電子商取引の洗練されたオペレーションの要点に関する 1 万語の実用的な情報 - 現場意思決定エンジン (パート 2)

電子商取引の洗練された運用において、現場意思決定エンジンは、正確なマーケティングと効率的な運用を実現するための重要なツールです。洗練された電子商取引の運用に不可欠な 10,000 語の記事シリーズの第 2 回目として、この記事では、現場の意思決定エンジンのコア モジュールを詳細に分析し、一般的な問題に対する解決策を参考として提供します。

上記の記事では、電子商取引の洗練された操作ツール、現場の意思決定エンジンのシステムアーキテクチャ、ビジネスプロセス、ラベルモジュール設計について説明しています。この記事では、分解を続け、ルール システム、戦略システム、インスタンス システム、戦略ツリー、一般的な問題について説明します。

6. ルールシステム

1. ルールのライフサイクル

ルールには、ラベルと同様に、ライフ サイクルがあります。

ルールが作成されると、ドラフト ステータスになります。試験に合格し、オンラインで公開されると有効になります。しかし、オンラインで公開されたときには、ルールにはドラフト版とオンライン版の 2 つのバージョンがありました。

ルールのバージョン管理を標準化するため、後続のルールを編集する必要がある場合は、ドラフト版を編集し、テストしてオンラインでリリースし、オンライン版を更新する、という手順を踏むことになります。これにより、編集プロセス中にルールがオンライン実行に影響を与えないことも保証されます。

したがって、ルールが公開されてオンラインで開始されると、ドラフト バージョンとオンライン バージョンの 2 つのバージョンが生成されます。各編集はドラフト バージョンの編集であり、各実行はオンライン バージョンの実行です。

ルールがオンラインになった後、ルールに問題が見つかった場合は、ルールを無効にすることができます。

削除ではなく無効化するのはなぜですか?

まず、システムセキュリティを考慮し、削除などのリスクの高い操作は基本的に行いません。削除したとしても、それは論理的な削除であり、物理的な削除ではありません。

第二に、いくつかのルールが戦略で使用され、戦略がユーザー プロセスに組み込まれました。ルールを軽率に削除すると、影響を評価することが難しくなり、リスクが大きくなります。

したがって、ルールにエラーがあることがわかった場合は、そのルールを無効にすることができます。ルールを無効にすると、後でポリシーを作成するときにそのルールを使用できなくなります。ただし、ルールがすでに使用されていて有効な場合は、そのルールを使用して判定を実行することができ、影響を受けません。ルールを完全にオフラインにしたい場合は、対応する戦略をすべてオフラインにすることができます。

無効化がある場合は、有効化も必要です。有効は、ルールが使用可能であることを意味します。ポリシーを作成するときに、このルールを使用することを選択できます。

2. ルールの種類

タグ タイプに対応して、ルールにもルール タイプがあります。

ルールの種類によって、決定を行う際の入力要件が異なります。たとえば、ユーザー ルールは uid に基づいて決定を下しますが、製品ルールは skuid に基づいて決定を下します。つまり、入力パラメーターと決定には違いがあります。

ルールタイプはタグタイプに1つずつ対応しています

• ユーザールール: 設定するユーザータグを選択し、uidに基づいて決定を下すことができます。
• 製品ルール: 設定する製品タグを選択し、skuidに基づいて決定を下すことができます。
• 注文ルール: 注文タグを選択して設定し、orderidに基づいて決定を下すことができます。
• カスタムルール: 設定用のカスタムタグを選択し、透明なタグフィールドに基づいて決定ルールを設定できます。

ルールを構成するときは、実際にはラベル + 演算子 + 値という式を構成します。

たとえば、ユーザーの年齢は 29 より大きいです。ユーザーの年齢はラベル、演算子はより大きい、値は 29 です。決定ロジックは、uid を通じて実際のユーザー年齢ラベル値を抽出します。たとえば、年齢が 30 歳のユーザー 1 がいるとします。30 が 29 より大きい場合は true が返され、それ以外の場合は false が返されます。

