Weibo広告戦略エンジニアリング、スタイルとシナリオ

概要

1. 広告スタイルとシナリオ

上の図は、Weibo 広告の現在の商業シナリオフロー、「1 つの画面、4 つの主要なフロー」を示しています。 「ワンスクリーン」とはWeiboの開設ファッションを指し、「四大フロー」とはWeiboの商業化の主体を指し、関係情報フロー、ホットフロー、コメントフロー、ホット検索フローが含まれます。右の写真は広告配信の背景を示しています。

2. 広告参加者

上図に示すように、コンピュテーショナル広告はまずこれらの概念に直面します。異なる広告主の規模と企業にとっての重要性に応じて、KAカテゴリと中小規模カテゴリに分類されます。 KAカテゴリーは大量購入が多い傾向にあります。中小規模のカテゴリーでは常連のお客様が入札していただきます。

一般的な課金方法には、CPE、CPM、CPD などがあります。

現在、インターネット市場ではOCPXが大規模に推進されています。OCPXは高度な技術内容が求められる販売方法であり、広告主のリスクを軽減する優れた方法でもあります。

3. 計算広告の核心的問題

広告には、プラットフォーム（サイト）、ユーザー、広告主の 3 つの関係者が関与します。計算広告設計における中心的な課題は、3 つの関係者の間でバランスを取りながら全体的な関心の最大化を追求することです。

4. 広告プロセス

上記が一般的な広告プロセスです。これは、広告主、プラットフォーム、ユーザーの観点から見た 3 方向の「移動」活動です。

広告およびマーケティング計画のプロセス: プロモーション プランの作成 -> オーディエンス ターゲティングの選択 -> 広告予算の設定 -> 広告の創造性の設定 -> 広告の開始 -> 広告の結果の確認 -> 次のマーケティング決定の実施。

精密な広告配信: 広告インベントリのリクエストに応じて、ユーザーを正確にプロファイルし、広告を呼び出し、広告の大まかな分類と細かい分類を実行し、広告を選択し、さまざまなプラットフォームに基づいて広告クリエイティブをレンダリングし、最終的にユーザーに表示します。

ユーザーによるコンテンツの消費は比較的簡単です。図のプロセスをご覧ください。

Weibo広告戦略エンジニアリングアーキテクチャの進化

1. Weibo広告エンジニアリングアーキテクチャの開発の歴史

Weibo の商業化プロセスが進展するにつれて、商業化をサポートするエンジニアリング アーキテクチャは、特定のビジネス ニーズに応じて変化します。

当初は非情報フロー広告を行っていました。従来の方法でWeiboにバナーをいくつか掲載しようとしましたが、現在、Weiboのモバイル版ではバナーは利用できなくなりました。バージョン 1.0 のシンプルなポップアップ広告システムからバージョン 2.0 の Fanstong に代表される製品ラインまで、Weibo は情報フロー広告の開発を始めました。微博は国内初の情報流通型広告会社であり、模索する中で一連の広告商品マトリックスを開発し、商品を迅速に発売するために大量の広告システムを模倣した。この状況を変えるために、2017年末のSuper Fans Passの発売を機に、広告システム全体を再構築した。それ以来、微博の広告エンジニアリングアーキテクチャは4.0時代に入った。

2. 配信システムアーキテクチャ 4.0

上の写真は2017年のエンジニアリングアーキテクチャ図で、Weiboの広告製品ラインの開拓とともに進化したエンジニアリングアーキテクチャの4.0バージョンです。当時はトラフィックのブルーオーシャン段階にあったため、広告主と広告予算の継続的な増加に協力して、広告システムの安定性、高可用性、高同時実行性を継続的に向上させ、広告収入の継続的な成長を実現しました。そこで、システムも階層化して整理しました。図の青い部分がオンライン広告システムの中核リンクです。広告リクエストを通じて、Weiboの複数の製品マトリックスを含むトラフィックが均一にアクセスされます。広告リクエストは複数の製品マトリックスに分散され、統一されたトラフィック価格評価を通じてユーザーのリクエストに応答します。全体として、このようなエンジン構造は、製品の顧客ニーズを継続的に満たすように設計されています。

