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

電子商取引の運用においては、洗練された運用が効率性と効果性を向上させる鍵となります。本稿では、eコマース業務の3つの中核となる「人・モノ・場所」を軸に、現場の意思決定エンジンを構築することで、洗練された業務を実現する方法について詳細に解説します。

電子商取引の運営は、人、物、場所などさまざまな次元に基づいた洗練された運営システムです。一言で説明すると、特定のシナリオにおいて、指定されたユーザーと指定された商品に対して、指定されたビジネスアクションが実行され、対応するビジネスデータが観測されることを意味します。

前回の記事でも述べたように、電子商取引の運用は、マーケティング システム、ゴールデン プロセス、プロモーション システムなどを含む非常に大規模なシステムです。各システムが独自のシナリオ、チャネル、ユーザー、製品、その他の戦略ルールを維持している場合、各システムは独自のロジックで構成され、日常的なメンテナンスが困難になります。開発コストが高くなるだけでなく、運用効率も非常に低くなります。

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

この記事では、以下のディレクトリからフィールド Juce エンジンを構築する方法を 2 つの記事に分けて説明します。

1. 背景

II.職業名の説明

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

4. ビジネスプロセス

5. ラベリングシステム

6. ルールシステム

7. 戦略システム

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

9. 戦略ツリー

10. よくある質問

1. 背景

電子商取引事業者は、日々の業務において、ユーザーに対して洗練された運用と転換テストを実施し、最良の運用結果を達成する必要があります。たとえば、特定のユーザーにクーポンを発行し、どのクーポンがこれらのユーザーにとって最もコンバージョン効果が高いかをテストすることができます。

このプロセスには、ユーザー グループの精緻なスクリーニングと、ユーザー転換に関する正確な実験が含まれます。

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

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

上記のシナリオに基づいて、現場意思決定システムは、シナリオ、インスタンス、戦略、ルール、ラベルの 5 層構造と対応する機能をサポートする予定です。

II.職業名の説明

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

まず、製品の観点から現場意思決定システムのアーキテクチャ設計を見てみましょう。合計で 5 つのレイヤーがあります。

1. シーンレイヤー

シナリオ レイヤーとは、トラフィック シナリオ、支払いシナリオ、プロモーション シナリオなど、意思決定エンジンを呼び出して使用するシナリオを指します。接続して使用する必要があるシステムがあれば、現場の意思決定エンジンに接続された、現場のパーティと同等になります。

2. インスタンス層

製品の観点では、インスタンス レイヤーはシナリオ内の特定の変更のインスタンスを指し、実際の効果が発生する場所です。たとえば、プロモーション シナリオでは、特定のプロモーション アクティビティ ID がインスタンスになります。これは、意思決定エンジンが実際に動作する特定のエンティティです。たとえば、トラフィック シナリオでは、特定のページ ID またはリソースの場所 ID がインスタンスになります。実際にトラフィック分散の役割を果たす特定のエンティティです。

3. 戦略レイヤー

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

4. ルールレイヤー

ルール レイヤーは、上記の戦略レイヤーの説明の一部であり、ユーザー ルール、製品ルール、カスタム ルールなどが含まれます。ルールは主に、フィールド + 演算子で構成される式です。たとえば、ユーザー ライフ サイクル = 新しいユーザーは、新しいユーザー ルールを形成します。

5. ラベルレイヤー

ラベル レイヤーは、上位のルール レイヤーが強く依存する基盤となる機能です。ルールはラベルで構成されます。ラベルは、現場の意思決定システム全体のルートであり、すべての意思決定のデータ ソースです。ルールに従って、タグにはユーザー タグ、製品タグ、透明タグなどが含まれます。ラベル データの正確さによって、意思決定エンジンの決定の正確さが決まります。

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

管理側ではビジネス構成のエントリとデータを維持する必要があり、ユーザー側では主にさまざまなユーザー シナリオのインターフェイス呼び出しをトリガーする必要があります。インターフェースが呼び出されると、管理側で設定されたデータに基づいてリアルタイムに判断が行われ、判断結果がユーザー側に返されます。

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

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

同時に、1 つの戦略を AB 実験で構成することができ、1 つの AB 実験には複数の実験グループを含めることができ、各実験グループは特定の決定内容に対応している必要があります。

4. ビジネスプロセス

1. ビジネス開発アクセスシナリオ例

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