したがって、ルールを構成するときは、まず使用するタグを選択する必要があります。さまざまなタイプのルールが、さまざまなタイプのタグの選択をサポートします。たとえば、ユーザー ルールではユーザー タグのみを選択できます。

ラベルを選択した後、列挙、テキスト、数値などのフィールド タイプを決定できます。フィールド タイプによって、オプションの演算子と値入力の相互作用が決まります。たとえば、列挙では含める/含めないを選択でき、テキストでは等しい/等しくないを選択でき、数値ではより大きい/より小さいを選択できます。

したがって、次のステップは演算子を選択し、対応する値を入力することです。

ただし、シナリオによっては、ルールの式がより複雑になり、複数の式で構成する必要があり、それらを演算子で接続する必要もあります。最も一般的な演算子は and と or です。そして、式 1 と式 2 が同時に満たされる必要があることを意味します。または、式 1 と 2 のいずれか 1 つを満たすことを意味します。

私たちは中学校と高校の数学で基本的な論理式を学びました。 A と B の反対は A ではない、または B ではないです。つまり、(ラベル 1 に a が含まれる) と (ラベル 2 に b が含まれる) を選択できます。反対にしたい場合は、(ラベル 1 に a が含まれない) または (ラベル 2 に b が含まれない) という構成になります。

したがって、 and と or は、日常的な複数式関係構成の 99% 以上を解決できます。

3. ルールテスト

ルールが作成された後、オンラインになる前にテストに合格する必要があります。これは、ルール構成の正確性を確保し、構成エラーがオンラインで発生するのを回避するためです。構成エラーが発生すると、ビジネス担当者がポリシーを作成するときに誤ったルールを誤用する可能性があります。さらに、ルールを作成する権限はビジネス担当者に与えられます。すべてのビジネス担当者がルールを作成できるため、リスクが高くなります。

テストの主な目的は、入力パラメータを入力し、出力パラメータが期待どおりであるかどうかを観察することです。

たとえば、ユーザーの年齢が 29 歳以上であるというルールの場合、uid を入力して、ルールの出力値が何であるかを観察する必要があります。ルールの出力値は yes と no のみです。ユーザーの年齢が 30 歳だとすると、ルールの出力値は「はい」になる必要があり、これは期待どおりです。答えが「いいえ」の場合、期待に応えられません。

カスタム ルールの場合、ラベル値は透過的に送信されるため、入力パラメータはルールによって選択されたカスタム ラベルになることに注意してください。

同時に、前述のように、ルールがリリースされ、開始されると、すべてのビジネス担当者がそのルールを使用してポリシーを構成できるため、リスクの高いアプローチとなります。このリスクを回避するために、ルール レベルで権限制御を実行することもできます。

パブリック ルールの場合は、ユーザーがルールを作成した後、すべてのビジネス担当者がポリシーを構成することを選択できます。ただし、プライベート ルールの場合は、ユーザーが作成した後は、ユーザー自身がポリシーを構成する場合にのみ使用できます。

パブリック ルールの構成権限を制御するだけで済むため、広く使用されているルール構成エラーの影響を効果的に軽減できます。

4. 規則の適用

ルールが作成され、オンラインで公開されると、任意の戦略で選択して使用できるようになります。ルールの観点から、どのインスタンス戦略が使用されているかを知る必要があります。

前述のように、ルールが無効になった後、そのルールを使用していたポリシーは自動的にオフラインにはならず、手動で処理する必要があります。したがって、ここでは、何を処理するかを知るために、ルールがどのインスタンスに関連付けられているかを知る必要があります。

したがって、どのポリシーでルールが使用されているかを知っておくと、ルールを調整した後のその後の検査が容易になります。ルールが変更された場合、影響を受けるポリシーの範囲を確認でき、調整が必要なポリシーを迅速に調整できます。

7. 戦略システム

1. ポリシーのライフサイクル

タグやルールと同様に、ポリシーにもライフ サイクルがあります。

ポリシーが作成されると、ドラフト状態になります。保存すると、ドラフトバージョンが生成されます。この時点で、戦略を徐々にオンラインに展開することができます。