基本的なプロセスは、広告リクエスト、広告インベントリへのアクセス、全体的なトラフィックの分配、ユーザー ポートレートのリクエスト、サービスの入札、広告のトリガー、オンライン インデックス サービスのリクエストであり、次のような比較的完全な行動ターゲティング システムを形成します。

1. ユーザー行動ターゲティング。トピックでのインタラクション、人気の Weibo 投稿でのインタラクション、ホットな検索グループでのインタラクションなど、Weibo での行動ターゲティング。

2. 社会関係志向。例えば、あるビッグV情報下のユーザーグループが自然と形成されたソーシャルグループとして把握できる場合、このビッグV情報下のファングループを選択して配信することができます。

3. 正確なオーディエンスターゲティング。プラットフォームや第三者によるデータ処理、単一キャンペーンの効果に基づく広告主による想起、既存顧客情報などによって形成されたユーザー粒度で集約されたデータパッケージであり、精緻なユーザーの集合体です。

4. ユーザー属性ターゲティング。ユーザーのプロフィール、年齢、地域などを含みます。

上記はオンライン配信の全体的なプロセスですが、配信プロセスは上記だけでは十分ではありません。パーソナライズされた在庫戦略、広告のネガティブフィードバック戦略、インテリジェントな頻度制御戦略なども含まれており、A/Bテストシステムのサポートも含まれており、広告配信のオンラインサービスグル​​ープを形成しています。

トラフィックはWeiboサイトから来るため、Weibo広告リクエストではトラフィック不正防止は必要ありません。既存の不正防止対策は主にインタラクティブなフィードバックを対象としており、つまり、広告後のリンク後のデータのフィードバックに対する大規模な不正防止戦略があり、もちろんソーシャルインタラクションも含まれます。次に、広告主に必要なレポートを提供するリアルタイム決済センター、つまり決済システムと、広告主に密接に関係するアカウントシステムがあり、一般的には投資後のリンクのためのオンラインサービスグル​​ープを形成します。

以下はニアラインデータアクセスです。これは、ユーザー基本データ、広告ターゲティングデータ、広告リアルタイムストリーミングデータ、アルゴリズムモデルトレーニングデータ、広告クリエイティブライブラリデータというデータ分類に基づいており、オンラインリアルタイムアクセスのニーズを定式化しています。

一番下はオフライン データ ウェアハウスです。オンラインで公開されたデータはデータ ウェアハウスに保存されます。

これは広告データ バスです。データ フローは通常、Kafka メカニズムを通じて実装され、その後データ ウェアハウスに集められてデータが分類されます。

写真左端の広告の監視システムは、業務の運用状況、サービスの安定性、システムの可用性をあらゆるレベルで監視します。これらはビジネス レベルの完全なツール チェーンです。複数の製品ラインが徐々にこのようなシステムに集約されることがわかります。

4.0 時代のアーキテクチャは、全体として、「大規模な成長」のために設計されたエンジニアリング アーキテクチャ システムです。この大幅な成長の客観的な現実は、広告数の増加が、広告予算供給の継続的な増加、Weiboによるトラフィック収益化規模の継続的な供給、および広告主の数、予算、規模の継続的な増加を通じて達成されているということです。現時点では、システムにとって最大の試練は、システムの高可用性と、ビジネス ニーズを満たす際の研究開発効率の保証です。このようなアーキテクチャは、「大幅な成長の成果」です。

このアーキテクチャ システムにはいくつかの問題があります (つまり、赤いボックス内の問題です)。戦略モデルの観点からは比較的軽視されており、つまり、機能アーキテクチャ レベルから見ると、アルゴリズム モデルの反復は比較的単純です。例えば、A/B テストは、非常に原始的な A/B テストを使用しており、人口ボーナス下では広告ビジネスの成長を迅速にサポートできます。しかし、人口ボーナスが消滅すると、広告ビジネスの成長をうまくサポートできなくなります。このとき、戦略モデルに対するシステムのサポートが非常に重要になります。

