必須の電子商取引業務に関する 10,000 語ガイド: フィールド意思決定エンジン (パート 2)

洗練されたeコマース運用において、フィールド意思決定エンジンは、的確なマーケティングと効率的な運用を実現するための重要なツールです。洗練されたeコマース運用のための10,000語の実践的なヒントシリーズの第2弾として、この記事ではフィールド意思決定エンジンのコアモジュールを詳細に解説し、よくある問題に対する解決策を参考までにご紹介します。

前回の記事では、eコマースの精緻な運用ツールであるフィールドデシジョンエンジンのシステムアーキテクチャ、業務プロセス、タグモジュール設計について解説しました。本記事では、ルールシステム、戦略システム、インスタンスシステム、戦略ツリー、そしてよくある課題について解説します。

VI. ルールシステム

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

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

ルールは作成された時点ではドラフト状態です。テストに合格し、オンラインリリースされると有効になります。ただし、リリース時点では、ルールにはドラフト版とオンライン版の2つのバージョンが存在します。

ルールのバージョン管理を標準化するため、その後のルール編集は、ドラフト版を作成し、テストを行った後、オンラインリリースし、既存のオンライン版を上書きする、という手順で行われます。これにより、ルール編集がオンライン実行に影響を与えることはありません。

そのため、ルールが公開されリリースされると、ドラフト版とオンライン版の2つのバージョンが作成されます。編集はドラフト版の編集となり、実行はオンライン版の実行となります。

ルールを実装した後、問題が見つかった場合は、そのルールを無効にすることができます。

削除するのではなく無効にする理由は何ですか?

まず、システムセキュリティ上の理由から、削除のようなリスクの高い操作は一般的に避けています。削除する場合でも、それは論理的な削除であり、物理的な削除ではありません。

第二に、一部のルールは既に戦略で使用されており、これらの戦略は既にユーザーワークフローに実装されています。これらのルールを突然削除すると、評価が困難になり、大きなリスクを伴います。

そのため、ルールにエラーが見つかった場合は、そのルールを無効にすることができます。ルールを無効にすると、新しいポリシーを作成する際にそのルールが使用できなくなります。ただし、既にそのルールを使用していて現在有効なポリシーは、影響を受けることなく、引き続きそのルールを使用して判定を行うことができます。ルールをネットワークから完全に削除したい場合は、対応するポリシーを無効にすることができます。

無効化されたルールごとに、有効化されたルールも存在します。有効化されたルールは利用可能とみなされ、ポリシー作成時に使用できます。

2. ルールの種類

タグタイプがあるように、ルールタイプもあります。

ルールの種類によって、意思決定に必要な入力パラメータが異なります。例えば、ユーザールールはUIDに基づきますが、商品ルールはSKUIDに基づきます。つまり、入力パラメータと意思決定は異なります。

ルールタイプとタグタイプの間には 1 対 1 の対応があります。

ユーザールール: ユーザータグを設定でき、決定は UID に基づいて行われます。
製品ルール: 製品タグを設定でき、決定は SKU ID に基づいて行われます。
注文ルール: 注文タグを設定でき、決定は orderid に基づいて行われます。
カスタムルール: カスタムタグを構成し、透明なタグフィールドに基づいて決定ルールを構成することができます。

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

例えば、ユーザーの年齢が29歳より大きいとします。ユーザーの年齢がラベル、演算子が「より大きい」、値が29です。この決定ロジックは、uidを使用して実際のユーザーの年齢ラベル値を取得することです。例えば、年齢が30歳のユーザー1がいる場合、システムは30が29より大きいかどうかを確認します。大きい場合はtrueを返し、そうでない場合はfalseを返します。

そのため、ルールを設定する際には、まず使用するタグを選択する必要があります。ルールの種類によって、選択できるタグの種類が異なります。例えば、ユーザールールではユーザータグのみ選択できます。