ただし、ポリシー実行の正確性をより適切に検証するために、ポリシーではプレリリース バージョンとグレースケール バージョンも区別されます。それぞれプレリリース環境とグレースケール環境に対応します。

ポリシーがプレリリース バージョンに公開されると、プレリリース環境でポリシーを体験して、ポリシーの正確性を確認できます。

最終的に、戦略はオンラインで公開され、オンライン版が利用可能になります。この過程で、ドラフト版、プレリリース版、グレースケール版、オンライン版が合計で制作されました。

戦略のバージョン管理を標準化するため、後から戦略を編集する必要がある場合は、ドラフト版を編集し、プレリリース版にリリース、グレースケール版にリリース、オンライン版にリリース、更新版を上書きするなどの手順で行います。これにより、編集中および公開中のオンライン実行にポリシーが影響しないことも保証されます。

ポリシーはオンラインでリリースされると有効になります。ポリシーをオフラインにする必要がある場合は、ポリシーを直接無効にすることができます。これは、すべての環境でポリシーを無効にすることと同じです。

ポリシーには有効期間があるという点で、ルールやラベルとは異なることに注意することが重要です。ラベルやルールは長期間存在し、使用されるため、有効期間を設定する必要はありません。戦略は段階的に行われます。 1 月にはこのように運営し、2 月にはこのようにマーケティングを行うとよいでしょう。したがって、戦略には有効期限が必要です。

ポリシーが有効期間内であればオンライン状態となり、オフラインで直接無効化する操作も行えます。ただし、ポリシーの有効期限が切れると自動的に無効になり、オンラインでの操作ができなくなります。

2. ポリシー設定

ポリシーの構成には、有効期間、選択ルール、決定内容が含まれます。

簡単に言うと、ポリシーを作成するときは、まずポリシー名、ポリシーの有効期間などの基本情報を入力する必要があります。

次に、ユーザー ルール、製品ルールなどのルールを選択する必要があります。ここで選択できるルール タイプは、シナリオ インスタンスでサポートされているルール タイプによって異なります。ここは、何でもランダムに選んだりサポートしたりできる場所ではありません。シナリオ インスタンスがこのルール タイプをサポートする場合、フィールド決定エンジンに接続するときに、対応する入力パラメータが必要です。たとえば、特定のシナリオで戦略を構成する場合、製品ルールを選択できますが、意思決定のために入力する製品 SKUid がない場合、確実に機能しません。

ルールを選択したら、最終決定内容を入力する必要があります。シナリオインスタンスが異なれば、決定内容も異なります。たとえば、プロモーション シナリオの決定内容は特定のプロモーション オファーであり、分割払いシナリオの決定内容は分割回数のリスト範囲である可能性があります。

この戦略をまだテストする必要がある場合は、AB 実験機能へのアクセスが必要です。

基本ルールと判定内容を設定した後、AB テストを実施するには、実験の有効期間、コントロール グループと実験グループの比率、コントロール グループと実験グループの対応する判定内容など、AB 実験を設定する必要があります。

制御グループと実験グループの構成可能な決定コンテンツ項目とスコープは、戦略自体の決定コンテンツ項目とスコープと一致しています。

これも二重保証に相当します。実験に問題がある場合でも、戦略は基本的な決定内容を出力できます。実験が正常に実行されると、ユーザーがヒットしたグループ（コントロールグループ/実験グループ）とそれに対応する決定項目の内容を出力できます。

実験の有効期間が終了すると、実験は自動的に終了し、戦略の実行時に実験は実行されなくなり、戦略内のバックアップ決定内容が自動的に出力されます。

戦略の有効期間中に実験を早期に終了したい場合は、実験を手動で閉じるか、新しい実験を作成することもできます。しかし、実験は戦略に基づいて実行されます。つまり、実験のリリースは戦略と統合されます。実験が更新された場合、戦略を有効にするには同期的にリリースする必要があります。

3. 戦略実行ロジック