3. システムがどのように広告成長の変革をサポートするか

広告成長の変革をどのようにサポートするかは、広範な成長（トラフィックの拡大、広告主の拡大、予算の拡大）から洗練された成長への変革を通じて、配信効果を継続的に向上させ、収益成長を促進します。このとき、システムの継続的な改善に基づいて戦略モデルの良好な駆動を実現するために、対応するシステムを変革する必要があります。この場合、アルゴリズムが新しいディープラーニング モデルを導入し続けるにつれて、全体的なエンジニアリング アーキテクチャも継続的に改良され、元のビジネス分割方法 (ターゲット、フィルター、ランク) からアルゴリズム戦略 (リコール、モデル、メカニズム、ソート) を重視した分割方法へと変化します。

4. トラフィックファネルモデル

広告システムで一般的に使用されるモデル: トラフィック ファネル モデル。再考して再定義します。まず広告をリコールし、精度に基づいて最大確率の表示を完了し、次に関連性を選択して、モデルを中核とする入札およびランキングのメカニズムに進みます。

この記事では、アルゴリズムの観点から再現率と関連性のメカニズムを説明するのではなく、主にエンジニアリングがアルゴリズム モデルの反復をどのようにサポートするかを紹介します。

5. 次世代戦略指向デリバリーアーキテクチャ

アーキテクチャ システム 4.0 に基づいて、オンライン配信エンジンは、新しいトラフィック ファンネル モデルを満たすためにビジネス カテゴリに分類されます。重要なポイントは次のとおりです。

①トリガー、モデル、戦略のメカニズムが独立して深く発展する

このシステムは、トリガー、モデリング、戦略の反復をサポートする独立した詳細な開発を実現し、互いに影響を与えることなく迅速な反復を実現できます。

②リーンドライブ思考、デュアルコアドライブシステムの導入、アルゴリズム反復効率の解放

全体的に洗練された変革を行う際には、システムは試行を続ける必要があり、その試行には適切な試行プラットフォームが必要となるため、リーン駆動型の考え方が導入されます。オンライン リーン プラットフォームには、Faraday Experiment Platform と Faraday Lean Insight が含まれており、ビジネス モデルの反復を促進するためのより優れたツール チェーンであり、データのリアルタイム性と密度に重点が置かれています。

全体的なシステムアーキテクチャは、オンラインリーンツールプラットフォーム、オンライン配信システム、ニアラインデータアクセス、データモデル処理（露出機械学習プラットフォームとオンラインリアルタイムストリーミングメカニズム）、オフラインデータプラットフォームに分かれています。

③特徴データのリアルタイム性と密度、モデルに依存しない開発

オンライン配信サービスに焦点を当ててみましょう。サービスには、トラフィックアクセス、トラフィックトリガー、およびマルチチャネルトリガーを含むトリガーメカニズムがあります。マルチチャネルトリガーシステムの後には、モデル推定サービスを含むメカニズム戦略があります。モデル推定サービスは、粗いソートとデータトリミングを実行する集約サービスです。これは、大規模な分散推定サービスで完了します。ランク付け者は、推定に基づいて細かいランキングも実行します。

特に、粗いソートと細かいソートを行う理由について説明したいと思います。私の理解では、粗いソートは細かいソートのパフォーマンスのためであり、細かいソートは大規模で細かい計算を伴うため、パフォーマンスが対応しきれない可能性があるため、粗いソートが必要になります。また、効果を確保しながら、パフォーマンスを確保するために、複数のレベルの粗いソートが必要になります。

一番上には、Faraday Experimental Platform と Faraday Lean Insights があります。全体として、優れたエンジニアリング アーキテクチャ システムとリーン駆動型ツール プラットフォームというデュアル コア エンジンが形成されます。

6. 広告資料の正確な想起をサポートする方法