ラベルを選択したら、列挙型、テキスト、数値などのフィールドタイプを指定できます。フィールドタイプによって、値のオプション演算子と入力インタラクションが決まります。例えば、列挙型の場合は「含む/除外」、テキストの場合は「等しい/等しくない」、数値の場合は「より大きい/より小さい」を選択できます。

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

ただし、シナリオによっては、ルールの式が非常に複雑になり、複数の式を組み合わせる必要がある場合があります。これらの組み合わせは、演算子を使用して接続する必要があります。最も一般的な演算子はANDとORです。ANDは、式1と式2の両方が同時に満たされることを意味します。ORは、式1または式2のいずれかが満たされることを意味します。

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

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

3. ルールテスト

ルールを作成した後、デプロイする前にテストに合格する必要があります。これは、ルール設定の正確性を確保し、誤った設定でのデプロイを回避するためです。誤った設定でのデプロイは、ビジネス担当者が戦略作成時に誤ったルールを誤用するリスクにつながります。さらに、ルール作成権限はビジネス担当者にのみ付与されるため、すべてのビジネス担当者がルールを作成できてしまうため、リスクが高まります。

テストでは主に、パラメータを入力し、出力パラメータが期待どおりであるかどうかを観察します。

例えば、29歳以上のユーザーを対象とするルールでは、ユーザーのUIDを入力する必要があります。ルールの出力値は「はい」または「いいえ」のいずれかになります。ユーザーの年齢が30歳の場合、期待値を満たすにはルールの出力は「はい」である必要があります。「いいえ」の場合は期待値を満たしていません。

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

同時に、前述の通り、ルールがリリースされ展開されると、すべての業務担当者がそれを使用してポリシーを設定できるようになるため、大きなリスクを伴います。このリスクを軽減するために、ルールレベルでアクセス制御を実装することも可能です。

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

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

4. ルールの適用

ルールを作成してデプロイすると、どのインスタンス戦略でも選択して使用できるようになります。ルール側では、どのインスタンス戦略で使用されているかを認識する必要があります。

前述の通り、ルールを無効化すると、そのルールを既に使用しているポリシーは自動的に削除されず、手動で処理する必要があります。そのため、必要な対応を判断するには、ルールがどのインスタンスに関連付けられているかを把握しておく必要があります。

したがって、ルールがどの戦略に適用されているかを把握しておくことは、ルール調整後の後続のチェックに役立ちます。ルールが変更された場合、影響を受ける戦略の範囲を特定できるため、調整が必要な戦略を迅速に調整できます。

VII. 戦略システム

1. 戦略ライフサイクル

タグやルールなどの戦略にはライフサイクルがあります。

戦略は作成された時点ではドラフト状態です。保存するとドラフト版が生成されます。この時点で、戦略は段階的にオンラインで展開できます。

ただし、戦略実行の正確性をより適切に検証するために、この戦略では、それぞれプレリリース環境とカナリアリリース環境に対応するプレリリースバージョンとカナリアリリースバージョンも区別します。

戦略がプレリリース版にリリースされると、プレリリース環境でテストしてその正確性を確認できます。

最終的に、この戦略はオンラインで公開され、オンライン版が完成しました。このプロセスでは、ドラフト版、プレリリース版、グレースケール版、そしてオンライン版が作成されました。

戦略のバージョン管理を標準化するため、戦略のその後の編集は、ドラフト版を作成し、プレリリース版にリリースし、段階的にロールアウトした後、最終的に本番リリースし、更新版を上書きする、という手順で行います。これにより、編集とリリースのプロセスがオンライン実行に影響を与えることはありません。

戦略を公開して起動すると、有効化されます。戦略をオフラインにする必要がある場合は、直接無効化できます。これにより、すべての環境で戦略が無効になります。

