Eコマースオペレーションにおいて、オペレーションの洗練は効率性と効果性の向上の鍵となります。この記事では、Eコマースオペレーションの3つの中核となる「人、商品、場所」という側面から、サイト固有の意思決定エンジンを構築することで、オペレーションの洗練を実現する方法について深く掘り下げます。

電子商取引業務とは、人、商品、場所といった様々な次元に基づいた、洗練された業務システムです。つまり、特定のシナリオにおいて、特定のユーザーや特定の商品に対して特定のビジネスアクションを実行し、それに伴うビジネスデータを観察することを意味します。

以前の記事でも述べたように、Eコマース業務はマーケティングシステム、ゴールデンプロセス、プロモーションシステムなどを含む非常に大規模なシステムです。各システムがシナリオ、チャネル、ユーザー、商品などについて独自の戦略ルールを維持していると、各システムが独自のロジックを持つことになり、日々のメンテナンスが困難になり、開発コストの増大と運用効率の低下につながります。

そのため、タグ、ルール、戦略、インスタンス、シナリオ、戦略ツリー、データなど、最下層からアプリケーション層までのすべての機能を包含し、あらゆる電子商取引運用システムでの使用をサポートする汎用的なフィールド意思決定エンジンが必要です。

この記事では、Field Jue エンジンの構築方法を 2 つの部分に分けて説明します。

I. 背景

II. 専門職名の説明

III. システムフレームワーク

IV. ビジネスプロセス

V. ラベリングシステム

VI. ルールシステム

VII. 戦略システム

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

IX. 戦略ツリー

10. よくある質問

I. 背景

日々の業務において、eコマース企業は最適な結果を得るために、精緻なユーザーターゲティングとセグメンテーションテストを実施する必要があります。例えば、特定のユーザーにクーポンを発行し、どのクーポンがそれらのユーザーのコンバージョンを促進するのに最も効果的かをテストするなどです。

このプロセスには、ユーザー グループの精緻なスクリーニングと、ユーザー セグメンテーションにおける正確な実験が含まれます。

現場意思決定システムは主に以下の目的を達成します。

• シナリオ、チャネル、ユーザー、製品選択ルールなどの統一的なメンテナンスにより、基礎となるデータの統一的な管理だけでなく、後続のモジュールの統一的なメンテナンスと最適化も実現できます。
• 統合運用戦略管理により、運用担当者は運用管理システム内で戦略を迅速に作成・展開し、データを収集・監視することが容易になります。
• 統合 R&D 機能管理には、各モジュールが抽象化され、独立して管理および保守される戦略的な運用フレームワークの構築が含まれ、R&D におけるさまざまなロジックの統合処理が容易になります。
• スケーラビリティを強化します。将来、ビジネスが外部シナリオに拡大した場合、より多くの外部チャネルをカバーし、対象を絞った操作をサポートできます。

上記のシナリオに基づいて、現場意思決定システムは、シナリオ、インスタンス、戦略、ルール、タグを含む 5 層構造と対応する機能をサポートすることを目的としています。

II. 専門職名の説明

III. システムフレームワーク

まず、製品の観点から現場意思決定システムのアーキテクチャ設計を検討してみましょう。これは5つのレイヤーで構成されています。

1. シーンレイヤー

シナリオ層とは、交通シナリオ、決済シナリオ、プロモーションシナリオなど、意思決定エンジンが呼び出されるシナリオを指します。システムがシナリオ層に接続して使用する必要がある場合、システムはシナリオプロバイダーとなり、シナリオ意思決定エンジンに接続します。

2. インスタンス層

製品の観点から見ると、インスタンスレイヤーとは、特定のシナリオ内で行われた変更の具体的なインスタンス、つまり変更が実際に適用される場所を指します。例えば、プロモーションシナリオでは、特定のプロモーションアクティビティIDがインスタンスであり、これは意思決定エンジンが実際に動作する具体的なエンティティです。同様に、トラフィックシナリオでは、特定のページIDまたはリソーススロットIDがインスタンスであり、これはトラフィックの分配が実際に行われる具体的なエンティティです。

3. 戦略レイヤー

このインスタンス内の戦略レイヤーは、効果的な意思決定戦略を設定します。基本戦略は、どのようなルールに基づいてどのようなアクションを実行するかを決定します。つまり、戦略はルールと決定という2つの部分で構成されます。決定はシナリオインスタンスと関連しており、シナリオインスタンスごとに設定可能な決定が異なります。例えば、トラフィックレイヤーの決定は表示する資料の種類であり、プロモーションシナリオの決定はプロモーションの割引額です。