微博広告の想起メカニズムから、ユーザータグトリガー、ソーシャルコミュニケーショントリガー、精密人口トリガー、コンテンツトリガー、DNNベクトルトリガーがあります。 5ウェイトリガーの後、MIXER広告の想起レベルがまとめられ、まとめの後、粗いランキング戦略と細かいランキング戦略があります。

ここで使用される情報には、トラフィック側と広告側が含まれます。

トラフィック戦略:

ユーザープロファイル、リクエストコンテキスト、過去のインタラクション行動

広告面：

広告主情報、企画情報、クリエイティブ情報

7. DNNベクトルトリガーモデル

ここでは、ユーザー側と広告側を含めたデュアルタワーモデルを採用したディープベクタートリガーモデルを紹介します。ユーザー側は、ユーザー情報をもとに、3層ニューラルネットワークを用いてユーザー側ベクトルを生成するトレーニングを行います。広告側も同様です。全体としては、オフラインでトレーニングが完了し、次にリアルタイムのベクトル推定が行われます。次に、単純なコサインとシグモイドを使用して、2 つのタワーの接合部で相関関係が決定されます。

8. エンジニアリングアーキテクチャのトリガー

トリガーエンジニアリングシステムは、トリガーをより良くサポートする方法の観点から、対応するサービスシステムを開発しました。リコールのリクエストが行われると、エージェントがトリガーされ、デュアルタワーリコール、コンテンツ指向リコール、ユーザーポートレートリコール、正確な人口リコール、Weiboソーシャル関係リコールの5つのリコールを実行します。リコール後、Mixerが実行され、品質推定サービスと組み合わせてトリミングされます。次に、オンラインリアルタイム広告計画ライブラリデータとオフラインデータは、需要に応じて 5 つのオンライントリガーにアクセスし、全体的な広告トリガーエンジニアリングアーキテクチャを形成します。

リーン チャネル思考ツール: 「2 翼プラン」

2017年のSuper Fansの立ち上げにより、Weibo広告が広範な成長から洗練された成長へと変化していることを考えると、より優れた実験プラットフォームと、リーン駆動型思考の源泉となるオンライン運営インサイトの方法とアイデアが必要です。これは、オンライン戦略の実験と調整、およびオンライン戦略運用のリーンインサイトを獲得するための2つの部分で構成されており、オンライン配信システムと合わせて、統合された2翼戦略エンジニアリングアーキテクチャシステムを形成します。

1. ファラデー実験プラットフォーム

① ファラデー成層実験モデル

ファラデーの実験では、百度のエジソンやアリババのテスラなど、インターネット業界で一般的に使用されている直交階層モデルを採用した。微博ファラデーモデルの発想は、グーグルの直交交通分解モデルに関する古典的な論文から来ており、多層独立実験の理論的根拠を提供している。もちろん、実験は微博広告の実際の状況も取り入れており、最初から問題を一から解決し、論文のモデルを簡素化している。当初はドメインという概念はなく、各層でハッシュ関数が使用されていました。

②実験のバケット化

各実験層はハッシュ関数を共有していますが、トラフィック識別子や実験 ID 識別子などのハッシュ関数パラメータは異なり、異なる層のトラフィック バケット分割が直交していることを示しています。また、Googleの論文で言及されている割り当て条件も紹介されています。シナリオの適用は非常に古典的です。たとえば、実験を行うときに、トラフィックの再利用や、実験の地域、性別など、実験のいくつかの特性を考慮します。このように、すべてのトラフィックの代わりに、丸で囲まれたトラフィックまたは制限されたトラフィックが使用されます。すべてのトラフィックを使用すると、実験効果が有意ではなく、実験効果が薄れ、不信感を引き起こしやすくなります。これにより、トラフィックを再利用し、戦略の実験効果を十分に観察できるようになります。これらは、トラフィック バケット タイプとトラフィックの区分の割り当て条件です。

③ ファラデー実験台