戦略には有効期限があるという点で、ルールやタグとは異なります。タグとルールは無期限であり、有効期限は必要ありません。一方、戦略は段階的に実施されます。1月にはオペレーションをある方法で計画し、2月にはマーケティング戦略を別の方法で計画するといったことが考えられます。つまり、戦略には常に有効期限があるということです。

ポリシーがまだ有効な場合はオンライン状態となり、直接オフラインにしたり無効化したりできます。ただし、ポリシーの有効期限が切れると、自動的にオフラインになり無効化され、オンラインに戻すことはできません。

2. 戦略構成

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

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

次に、ユーザールール、製品ルールなど、ルールを選択する必要があります。ここで選択できるルールの種類は、シナリオインスタンスでサポートされているルールの種類によって異なります。ランダムに、あるいは恣意的に選択することはできません。シナリオインスタンスが特定のルールの種類をサポートする場合、フィールド意思決定エンジンに接続する際に、対応する入力パラメータが必要です。例えば、シナリオで製品ルールの選択を許可するポリシーを設定したい場合、意思決定に必要な製品SKUidの入力パラメータがなければ、そのポリシーは機能しません。

ルールを選択したら、最終的な決定の詳細を入力する必要があります。シナリオインスタンスごとに決定の詳細が異なります。例えば、プロモーションシナリオの決定の詳細には具体的なプロモーションオファーが含まれる一方、分割払いシナリオの決定の詳細には分割払い期間の範囲が含まれる場合があります。

この戦略をまだテストする必要がある場合は、A/B テスト機能を統合する必要があります。

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

制御グループと実験グループの設定可能な決定項目と範囲は、戦略自体の決定項目と範囲と一致しています。

これは二重の安全網としても機能します。実験に問題が発生した場合でも、戦略は基本的な決定内容を出力できます。実験が正常に実行された場合は、ユーザーが選択したグループ（コントロールグループまたは特定の実験グループ）に対応する決定項目を出力できます。

実験の有効期限が切れると、自動的に終了します。戦略が実行されると、実験は実行されなくなり、戦略内のフォールバック決定内容が自動的に出力されます。

ポリシーの有効期間内に実験を早期に終了したい場合は、手動で実験を閉じるか、新しい実験を作成できます。ただし、実験はポリシーに影響を与えます。つまり、実験のリリースとポリシーは連動しています。実験を更新した場合、ポリシーを有効にするには、同時にリリースする必要があります。

3. 戦略実行ロジック

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

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

シナリオインスタンスに複数の戦略が存在する状況があります。パラメータを入力すると、ルールの判断に基づいて複数の戦略がマッチングされ、それぞれが決定内容を出力します。このような状況はどのように処理すればよいでしょうか？

一般的な処理方法としては、和集合をとる、積集合をとる、優先順位に従って出力する、という 3 つの方法があります。

結合: 複数の戦略決定内容の結合、つまりすべてを結合して一緒に出力します。
積集合の取得：この手法は複数の戦略決定文の積集合を取得します。つまり、各戦略決定文に含まれる文のみが出力されます。このアプローチでは、積集合が空になる状況が発生しやすく、結果として決定文の出力が空になります。
優先度による出力：戦略自体の優先度に基づき、最初にターゲットにヒットした戦略に対応する決定内容を出力します。つまり、最も優先度の高い戦略の実行結果が使用されます。

現場の意思決定システムでは、シナリオインスタンスごとに要件が異なるため、この意思決定出力機能の設定をシナリオインスタンス設定でサポートできます。これにより、アクセス側の処理コストを削減できます。

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

VIII. シナリオインスタンスシステム

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

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

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

閉ループの現場意思決定システムとは、ユーザーがシナリオやインスタンスを選択し、戦略を作成し、ルールを選択し、決定を下し、インスタンスを公開し、現場意思決定システム内でオンラインで有効にすることを意味します。

このプロセス全体は、現場の意思決定システムの将来を見据えた設計に基づいており、ユーザーはシステムのあらゆるレイヤーと、設定中の実行ステップをすべて把握できます。現場の意思決定ロジックを理解するというユーザーの観点から見ると、コストは低いものの、運用コストは高くなります。