• タグの実行ロジックは、パラメータを入力し、タグに対応する値を返すことです。
• ルールの実行ロジックは、パラメータを入力し、yes または no、つまりルールがヒットしたかどうかを返すことです。
• 戦略の実行ロジックは、パラメータを入力し、特定の決定コンテンツを返すことです。

つまり、このシナリオインスタンスでは、戦略は、入力パラメータに必要な uid、skuid、orderid、透過フィールドなどのルール決定結果に基づいて決定コンテンツを返します。

すると、状況が起こります。シナリオインスタンスに複数の戦略がある場合、パラメータを入力後、ルール判断に基づいて複数の戦略をマッチングし、決定内容を出力します。何をすべきでしょうか?

一般的な処理方法には、和集合、積集合、優先順位による出力の 3 つがあります。

1. 結合を取る: 複数のポリシー決定内容の結合を取ります。つまり、すべてを結合して一緒に出力します。
2. 交差を取る: 複数の戦略的意思決定コンテンツの交差を取ります。つまり、各戦略的意思決定コンテンツ内のものだけが出力されます。この方法では、交差点が空になり、決定内容の出力が空になる状況に簡単に陥る可能性があります。
3. 優先度による出力：戦略自体の優先度でソートし、優先度に応じて最初にヒットした戦略に対応する決定内容を出力します。つまり、優先度の高い戦略の実行結果が優先されます。

現場意思決定システムの場合、この意思決定出力機能の構成は、シーンインスタンス構成でサポートできます。シーンインスタンスが異なれば、要求も必ず異なります。これにより、アクセス側の処理コストを削減できます。

もちろん、別の方法もあります。フィールド決定は、すべての結果をアクセス パーティに順番に返し、各アクセス パーティは最終的な出力結果について独自の決定を下します。

8. シーンインスタンスシステム

1. シナリオアクセスタイプ

ビジネス シナリオでフィールド意思決定エンジンの機能を使用する場合は、フィールド意思決定システムに接続する必要があります。

システム連携の観点では、現場意思決定システムのクローズドループによるアクセス方法と、業務システムに現場意思決定システムを埋め込むアクセス方法の 2 つがあります。

フィールド意思決定システムのクローズド ループとは、ユーザーがシナリオとインスタンスを選択し、ポリシーを作成し、ルールを選択し、意思決定を選択し、インスタンスを公開し、それらをオンラインにしてフィールド意思決定システムで有効にすることを意味します。

この一連のプロセスは、現場の意思決定システムに基づいて設計されたフォワード プロセスです。ユーザーは、構成中にシステムの各レイヤーと実行の各ステップを認識することになります。現場の意思決定ロジックをユーザーが理解する観点から見ると、コストは低いですが、運用コストは高くなります。

同時に、このソリューションにより、ビジネス関係者は独自の管理システム運用手順を維持する必要がなく、現場の意思決定システムを自社の管理コストとして直接使用できるようになり、開発コストも削減できます。

現場意思決定システムを業務システムに組み込むことで、ユーザーは現場意思決定システムを意識する必要がなくなります。トラフィック配信システムやプロモーション システムなど、独自のビジネス システムで独自のビジネス構成を完了し、ユーザー ルールまたは製品ルールを 1 つだけ選択して、ビジネス アクティビティが指定されたユーザーと製品に対してのみ有効であることを示すことができます。

この一連のプロセスはビジネス システムの観点から設計されており、ユーザーは構成中に現場の意思決定システムがどのように動作するかをほとんど認識していません。現場の意思決定ロジックをユーザーが理解する観点からは、コストは高いが、運用コストは低い。多くのシナリオでは、実際にはビジネス担当者にとって困難であり、現場の意思決定システムを理解する必要はありません。彼らの視点から見ると、新規ユーザーにのみ有効なプロモーションオファーを作成するだけです。このシナリオでは、埋め込みアクセス方法の方が効果的であり、理解と運用にかかるコストを大幅に節約できます。