これは、ファラデー実験プラットフォームの全体的なアーキテクチャ図です。完全に自動化されたメカニズムを採用します。ファラデーのウェブポータルを通じて、実験情報が記録され、実験はオンライントラフィックの入り口で発行および分析され、実験データ情報に基づいてオンライン戦略が調整されます。実験ヒットデータが分析され、実験が埋め込まれ、その後、リアルタイム分析エンジンに入り、実験結果をカウントします。

実験を発行して分析する方法は 2 つあります。

1 つの方法は、トラフィックの全体の入り口で実験を一律に送信して解析し、すべてを 1 つのステップで実行し、要求情報を一緒に送信し、要求リンクをたどって、最後に戻ることです。ヒットした戦略には、対応する識別が与えられます。実験の数が比較的少なく、分析にストレスがなく、実験相関分析が比較的小さく、実験が消費する帯域幅が少ない場合は、これが適切です。しかし、実験の規模が大きくなると、現在の広告システムは分散システムであるため、完全な実験情報が常にリクエストとともに送信されると、帯域幅の消費が非常に大きくなり、返される結果がタイムアウトし、可用性が低下し、実験時間が非常に長くなります。そのため、対応するサービスが対応する戦略の実験条件をそれぞれ分析し、他の戦略の実験条件を分析する必要がないという別の方法が生まれました。このようにして、興味のある情報のみが得られ、情報の冗長性が回避されます。

なぜ最初からそのような設計がなされなかったのでしょうか? なぜなら、このシステムは当初、1 つから多数へと進む問題ではなく、何もないところから何かを生み出す問題を解決するために設計されたからです。最初のステップは、実験プラットフォームを作成することです。最初の方法は比較的簡単で、実験をすぐに開始できます。

④ 広告側でのA/B実験

一般的に使用される A/B 実験は、トラフィック側のバケット実験であり、異なるトラフィック比率に基づいて異なる実験を比較します。ただし、このトラフィック側のバケット化実験では、一部の広告ニーズを満たすことができません。実際の広告システムでは、特定の広告業界や広告主を対象とした実験的な戦略があり、関心のある実験結果は、関心のある広告業界や広告主の結果でもあります。トラフィック側の実験を使用することは不可能ではありませんが、実験結果を分析する際には、データ分析を広告主レベルに特化させる必要があり、統計分析エンジンに大きな課題をもたらします。これを行わず、全体的な効果のみを考慮すると、実験分析の効果が必然的に薄れ、戦略の重要性を正確に反映できなくなります。これには、広告側の実験のためのメカニズムの設計が必要です。

まず、広告主、広告カテゴリ、広告プラン、広告の創造性など、実験対象を特定します。

次に、均質または非均質の実験を実行します。

同質的な実験（プロモーション計画の対象者をランダムに 2 つに分け、2 つの区分に基づいて異なる戦略を比較する）では、1 つの計画に対して「疑似計画」に類似した 2 つのコンセプトが作成され、その後、疑似計画が同時に体系的に開始される可能性があります。人口を 2 つのグループに分けて、結果を比較します。

非均質実験とは、実験を行うために選ばれた人々のグループが行う実験です。この実験では、多くの場合、コントロールがなく、実験結果に基づいて縦断的に判断されます。つまり、現在の戦略実験結果が、これまでに実施されていない実験の戦略操作結果と比較されます。

⑤ 広告予算による独立したA/B実験