4. ルールレイヤー

前述の戦略レイヤーの一部であるルールレイヤーには、ユーザールール、プロダクトルール、カスタムルールが含まれます。ルールは主にフィールドと演算子で構成される式です。例えば、「user lifecycle = new user」は新しいユーザールールを作成します。

5. タグレイヤー

タグレイヤーは、上位のルールレイヤーが強く依存する基盤機能です。ルールはタグで構成され、タグは現場の意思決定システム全体の根幹を成すものであり、あらゆる意思決定のデータソースとして機能します。ルールと同様に、タグにはユーザータグ、製品タグ、パススルータグが含まれます。タグデータの精度が、意思決定エンジンの意思決定の精度を左右します。

研究開発の観点から見ると、現場の意思決定システムのアーキテクチャ設計は、管理側とユーザー側を明確に区別する必要があります。

管理側は業務設定のためのエントリポイントとデータを維持する必要があり、一方、ユーザー側は主に様々なユーザーシナリオにおいてインターフェース呼び出しをトリガーする必要があります。インターフェース呼び出しが行われると、管理側は管理側で設定されたデータに基づいてリアルタイムで判断を実行し、その結果をユーザー側に返します。

現場の意思決定システムの ER 図は、システムの相互作用と適用に影響を与えるため、特別な注意が必要です。

通常、シナリオには複数のインスタンスを含めることができ、各インスタンスには複数のポリシーを設定できます。各ポリシーには、同じタイプのルールを1つ設定できます。

同時に、A/B 実験を使用して戦略を構成することができ、A/B 実験には複数の実験グループを含めることができ、各実験グループは特定の決定コンテンツに対応している必要があります。

IV. ビジネスプロセス

1. ビジネス開発と統合シナリオの例

ビジネスシナリオに戦略的な運用が必要な場合は、それを電子商取引現場の運用システムに統合する必要があります。

例えば、決済シナリオでは、決済戦略設定においてユーザーグループのスクリーニングとA/Bテストのサポートが必要です。そのため、業務シナリオの「決済戦略設定」を現場の意思決定エンジンシステムに統合し、業務担当者がシナリオを選択して運用戦略を作成できるようにする必要があります。

統合する場合、開発者はシステムに新しいシナリオを作成し、A/B 実験を実行するときに観察するデータ メトリック、インスタンス データのソース、決定データのソース、特定の種類のルールがサポートされているかどうか、A/B 実験がサポートされているかどうかなど、それらのシナリオに関連するパラメーターを維持します。

同時に、新しいインスタンスを追加する必要があります。インスタンスの関連付けシナリオとインスタンスの権限設定に加えて、最も重要なのは、実際の開発で使用するためのインスタンスIDを取得することです。

構成後、開発者はコードの変更を実装するために、特定のシナリオとインスタンス向けのソリューションを開発する必要があります。

2. フィールドシステムの研究開発と保守ラベル

ビジネス担当者が特定のタグを使用する必要がある場合、フィールドシステム開発チームがタグを追加する責任があります。

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

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

重要な点の一つはラベルの重要性です。ラベルは現場の意思決定システムにおいて最も基本的かつ中核的な機能です。ラベルが不正確であれば、ルールに欠陥が生じ、誤った意思決定につながるという深刻な問題が生じます。したがって、ラベルの正確性は現場の意思決定システムにとって最も重要な保証です。開発チームによる設定とそれに続くテストによって、ラベルの正確性は最大限に高められます。問題がないことを確認した上でのみ、システムを業務部門に提供する必要があります。

標準的なタグメンテナンスロジックは、ビジネス部門が要件を提出し、開発チームがタグを追加・テストし、オンラインでリリースするというものです。リリース後に問題が発生した場合、開発チームはタグを無効化または修正することもできます。

3. ビジネス人員構成ルール

ビジネス担当者は、ドメインシステムに既に設定されているタグを利用して、任意のルールを設定できます。異なるルールタイプは異なるタグタイプで設定できます。例えば、ユーザールールを設定する場合は、ユーザータグのみを選択できます。

ラベルを選択するだけでなく、等しい、等しくない、より大きい、より小さい、含む、含まないなどの特定の演算子も選択する必要があります。

式は、ラベル、演算子、およびラベル値によって構成されます。

「AND」や「OR」などの演算子を使用して異なる表現を接続し、組み合わせ効果を実現することもできます。

ルールを構成した後、ルールの実行結果が期待どおりであるかどうかを確認するテストを実行して、ルール式の構成にエラーがあるかどうかを判断できます。

テストに合格すると、リリースされて公開され、正式に有効になります。