もちろん、埋め込みアクセス方法は本質的には変わりません。これは、シーンにアクセスしたときに、デフォルトでインターフェイスを介してシーンをカスタマイズしたり、シーンとインスタンスをリアルタイムで作成したりするのと同じです。ビジネス選択ルールが保存され有効になると、ポリシーが自動的に作成され、リリースプロセスが実行されるのと同じことになります。その背後にあるフレームワークと基礎となるロジックは変更されていません。

しかし、これによって別の問題も発生します。各システムに独自の組み込みシステムがある場合、業務システムの開発やアクセスが面倒になります。また、現場の意思決定システムについては、その後の更新があった場合、維持することが非常に困難になります。

したがって、現場意思決定システムは標準化されたコンポーネントの形で出力できます。ビジネス システムが現場の意思決定機能を使用する場合は、主要なパラメータをコンポーネントに渡し、同じ操作プロセスに従ってルールや意思決定内容などを選択する必要があります。この方法により、後続の更新がある場合でも、すべての最適化コンポーネントを均一に更新できるため、より効率的になります。

2. インスタンスのバージョン管理

前述のように、ユーザーがポリシーを公開する場合、実際にはインスタンスを公開する必要があります。

インスタンスを公開する理由は何ですか?

私たちは、インスタンスがコード実行の最小単位であると考えています。つまり、これらの戦略は、この場所で決定を下した結果であるということです。すべての戦略をオンラインで自由に変更して公開できる場合、データは常に同じ場所で更新および上書きされることになり、競合が発生する可能性があります。

したがって、この問題はインスタンスを公開することで解決できます。同じ場所で、同時に編集できるのは 1 つのバージョンのみです。 1 つのバージョンがリリースされた後、次のバージョンを開くことができます。このタイプのバージョン管理はより安全であり、問​​題が発生した場合に時間を遡ってロールバックするのにも役立ちます。

インスタンスリリースには、ドラフト、プレリリース、グレースケール、オンラインの 4 つのバージョンがあります。

つまり、新しいポリシーの追加、ポリシーの無効化、ポリシーの編集など、インスタンスへのあらゆる変更は、インスタンスの決定に影響を与える可能性がある限り、インスタンスの変更とみなされ、ドラフト バージョンの情報が変更されます。

ドラフト版が更新された後、プレリリース版、グレースケール版、そしてオンライン版へとリリースする必要があります。各バージョンのデータが順番に更新されるように、順番にリリースして実行します。

現在のバージョンがユーザーによって使用されている場合、他のユーザーは、そのユーザーがリリースを完了するか、編集を元に戻して元の状態に戻して他のユーザーにリリースするまで待つことしかできません。たとえば、ユーザー A が新しいポリシーを追加して保存し、インスタンスをプレリリース バージョンに公開します。このとき、ユーザー B は新しいポリシーを追加したいのですが、追加できません。ユーザー A が自分のバージョンをオンラインで公開するのを待つか、バージョンを取り消して元のバージョンに復元することしかできません。

厳密なバージョン管理の最大の利点の 1 つは、いつでもロールバックできることです。ユーザーは、リリースされたばかりのバージョンに問題があることに気付いた場合、過去のバージョンを表示し、過去のバージョンを選択してすぐにロールバックすることができます。これは、新しいバージョンを作成し、リリースする前にコンテンツを過去のバージョンで上書きすることと同じです。この種のフォールバック処理は非常に効率的であり、リスクを最小限に抑えることができます。

3. 例題テスト

上記ではラベルテストとルールテストについては触れましたが、戦略テストについては触れていませんでした。戦略をテストできないわけではなく、インスタンス テストの方がコスト効率が高いのです。

インスタンスのバージョン管理から、インスタンスがコード実行の最小単位であることがわかります。ポリシーを構成しますが、ルールのテストを通じて大まかな答えを知ることができるため、本質的には単一のポリシーの実行効果をテストしているわけではありません。代わりに、この戦略を追加した後に自分のエリアがどのように表示されるかをテストしたいと思います。

このインスタンスには複数のポリシーが存在する可能性があり、これにはポリシー実行ロジックが含まれます。このシナリオ インスタンスには、uid、skuid、さまざまな透過フィールドなど、多くの入力パラメーターが含まれる場合があります。