同時に、業務ユーザーは、独自の管理システム運用プロセスを整備することなく、現場の意思決定システムを自社の管理コストとして活用することができ、開発コストの削減にもつながります。

業務システムに現場意思決定システムを組み込むことで、ユーザーは現場意思決定システムを意識する必要がなくなります。トラフィック配信システムやプロモーションシステムなど、自社の業務システム内で独自の業務設定を完了し、ユーザールールや製品ルールを選択するだけで、特定のユーザーと製品に対してのみ業務活動が有効であることを明示できます。

このプロセス全体はビジネスシステムの観点から設計されており、ユーザーは設定時に現場の意思決定システムがどのように動作するかをほとんど意識していません。ユーザーが現場の意思決定ロジックを理解するコストは高いものの、運用コストは低く抑えられます。多くのシナリオにおいて、ビジネス担当者は現場の意思決定システムを理解することは難しくなく、またその必要性も感じません。彼らの視点からすれば、新規ユーザーのみに適用されるプロモーションオファーを作成することだけが目的です。このようなシナリオでは、組み込みアクセスアプローチがより効果的であり、理解コストと運用コストを大幅に削減できます。

もちろん、埋め込みアクセスの方法は基本的に変わりません。シナリオにアクセスする際、シナリオとインスタンスはデフォルトで事前定義されているか、インターフェースを通じてリアルタイムに作成されるという点が異なります。ビジネス側がルールを選択して保存すると、戦略が自動的に作成され、デプロイメントプロセスが実行されます。基盤となるフレームワークとロジックは変わりません。

しかし、これにより別の問題も発生します。各システムが独自の組み込みシステムを開発すると、業務システムの場合は開発と統合が面倒になり、現場の意思決定システムの場合は後で更新があった場合に保守が極めて困難になります。

そのため、現場意思決定システムは標準化されたコンポーネントの形で出力できます。業務システムで現場意思決定機能を利用する場合、このコンポーネントに主要なパラメータを渡し、同じ操作手順に従ってルールや意思決定内容などを選択すれば済みます。こうすることで、将来的にシステム更新が発生した場合でも、コンポーネントを統一的に更新・最適化できるため、効率が向上します。

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

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

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

インスタンスはコード実行の最小単位であると考えています。つまり、これらの戦略はすべて単一の意思決定プロセスに帰結するということです。もし各戦略を任意に変更・展開できるとしたら、データは常に同じ場所で更新・上書きされ、競合が発生する可能性があります。

したがって、この問題はインスタンスベースのデプロイメントを使用することで解決できます。一度に編集できるバージョンは1つだけで、次のバージョンは前のバージョンが公開された後にのみ開始できます。このバージョン管理はより安全で、問題が発生した場合でもタイムリーなロールバックを可能にします。

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

つまり、ポリシーの追加、無効化、編集など、インスタンスへのすべての変更は、インスタンスの決定に影響を与える可能性がある場合はインスタンスの変更と見なされ、それに応じてドラフトバージョン情報が更新されます。

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

ユーザーが現在最新バージョンを使用している場合、他のユーザーは、そのユーザーが公開を完了するか、編集内容を元に戻して元のバージョンを復元し、他のユーザーにリリースするまで待つしかありません。例えば、ユーザーAが戦略を追加して保存し、インスタンスをプレリリース版に公開した場合、戦略を追加したいユーザーBは戦略を追加できず、ユーザーAが自分のバージョンをオンラインで公開するか、自分のバージョンを元に戻して元のバージョンを復元するまで待つしかありません。

厳格なバージョン管理の最大の利点の一つは、いつでもロールバックできることです。ユーザーが新しくリリースされたバージョンに問題を発見した場合、過去のバージョンを参照し、以前のバージョンに迅速にロールバックできます。これは、新しいバージョンを作成し、コンテンツを以前のバージョンで上書きしてからリリースするのと同等です。このロールバックプロセスは非常に効率的で、リスクを最小限に抑えます。