4. ビジネス担当者が構成戦略を適用する

ビジネス担当者は、戦略を構成する際に 2 つのシナリオに遭遇します。1 つは現場の意思決定システム内でのクローズドループ構成であり、もう 1 つはアプリケーション システム内での組み込み構成です。

現場意思決定システムのクローズドループシステムを設定する際には、まず特定のシナリオインスタンスを選択し、インスタンスに新しい戦略を追加し、戦略設定時に既に有効なルールを選択し、A/B実験を作成するかどうかを選択する必要があります。各ブランチごとに意思決定項目を設定することで、運用戦略を正常に作成できます。

たとえば、ビジネス担当者が特定の支払いシナリオの支払い戦略設定内で分割払いオプションを管理する必要がある場合、シナリオベースの意思決定システムで「支払い戦略設定」ビジネス シナリオを選択できます。

まず「低リスクユーザー」ルールを選択し、次に A/B 実験を設定します。

転換率が 50% のコントロール グループが選択されました。

転換率が 50% の実験グループを選択します。

各ブランチには具体的な決定が設定されます。例えば、低リスクユーザー向けのコントロールグループは3つのフェーズで構成され、低リスクユーザー向けの実験グループは6つのフェーズで構成されます。

さらに、アプリケーションシステム内に設定を組み込むというシナリオもあります。ビジネスユーザーは、現在のビジネスシステム内のルールを直接選択し、ビジネス設定を完了できます。

この時点では、業務担当者は現場の意思決定システム内の設定を操作していませんが、実装フレームワークの観点から見ると、シナリオ、インスタンス、戦略を含む新しい設定を現場の意思決定システム内に作成することと同等です。戦略には、選択されたルールと具体的な意思決定が含まれます。

設定方法に関係なく、最終的な戦略設定が完了したらインスタンスを公開する必要があり、インスタンスが有効になって初めてシステムが正式に起動されます。

ここで重要なのは、デプロイメント戦略ではなく、デプロイメントインスタンスであるということです。

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

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

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

5. クライアント側の実行フロー

ユーザ側プロセスが特定の業務シナリオに到達すると、まずこの特定の業務シナリオに基づいて対応するシナリオインスタンスIDを識別し、現場意思決定システムにこのシナリオインスタンスIDに有効なポリシーがあるかどうかを判断し、ある場合は対応するポリシーを実行してポリシー実行結果を出力する必要があります。

たとえば、ユーザーが注文をし、利用可能な分割払いの回数を決定する必要があるとき、現場の意思決定システムに支払い用の進行中の運用戦略が設定されている場合は、その戦略のビジネス構成、ユーザーがその戦略のルールに一致したかどうか、どの A/B テストブランチが一致したかを読み取り、対応するビジネス上の意思決定を実行します。

V. ラベリングシステム

1. タグのライフサイクル

人生と同じように、ラベルも誕生から死に至るまでの過程を経ます。

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

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

そのため、タグが公開されて起動されると、ドラフト版とオンライン版の2つのバージョンが生成されます。編集はドラフト版の編集となり、実行ごとにオンライン版が実行されます。

タグがリリースされた後、問題が見つかった場合は無効にすることができます。

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

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

第二に、一部のタグは既にルールで使用されており、ルールは戦略で使用されており、戦略は既にユーザーフローに実装されています。タグを軽率に削除すると、影響の評価が困難になり、リスクは大きくなります。

そのため、タグにエラーが見つかった場合は、タグを無効にすることができます。タグを無効にすると、後でルールを作成する際にそのタグは使用できなくなります。ただし、既にそのタグを使用していて現在有効なルールは、影響を受けることなく、引き続きそのタグを使用してルール評価を実行できます。タグを完全に削除したい場合は、対応するルールをリストから削除してください。

無効なルールには必ず有効なルールが存在します。有効なルールは、タグが利用可能であり、ルール作成時に使用できることを示します。

2. タグの種類

タグは種類によって区別する必要があります。まず、タグの種類によって入力パラメータの要件が異なります。例えば、ユーザータグの場合、決定入力パラメータはuidである必要がありますが、製品タグの場合、決定入力パラメータはskuidです。つまり、入力パラメータと実行ロジックが異なります。

一方、最も基本的なデータであるタグは型を区別するために使用することができ、これは後続の上流のルールや戦略が型を継承するのに役立ち、それによってすべての段階で型の統一を実現します。

もちろん、システムのメンテナンスやビジネスの検索を容易にするために、セカンダリタイプのタグをカスタマイズすることもできます。

一般的なタグ カテゴリは次のとおりです。