したがって、インスタンス テストを通じてのみ、ユーザー側の実行効果の最も正確なシミュレーションを取得できます。

インスタンスをテストするときは、uid や skuid など、シナリオ インスタンスに必要なフィールドを入力パラメータに入力する必要があります。次に、インスタンスは実行結果を返します。つまり、最終的な強度決定値を出力します。これは、複数の戦略を実行した後、戦略実行ロジックに基づいて最終的に出力される決定値である可能性があります。

9. 戦略ツリーのアップグレード

1. 問題点を解決する

上記のシステム アーキテクチャから、現在の視点がシーンから最終決定に至るまでトリガーされていることがわかります。

このロジックは理解しやすいですが、2 つの問題があります。

1. 操作は比較的複雑です。異なるシナリオで同じユーザーに対してポリシーを実行する必要がある場合は、異なるシナリオインスタンスに移動して操作する必要があり、操作コストが増加します。
2. 抽象化が難しい。現在の構造では、同じユーザー タイプに対してどのような洗練された戦略が実装されているかをすぐに確認することは困難です。

したがって、戦略ツリーを形成するには、ユーザー ディメンションや製品ディメンションなどの別のディメンションから戦略全体を抽象化する必要があります。

一方、この戦略ツリーは効率を迅速に向上させることができます。たとえば、操作するユーザーを選択し、さまざまなシナリオで実行する戦略をすばやく構成できるため、運用効率が大幅に向上します。一方、これは上司の考えとより一致しています。一般的に言えば、上司は、システム機能の観点から始めるのではなく、特定のタイプのユーザーに対してどのような戦略を実装したか、また別のタイプのユーザーに対してどのような戦略を実装したかを必ず確認したいと思っています。このような戦略は、蓄積と沈殿にもより役立ちます。

2. ツリー構造

現在のシステム構造では、シナリオ、インスタンス、戦略、ルール、ラベル、決定がすべて完了しています。しかし、それらを再び接続するには新しいキャリアが必要であり、この新しいキャリアが木です。

したがって、ツリー構造の構築に重点が置かれます。

上記のツリーと同様に、操作は新しい e コマース ユーザーに基づいています。まず、ユーザーをその価値に応じて優良ユーザー、一般ユーザー、成長ユーザーの3つの層に分けます。そして、男性ユーザーと女性ユーザーを性別ごとに分け、さらに操作を細かく設定します。

ルート ノードから最下部のリーフ ノードまでのツリーのさまざまなノードが接続されて完全なルールを形成していることは、簡単にわかります。左端のブランチを例にとると、その意味は{ユーザーライフサイクル = 新規eコマースユーザー、ユーザーバリュー = 高品質ユーザー、ユーザー性別 = 男性ユーザー}となります。

したがって、ツリーの場合、最初に必要なのはツリー自体の ID、名前、およびステータスです。

次に、ツリーには複数のノードを含めることができ、異なるツリーノードにも ID、名前、状態があります。

そして、各ノードはルールに対応します。子ノードは親ノードのルールを継承し、それらを接続してルール セットを形成することもできます。

3. ツリー構成プロセス

ツリーの構成ロジックは、ノードを作成してツリーを構築し、各ノードで戦略を構成することです。

ノードを作成するロジックは、ユーザー ルールを選択することです。異なるノードは異なるユーザー ルールによって定義されます。異なるレベルのノードには継承関係があり、つまり、次のレベルのリーフ ノードのルールは、前のレベルのリーフ ノードのルールを継承します。

ツリー ノードが作成された後、各ノードでポリシーを構成できます。ポリシーを構成する場合、ノードにはすでにルールが定義されているため、ルールを選択する必要はありません。シナリオ、インスタンス、および対応する決定コンテンツを選択するだけです。

4. ツリー実行プロセス

ツリーの実行プロセスを理解するには 2 つの方法があります。