たとえば、支払いシナリオの支払い戦略構成では、ユーザー層をスクリーニングし、AB 実験をサポートする必要があります。この場合、業務シナリオ「支払戦略構成」を現場意思決定エンジンシステムに接続し、業務担当者がシナリオを選択して運用戦略を作成できるようにする必要があります。

アクセス中、R&D 担当者はシステム内に新しいシナリオを作成し、シナリオ内で AB 実験を実行するときに監視する必要があるデータ インジケーター、インスタンス データのソース、決定データのソース、特定の種類のルールがサポートされているかどうか、AB 実験がサポートされているかどうかなど、シナリオの関連パラメーターを維持します。

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

構成が完了したら、シナリオとインスタンスを開発し、コードに実装するために R&D が必要になります。

2. フィールドシステム開発・保守ラベル

ビジネス担当者がタグを使用する必要がある場合、フィールド システムの R&D チームがタグの追加を担当します。

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

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

1つはラベルの重要性です。ラベルは、現場の意思決定システムの最も基本的かつ中核的な機能です。ラベルが間違っていれば、ルールも間違ったものになり、決定も間違ったものになります。これは非常に深刻な問題です。したがって、ラベルの正確さは、現場の意思決定システムの主な保証となります。 R&Dによる構成と構成後のテストによりラベルの精度を最大限に高め、問題がないことを確認した上で業務利用向けに納品いたします。

従来のタグ保守ロジックは、ビジネス部門が要件を提示し、R&D 部門が追加およびテストを行い、オンラインでリリースするというものです。オンライン化後に問題が発生した場合、R&D はそれを無効化または変更することもできます。

3. 業務人員構成ルール

業務担当者は、現場システムで有効にしていたタグを利用して、自由にルールを設定できます。異なるタグ タイプを使用して、異なるルール タイプを構成できます。たとえば、ユーザー ルールを構成する場合、ユーザー タグのみを選択できます。

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

ラベル + 演算子 + ラベル値が式を構成します。

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

ルールの構成が完了したら、ルールの実行結果が期待どおりかどうかをテストして、ルール式の構成が正しいかどうかを判断できます。

テストに合格すると、オンラインで公開され、正式に有効になります。

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

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

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

たとえば、一部のビジネス担当者は、支払いポリシー構成において、支払いシナリオや分割回数に関する戦略的な操作を実行する必要があります。フィールド決定システムで、ビジネス シナリオ「支払戦略構成」を選択します。

まず「低リスクユーザー」ルールを選択し、次に AB 実験を構成します。

転換率が50%のコントロールグループを選択する

転換率50%の実験グループを選択する

特定の決定はブランチごとに設定されます。たとえば、低リスクのユーザー コントロール グループの場合、対応する分割回数は 3 に設定されます。低リスクユーザー実験グループの場合、対応する分割回数は 6 に設定されています。

さらに、アプリケーション システムに構成が組み込まれるという別のシナリオもあります。ビジネス担当者は、現在のビジネス システム内のルールを直接選択し、ビジネス構成を完了できます。

このとき、業務担当者は現場意思決定システムで構成を操作するわけではありませんが、実装フレームワークの観点からは、シナリオ、インスタンス、戦略など、現場意思決定システムに新しい構成を作成することに相当します。ポリシーは、選択されたルールと特定の決定で構成されます。

ただし、どの構成方法を使用する場合でも、最終的なポリシー構成が完了したらインスタンスをリリースする必要があり、インスタンスが有効になってからのみ正式に起動できます。

ここで重要なのは、リリース ポリシーではなくリリース インスタンスであるということです。

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

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

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

5. ユーザー側の実行プロセス

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

たとえば、ユーザーが注文を出し、利用可能な分割払いの回数を決定する必要があるとき、現場決定システムで支払い戦略構成の進行中の運用戦略がある場合などです。ポリシーのビジネス構成を読み取り、ユーザーがポリシーのルールに一致するかどうか、どの AB 実験ブランチが一致するかを判断し、対応するビジネス決定コンテンツを実行します。

5. ラベリングシステム

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

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

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

タグのバージョン管理を標準化するため、後続のタグの編集が必要な場合はドラフト版を編集し、テストに合格したらオンラインで公開して上書き更新する、という流れになります。これにより、編集中にタグがオンライン実行に影響を与えないことも保証されます。

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

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

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

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

次に、一部のタグがルールで使用され、ルールがポリシーで使用され、ポリシーがユーザー プロセスに展開されました。ラベルを軽率に削除すると、影響を評価することが難しくなり、リスクが大きくなります。

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