広告実験プラットフォームが特定の広告実験で遭遇する可能性のある問題は、非広告ビジネスでは発生しません。広告分野には、A、U、C の 3 つの当事者が関与しているためです。この 3 つの当事者は、効果的な完全なループを形成します。単純なループでは、計画された配信 -> 支出 -> オフラインでの広告を考慮に入れます。ここに予算が関与しており、予算がなくなると広告はオフラインになります。ここで問題があります。トラフィックを 2 つの部分に分割し、異なる戦略を使用して、単純なトラフィック バケット化の実験を行うと、これらの 2 つの戦略の結果は、広告主の予算の消費率が異なります。その結果、特定のバケット (50-50) が一定期間にわたって急速に消費された場合、予算が独立していないと、バケット B の予算が引き継がれます。具体的には、広告主のお金はバケット A に多く費やされます。トラフィックが少ない場合は効果が非常に良いかもしれませんが、トラフィックが増加し続けると、戦略の実験効果が非常に小さくなることがわかります。そのため、広告主側で実験を行う際には、広告予算の独立性を考慮します。例えば、プランを2つに分け、予算を均等に配分することで、それぞれが独立し、お互いに影響を与えないようにします。最後に、予算独立実験をトラフィック バケットに適用することを検討します。これはまだ実行されていませんが、実行可能であることが証明されています。

⑥ 実験テストと効果評価

実験テストと効果評価はリアルタイムの効果評価であり、5分以内のデータ遅延を実現できます（保守的に）。1分も許容されますが、問題は広告効果の測定にあります。たとえば、ctr =インタラクション/露出の場合、インタラクションが遅れて計算結果が不安定になる可能性があります。したがって、実験効果を安定させるために、5分ごとに計算します。

複数日にわたる実験効果を分析するために採用されたメカニズムは、オフラインクロスデイ + リアルタイムストリーム分析エンジンです。リアルタイム ストリーミング メカニズムはオフライン メカニズムほど効果的ではないため、ここではいくつかの最適化を行いました。たとえば、このようなタスクのオフライン スケジューリングを数時間前に実行できる場合は、オフライン バッチ処理を使用して、今日の早い時間のリアルタイム ストリーミング分析データを置き換えます。リアルタイム ストリーミングでは、1 時間または 2 時間などの最新のデータを使用する傾向があります。実験の意思決定の観点から、リアルタイムストリーミングは主に、実験結果が重大な欠陥を引き起こすかどうかを判断し、実験を適時に終了するために使用されます。オフラインデータ処理によってもたらされるリアルタイムレポートは、主に実験結果を評価するために使用されます。

全体的な実験効果の可用性が監視され (たとえば、トラフィック バケットの監視。異なる戦略ではトラフィック レベルでの可用性が異なります)、2 つの実験バケットの可用性が同じレベルであることを確認します。

実験的なプラットフォームは、約 4,000 万から 1 億に及ぶビジネス指標をサポートし、カスタム指標もサポートします。同時に、この実験ではバージョン追跡と nodiff 制御実験もサポートされています。

2. 広告リーンインサイト

Lean Insightが解決したい問題は、オンライン戦略が多数あるため、戦略実行中にシステムの動作状況をシステム外部でどのように可視化し、戦略操作を水のように透明にできるかということです。その後、Lean Matrix記述法が提案されました。全体のビジネスは複数のレベルのビジネスステージに分割され、各ステージで完全な洞察が得られます。

上図はシステムアーキテクチャ図です。データが到着すると、リアルタイムストリーミングメカニズムに入ります。リアルタイムストリーミングメカニズム内のデータカテゴリは、キーによって分類され、相互に関連付けられます。ログ構造はコンポーネント化されており、オンラインデバッグログ、ユーザー情報ログ、オンライン戦略およびモデル実行ログ、広告ログなどが含まれます。さらに、ログ処理と保存が行われ、オフラインストレージとオンラインストレージに分かれています。オンラインストレージは、PGやclickHouseなどの列指向ストレージを使用して、オンラインで即座にアクセスします。

全体的なプレゼンテーション効果は次のとおりです。各レイヤーはビジネス戦略の段階です。リクエストアクセスまたは広告リコールセットの処理は、全体としてファネルであり、広告の数の観点からは2次元です。戦略の実行に伴い、広告リコールセットの数は継続的に減少します。さまざまな入札タイプの分布や全体的な入札レベルなど、各レベルをより詳細に表示して、さまざまな戦略レイヤー間のパフォーマンスの違いを特定し、戦略の具体的な影響を把握することができます。

著者: DataFunTalk

出典: DataFunTalk