1つは、これまでの現場意思決定システム実行プロセスと同じで、戦略を読み取り、ルールを判断し、対応するシナリオインスタンスに応じて意思決定内容を決定します。なぜなら、戦略ツリーの場合、前述のように、本質的にはルールのつながりだからです。単一のルールが「and」で接続された複数のルールになりますが、それでもルールであることに変わりはありません。したがって、システム全体は変更されておらず、実行ロジックも当然変更されません。

もちろん、それを理解するには別の方法もあります。それは、木の観点から理解することです。ユーザーがアクセスすると、まずユーザー ルールを決定し、次にルート ノードを通じて、ユーザーがヒットするツリーを決定し、次にユーザーがレイヤーごとにヒットするリーフ ノードを決定し、最後にヒットするすべてのノードの戦略を実行します。これは、ツリーの観点から実行ロジックを積極的に理解するためです。

10. よくある質問

1. ユーザールールとユーザーパッケージの違いは何ですか?

ビジネス プロセスで最もよく尋ねられる質問は、「フィールド決定システムのルールを使用して、ユーザー グループを囲み、テキスト メッセージを送信できますか?」です。

営業スタッフに何度も説明しようとしましたが、なかなか丁寧に説明するのが難しいようです。

そのため、私は後に、スクリーニングと選択という別の概念でそれを説明しようとしました。

スクリーニングは漏斗のようなものです。ユーザーが来たら、通過できるかどうかを確認します。もし彼が見逃されなかったら、彼は排除されたことになる。具体的なものが何も入っていない漏斗だけが残っています。

円の選択は羊小屋に似ています。羊小屋にはたくさんの羊がいて、それぞれの羊にはIDが付けられています。この特定の羊の群れを引き寄せてミルクを生産することができます。たとえば、今日はミルクを生産するために 83 頭の羊を捕まえました。羊小屋の中には具体的な物のセットがあり、それらに特定のアクションを適用できます。

したがって、現場意思決定システムにおけるルール エンジンはスクリーニング ロジックのようなもので、ルールはファネルのようなものです。各ユーザーが来たときに、そのユーザーがルールに一致しているかどうか（フィルタリングされているかどうか）しかわかりませんが、ファネル自体はコンテナではなく、「ユーザー」が含まれていないため、このファネルに何人のユーザーがいるかはわかりません。

これらの 300,000 人のユーザーを選択して SMS マーケティングを送信する場合、これが選択ロジックです。特定のルールに基づいて 300,000 人のユーザーのパッケージを選択し、バッチ処理します。このパッケージは、300,000 人の「ユーザー」を含むコンテナです。ターゲットが明確になれば、SMS マーケティングの送信など、30 万人のユーザーに対して明確なアクションを実行できます。

ユーザー ルールはスクリーニングであり、特定のオブジェクトを持たず、意思決定にのみ使用されます。

ユーザー パッケージは丸で囲まれ、特定のターゲットが設定されており、マーケティングに使用されます。

これがユーザールールとユーザーパッケージの最大の違いです。

もちろん、ベースとして同じタグ付け機能を持つこともできます。ユーザー パッケージは、タグを使用して正規表現を組み立て、その表現のユーザー バッチを実行することによって形成されます。一般的に、ユーザー パッケージのバッチを実行するには時間がかかるため、更新時間が必要になり、リアルタイムで実行することはできません。ユーザールールによりリアルタイムで決定を下すことができます。

2. ポリシーを有効にするためにインスタンスを公開する必要があるのはなぜですか?

ユーザーがポリシーを公開する場合、実際にはインスタンスを公開する必要があります。インスタンスを公開する理由は何ですか?

私たちは、インスタンスがコード実行の最小単位であると考えています。つまり、これらの戦略は、この場所で決定を下した結果であるということです。すべての戦略をオンラインで自由に変更して公開できる場合、データは常に同じ場所で更新および上書きされることになり、競合が発生する可能性があります。

したがって、この問題はインスタンスを公開することで解決できます。同じ場所で、同時に編集できるのは 1 つのバージョンのみです。 1 つのバージョンがリリースされた後、次のバージョンを開くことができます。このタイプのバージョン管理はより安全であり、問​​題が発生した場合に時間を遡ってロールバックするのにも役立ちます。