3. 例のテスト

上記の文章ではタグテストとルールテストについて触れられていますが、戦略テストについては特に触れられていません。戦略テストが不可能というわけではなく、インスタンステストの方が費用対効果が高いということです。

インスタンスのバージョン管理から、インスタンスがコード実行の最小単位であることがわかります。戦略を設定する際の目標は、ルールテストで大まかな答えが得られるため、単一の戦略の実行効果をテストすることではありません。むしろ、この戦略を追加することで、関連する領域が実際にどのように表示されるかをテストしたいのです。

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

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

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

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

1. 問題点への対処

上記のシステムアーキテクチャに基づくと、現在の観点はシナリオから始まり、最終的な決定に至るまで一貫していることがわかります。

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

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

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

この戦略ツリーは、効率を迅速に向上させることができます。例えば、管理対象のユーザーを選択し、様々なシナリオで実行する戦略を迅速に設定できるため、運用効率を大幅に向上させることができます。一方で、これは上司の考え方にも合致しています。一般的に、上司はシステム機能の観点から始めるよりも、あるタイプのユーザーに対してどのような戦略を実装したか、また別のタイプのユーザーに対してどのような戦略を実装したかを確認することを確実に好みます。このような戦略は、蓄積と洗練にもつながります。

2. ツリー構造

現在のシステムアーキテクチャには、シナリオ、インスタンス、戦略、ルール、タグ、意思決定といった必要な要素がすべて含まれています。しかし、これらを再接続するには新たなフレームワークが必要であり、そのフレームワークこそがツリーです。

したがって、重要なのはツリー構造を構築することです。

上記のツリーと同様に、このアプローチは新規eコマースユーザーの運用に基づいています。まず、ユーザーをその価値に応じてプレミアム、アベレージ、グロースの3つの層に分類します。次に、これらの層内でさらに男性と女性に細分化し、よりきめ細かな運用を行います。

ルートノードから最下部のリーフノードまで、ツリーの様々なノードが完全なルールを形成していることは容易に理解できます。左端のブランチを例にとると、{ユーザーライフサイクル = 新規eコマースユーザー、ユーザーバリュー = 高品質ユーザー、ユーザーの性別 = 男性ユーザー} を表しています。

したがって、ツリーの場合、最初に考慮すべきことは、ツリー自体の ID、名前、および状態です。

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

各ノードは1つのルールに対応しています。子ノードは親ノードからルールを継承することができ、これらのルールは連結されてルールセットを形成することができます。

3. ツリー構成プロセス

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

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

すべてのツリーノードを作成したら、各ノードにポリシーを設定できます。ポリシーを設定する際には、ノードに既にルールが定義されているため、ルールを再度選択する必要はありません。シナリオ、インスタンス、および対応する決定内容を選択するだけで済みます。

4. ツリー実行フロー

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

一つのアプローチは、従来の現場意思決定システムに類似しており、戦略を読み取り、ルールを判断し、対応するシナリオインスタンスに基づいて意思決定内容を決定します。前述のように、戦略ツリーは本質的にルールの繋がりであり、単一のルールから「AND」で接続された複数のルールへと変化しますが、それでもルールであることに変わりはありません。したがって、システム全体は変化せず、実行ロジックも当然変化しません。

もちろん、別の理解方法もあります。それはツリーの観点から理解することです。ユーザーがシステムに入ると、システムはまずユーザーのルールを決定し、次にルートノードを使ってユーザーがどのツリーにいるのかを判断し、さらにレイヤーごとに進んでユーザーがどのリーフノードにいるのかを判断します。最後に、ツリー上のすべてのノードに対する戦略が実行されます。これは、ツリーの観点から実行ロジックを将来を見据えて理解するものです。