• ユーザー タグ: クエリは、ユーザー ID を入力パラメータとして使用して実行でき、さらにユーザー ID タグ、ユーザー財務 (リスク) タグ、ユーザー アクティビティ タグ、およびユーザー トランザクション タグに分類できます。
• 製品タグ: skuid パラメータでクエリします。これは、製品、価格、売上、ブランド、店舗、プロモーション、品質などのディメンションにさらに細分化できます。
• 注文タグ: 入力パラメータとして orderid を使用してクエリされます。主に注文レベルのタグです。
• カスタムタグ: 入力フィールドに制限はありません。つまり、任意のフィールドを入力としてクエリし、対応するタグ値を決定できます。「チャネル」や「端末タイプ」などの一般的なタグはこのカテゴリに該当します。ただし、シナリオで戦略を設定する際に、そのシナリオがドメイン意思決定システムに統合されている際に、ルールで使用できるカスタムタグをドメイン意思決定システムに透過的に渡す必要があります。例えば、シナリオで「チャネル」タグを使用する場合、ドメイン意思決定システムを呼び出す際に「チャネル」フィールドとその値を渡す必要があります。そうしないと、意思決定は失敗します。

3. タグソース

タグのデータソースは通常複数あります。ユーザータグを例に挙げると、ユーザーパッケージをアップロードしてユーザータグを作成すること、他のシステム（ビッグデータT+1バッチ実行タグなど）からフィールドを呼び出すこと、カスタムインターフェースを介してタグを生成すること、そしてフィールドを渡すことによってタグを渡すことが一般的にサポートされています。

タグ ソースが異なるということは、フィールド データ ソースが異なることを意味し、タグに設定されている特定のフィールド コンテンツも異なることを意味します。

これは、カスタム インターフェースによって生成されたフィールドの方がリアルタイム パフォーマンスが優れていることを示していますが、構成もより複雑で専門的であり、これがタグを R&D チームが構成する必要がある理由の 1 つです。

ユーザーパッケージ/製品パッケージなどのタグの場合、パッケージは毎日バッチ実行され、クエリもサポートされる必要があることに注意してください。これはリソースへの負荷が高いため、通常は有効期限が設けられています。有効期限を過ぎると、リソースの無駄を避けるため、パッケージは実行されなくなります。

さらに、タグ値を取得するためのリクエストごとに、基盤となるAPIまたは外部システムへのクエリを実行すると、パフォーマンスに負荷がかかりやすくなります。ページトラフィックの増加は、他のシステムをクラッシュさせる可能性があります。そのため、タグには通常、3分などのキャッシュ時間が設定されています。

つまり、ユーザーがこのタグ値をリクエストすると、3分間のキャッシュが作成されます。この3分以内のリクエストは、基礎となるデータクエリをトリガーすることなく、キャッシュから直接値を取得します。3分経過するとキャッシュは期限切れとなり、それ以降のリクエストは新たな基礎となるデータクエリをトリガーします。

4. フィールドタイプ

フィールドタイプは主に正規表現の機能に影響します。フィールドタイプによってサポートされる正規表現の演算子は異なります。一般的なフィールドタイプは次のとおりです。

例えば、数値フィールドのみを選択した場合、ルールを作成する際に「より大きい」または「より小さい」演算子を選択できます。ただし、フィールドがテキストの場合、「より大きい」演算子を選択すると、比較は実行されません。

列挙型の場合、タグ作成時にフィールドの列挙値を入力する必要があります。フィールドの列挙値を入力した後でのみ、ルール作成時にフィールド値を入力する際に​​ドロップダウンメニューから選択できるようになります。

列挙値が不明な場合は、テキスト型のみ選択できます。ルール作成時にフィールド値を入力する場合は、テキスト値のみ選択でき、テキスト値に基づいて直接マッチングが実行されます。

5. ラベルテスト

タグを作成した後、デプロイする前にテストに合格する必要があります。これは、タグ設定の正確性を確認し、誤った設定でのデプロイを回避するためです。誤った設定でデプロイされると、ビジネスユーザーがルール作成時に誤ったタグを使用する可能性があります。

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

例えば、ユーザーのライフサイクル全体にわたってタグ付けを行う場合、UIDを入力し、出力値を観察する必要があります。新規ユーザーのUIDであれば、タグの出力は「新規ユーザー」となり、期待通りの結果となります。一方、「リピーターユーザー」であれば、期待通りの結果にはなりません。

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

6. タグの適用

タグを作成して公開すると、任意のルールで選択して使用できるようになります。タグ側から見ると、どのルールで使用されているかを認識する必要があります。

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

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