無効化がある場合は、有効化も必要です。有効にすると、タグが使用可能になり、ルールを作成するときにそれを使用することを選択できるようになります。

2. タグの種類

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

一方、ラベルは最下位レベルのデータであるため、ラベルに基づいてタイプを区別することができ、後続の上流ルールやポリシーによるタイプの継承に役立ち、各リンクでのタイプの統一を実現します。

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

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

• ユーザータグ: uid 入力パラメータによるクエリ。ユーザー ID タグ、ユーザー財務 (リスク) タグ、ユーザーアクティブタグ、ユーザートランザクションタグに細分化できます。
• 製品タグ: skuid によるクエリ。製品、価格、販売、ブランド、店舗、プロモーション、品質、その他のディメンションに細分化できます。
• 注文タグ: 注文IDによるクエリ、主に注文ディメンションのタグ
• カスタム タグ: 入力フィールドには制限はありません。つまり、任意のフィールドを入力パラメータとして使用して、そのフィールドに対応するタグ値が何かを照会できます。当社の一般的なチャネルと端末タイプはすべて、このカテゴリのラベルに属します。ただし、カスタム タグを使用する場合は制限があります。シーンのポリシーを構成する場合、ルールで使用できるカスタム タグは、シーンがフィールド決定システムに接続されたときに、シーンがフィールド システムに透過的に送信されるようにする必要があります。たとえば、シナリオでチャネル タグを使用する場合、シナリオがフィールド決定システムを呼び出すときに、チャネル フィールドとフィールド値を渡す必要があります。そうしないと、決定は行われません。

3. タグソース

通常、ラベル データには複数のソースがあります。ユーザー ラベルを例にとると、通常、ユーザー パッケージをアップロードしてユーザー ラベルを形成すること、他のシステムからフィールドを呼び出すこと (ビッグ データ T+1 バッチ実行ラベルなど)、カスタム インターフェイスを通じて生成されたラベル、および透明フィールドを通じて透明ラベルをサポートすることになります。

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

このことから、フィールドがカスタム インターフェイスによって生成される場合、リアルタイムのパフォーマンスは向上しますが、構成もより複雑で専門的になることがわかります。これが、ラベルを R&D で構成する必要がある理由の 1 つです。

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

同時に、リクエストまたはタグ値が照会されるたびに、基盤となるインターフェースまたは外部システムが照会されると、パフォーマンスの低下が容易に発生する可能性があります。ページのトラフィックが増加する限り、他のシステムがクラッシュする可能性があります。したがって、タグのキャッシュ時間は通常、たとえば 3 分になります。

つまり、ユーザーがタグ値を要求すると、3 分間のキャッシュが構築されます。 3 分以内にリクエストが行われた場合、値はキャッシュから直接返され、基になるデータ クエリはトリガーされません。キャッシュは 3 分後に無効になり、再度要求されると基礎となるデータ クエリが再度トリガーされます。

4. フィールドタイプ

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

たとえば、数値フィールドのみがある場合は、ルールを作成するときに「より大きい」や「より小さい」などの演算子を選択できます。テキスト型の場合、「より大きい」などの演算子を選択しても判定は行われません。

列挙型の場合は、ラベルを作成するときにフィールド列挙値を入力する必要があります。フィールド列挙値が入力されている場合にのみ、ルールの作成時にフィールド値を入力するときにドロップダウンして選択できます。

列挙値が不明な場合は、テキスト タイプのみを選択できます。ルールを作成してフィールド値を入力するときは、テキスト値を入力し、テキスト値に基づいて直接一致させることのみを選択できます。

5. ラベルテスト

タグが作成された後、オンラインにする前にテストに合格する必要があります。これは、ラベル構成の正確性を確保し、オンラインで構成エラーが発生しないようにするためです。構成エラーが発生すると、ビジネス担当者がルールを作成するときに誤ったラベルを誤って使用してしまう可能性があります。

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

たとえば、ユーザー ライフ サイクル ラベルの場合、uid を入力し、uid 出力値が何であるかを観察する必要があります。これが新しいユーザーの uid であると仮定すると、ラベル出力値は「新しいユーザー」になる必要があり、これは期待どおりです。あなたが「古いユーザー」である場合、それはあなたの期待を満たしません。

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

6. ラベルの貼り付け

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

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

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