10. よくある質問

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

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

販売員に何度も説明してみましたが、いつも分かりやすく説明するのは難しいようです。

そこで、私は後に、フィルタリングと選択という別の概念で説明しようとしました。

フィルタリングは漏斗のようなものです。ユーザーがやって来て、通過できるかどうかを確認します。通過できない場合は、フィルタリングによって除外されます。あるのは漏斗だけで、中には何も入っていません。

選抜プロセスは羊小屋に似ています。羊小屋にはたくさんの羊がいて、それぞれにIDが付与されています。あなたは特定の羊の群れを率いてミルクを生産させることができます。例えば、今日は83匹の羊を率いてミルクを生産させました。羊小屋の中には具体的な存在があり、それらに対して特定のアクションを起こすことができます。

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

SMSマーケティングで30万人のユーザーをターゲットにしたい場合、これがターゲティングロジックです。特定のルールを用いて30万人のユーザープールを選択し、一括処理します。このプールはコンテナであり、30万人の「ユーザー」を格納します。特定のターゲットグループが特定できたら、SMSマーケティングメッセージの送信など、30万人のユーザーに対して具体的なアクションを実行できます。

ユーザールールはフィルタリングを目的としており、特定のユーザーグループを対象とするものではなく、意思決定にのみ使用されます。

ユーザーパッケージは特定のグループから選択され、マーケティングに使用されます。

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

もちろん、基盤として同じタグ付け機能を共有できます。ユーザーパッケージは、タグを使用してルール式を組み立て、それらの式をバッチ実行してパッケージを形成することで作成されます。一般的に、ユーザーパッケージのバッチ実行には時間がかかるため、常に更新時間が発生し、リアルタイム処理は不可能です。一方、ユーザールールはリアルタイムで判断を下すことができます。

2. 戦略を有効にするためにインスタンスをデプロイする必要があるのはなぜですか?

ユーザーがポリシーを公開する場合、実際にはインスタンスを公開する必要があります。なぜインスタンスを公開する必要があるのでしょうか？

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

3. タグを開発して作成する必要があるのはなぜですか?

タグがビジネススタッフによって作成されずに、R&D 担当者によって追加されたのはなぜですか?

一つの問題は、タグの特殊性です。多くのタグは、高度に専門化された設定オプションを必要とします。例えば、API経由で作成されたタグは、API名、メソッド名、タグのキャッシュ時間など、高度な技術情報を設定する必要があります。業務担当者がこれらの設定を行う場合でも、開発チームに関連情報を求める必要があります。開発チームが直接タグを追加する方がはるかに効率的です。

一个是标签的重要性。标签是场域决策系统的最底层最核心能力，如果标签出错了，那规则就出错，决策就出错，这是非常非常严重的问题。所以标签的准确性是场域决策系统的首要保障。由研发进行配置，配置后进行测试，可以最大限度保障标签准确性，确认无问题后再交付业务使用。

常规的标签维护逻辑是由业务提需求，研发添加、测试，然后再发布上线。如果上线后存在问题，研发也可以操作禁用或者修改。

4. 场域决策系统权限如何控制

通过上文的介绍，大家很容易感受到，场域决策系统是一个非常重要的中枢系统，就像人的大脑一样，负责处理各类决策。那么，系统肯定需要完善的权限控制，避免大脑被“入侵”，造成决策事故。

在场域决策系统的每一层，场景、实例、策略、规则、标签，都需要有严格的权限控制。

除此之外，策略、规则、标签本身可以有权限人员控制，也就是说创建策略的时候，可填写有权修改该策略的人员，后续该人员也可以进行处理。毕竟工作中涉及交接、配合等场景，有时候需要其他同事帮忙补位处理。

当然，系统还需要超级管理员角色，以备不时之需。比如有同事在休假，或者离职等场景，导致已有的策略、规则、标签没有人有权限操作时，超级管理员就可以发挥作用。

Haozao