インスタンスリリースには、ドラフト、プレリリース、グレースケール、オンラインの 4 つのバージョンがあります。

つまり、新しいポリシーの追加、ポリシーの無効化、ポリシーの編集など、インスタンスへのあらゆる変更は、インスタンスの決定に影響を与える可能性がある限り、インスタンスの変更とみなされ、ドラフト バージョンの情報が変更されます。

ドラフト版が更新された後、プレリリース版、グレースケール版、そしてオンライン版へとリリースする必要があります。各バージョンのデータが順番に更新されるように、順番にリリースして実行します。

現在のバージョンがユーザーによって使用されている場合、他のユーザーは、そのユーザーがリリースを完了するか、編集を元に戻して元の状態に戻して他のユーザーにリリースするまで待つことしかできません。たとえば、ユーザー A が新しいポリシーを追加して保存し、インスタンスをプレリリース バージョンに公開します。このとき、ユーザー B は新しいポリシーを追加したいのですが、追加できません。ユーザー A が自分のバージョンをオンラインで公開するのを待つか、バージョンを取り消して元のバージョンに復元することしかできません。

厳密なバージョン管理を行うことの最大の利点の 1 つは、いつでもロールバックできることです。ユーザーは、リリースされたばかりのバージョンに問題があることに気付いた場合、過去のバージョンを表示し、過去のバージョンを選択してすぐにロールバックすることができます。これは、新しいバージョンを作成し、リリースする前にコンテンツを過去のバージョンで上書きすることと同じです。この種のフォールバック処理は非常に効率的であり、リスクを最小限に抑えることができます。

3. ラベルを開発および作成する必要があるのはなぜですか?

タグはビジネス担当者自身によって作成されるのではなく、なぜ R&D によって追加されるのでしょうか?

1つはレーベルのプロフェッショナリズムです。多くのタグには専門的な設定項目が必要です。たとえば、インターフェースを通じて作成されたタグには、インターフェース名、メソッド名、タグのキャッシュ時間などの設定が必要です。これらは非常に専門的な内容です。たとえビジネス担当者が対応したとしても、関連情報を入手するには R&D に問い合わせる必要があります。 R&D が直接追加した方が効果的でしょう。

1つはラベルの重要性です。ラベルは、現場の意思決定システムの最も基本的かつ中核的な機能です。ラベルが間違っていれば、ルールも間違ったものになり、決定も間違ったものになります。これは非常に深刻な問題です。したがって、ラベルの精度は、フィールドの意思決定システムの主要な保証です。 R＆Dによる構成と構成後のテストは、ラベルの精度を最大化でき、問題がないことを確認した後にのみビジネスで提供されます。

従来のタグメンテナンスロジックは、ビジネスが要件を提起し、R＆Dが追加およびテストを行い、オンラインでリリースすることです。オンラインになった後に問題がある場合、R＆Dはそれを無効または変更することもできます。

4.フィールドの意思決定システムの権限を制御する方法

上記の紹介を通して、誰もがフィールドの意思決定システムが、人間の脳のように非常に重要な中心システムであり、さまざまな意思決定を処理する責任があると感じるのは簡単です。その後、システムは間違いなく、脳が「侵略」され、意思決定事故を引き起こすのを防ぐために完全な許可制御を必要とします。

フィールドの意思決定システムのすべてのレイヤー、シナリオ、インスタンス、ポリシー、ルール、およびラベルにはすべて、厳格な許可制御が必要です。

さらに、ポリシー、ルール、およびラベル自体は、認定担当者によって制御できます。つまり、ポリシーを作成する場合、ポリシーを変更する権限を持つ担当者を埋めることができます。また、担当者は後で処理することもできます。結局のところ、仕事にはハンドオーバーや調整などのシナリオが含まれ、時にはギャップを埋めるために他の同僚が必要です。

もちろん、このシステムには、緊急時にスーパー管理者の役割も必要です。たとえば、同僚が休暇中または会社を離れる場合、既存のポリシー、ルール、タグを運営する許可が誰もいない場合、スーパー管理者は役割を果たすことができます。