リード:この共有テーマは、マイクロブログ広告戦略エンジニアリングアーキテクチャの進化であり、マイクロブログ広告アーキテクチャが戦略、アルゴリズム、モデルの反復をどのようにサポートするかについて、0から1、1からNまで、以下のセクションを含む。

• 概要
  

• マイクロブログ広告戦略エンジニアリングアーキテクチャシステムの進化
  

• リーン駆動思考ツール:2つの翼計画

▌概要

1. 広告スタイルとシーン

上の写真は、マイクロブログ広告の現在のビジネスシーンの流れであり、「1つの画面と4つのストリーム」です。 "1つの画面は、Weiboを開くFashionを指し、「4つのストリーム」は、関係情報フロー、ホットストリーム、コメントストリーム、ホット検索ストリームなど、Weiboの商業化の本体を占有することを意味します。右の図は、広告配信のバックグラウンドです。

2. 広告参加者

上の図のように、コンピューティング広告は、さまざまな広告主の規模と会社への重要度に応じて、KA と中小規模のカテゴリに分類されるこれらの概念から始めています。 クラスKAは、多くの場合、幅広い購入を行います。 中小規模のカテゴリでは、通常の顧客が入札します。

一般的な請求方法は、CPE、CPM、CPD です。

現在、インターネット市場ではOCPXを大規模に推進していますが、OCPXは高い技術コンテンツを必要とし、広告主の配信リスクを低減するための優れた販売方法です。

3. 広告の核となる問題を計算します

これは、プラットフォーム(サイト側)、ユーザー、広告主の3つの側面を含む広告であり、広告デザインを計算する際の核となる問題は、3者間のバランスの取れた全体的な利益を最大化する方法です。

4. 広告配信プロセス

上記は、一般的な広告配信プロセスです。 これは、広告主の視点、プラットフォームの視点、およびユーザーの視点から、3 者間の「向き合い」のアクティビティをパブリックに行う方法です。

広いキャンプに訴えたマーケティング計画プロセス:プロモーションプログラムの作成 - オーディエンスのターゲット設定を選択します -> 広告予算を設定します -> 広告クリエイティブを設定します -> 広告配信を開始します -> 広告の掲載結果を確認します -> マーケティングの決定の次のステップ。

正確な広告配信: 広告在庫の要求に応じて、ユーザーは正確なユーザー画像を描画し、その後、広告のリコールを行い、広告を粗くし、洗練し、広告を選択し、異なるプラットフォームに応じて広告クリエイティブのレンダリングを行い、最終的にユーザーに表示します。

ユーザー コンテンツの消費は、図のフローを見て比較的簡単です。

▌マイクロブログ広告戦略のエンジニアリングアーキテクチャシステムの進化です

1. マイクロブログ広告プロジェクトアーキテクチャの開発の歴史

Weiboの商業化プロセスは絶えず発展しており、商業化を支えるエンジニアリングアーキテクチャは、特定のビジネスニーズに応じて変化します。

最初は、非情報フローの広告は、従来の方法でマイクロブログにいくつかのbannerをキャストし、現在、Bannerは、マイクロブログのモバイル側では、現在ないです。 1.0バージョンのシンプルなウィンドウ広告システムから、ファンパスに代表される製品ラインの2.0バージョンまで、Weiboは情報フロー広告の研究開発を開始しました。 Weiboは、国内情報フロー広告の最初のであり、一連の広告製品マトリックスをインキュベートし、製品の迅速なアップラインのために、多くの広告システムを複製し、この状況を変えるために、17年末に大ファンがラインに参入し、広告システムの全体的な再構築を行い、マイクロブログ広告エンジニアリングアーキテクチャは4.0時代に入りました。

2. システムアーキテクチャ4.0を投入する

上の図は、17年間のエンジニアリングアーキテクチャ図であり、Weibo広告製品ラインの探査と進化に伴い、エンジニアリングアーキテクチャ4.0バージョンは、トラフィックの青い海段階にあるので、広告主と広告予算の増加に協力することで、広告システムの安定性、高可用性、高同時性を継続的に改善し、広告収入の増加を実現しています。 だから、私たちは正しいシステムは階層的にグルーミングされ、青い領域はオンライン広告配信システムのコアリンクです。広告リクエスト、トラフィックを介して統合アクセス、アクセスは、マイクロブログ複数の製品マトリックスを含み、広告要求は、複数の製品になりますマトリックスは、統一されたトラフィック価格評価を通じてユーザーの要求に応答する要求の配布を行います。全体的にそのような引け!オプティマス構造は、顧客の要求に直面して製品によって提案されたアーキテクチャ設定を継続的に満たすために行われます。

その基本的なプロセスは、広告要求、広告在庫アクセス、全体的なトラフィックの配信、ユーザーの画像の要求、スポットサービスの後、広告トリガー、オンラインインデックスサービスを要求し、より完璧な行動指向システムを形成することです。

1. ユーザーの行動の方向。 トピックの相互作用、人気のあるマイクロブログとの相互作用、群衆の相互作用のホット検索など、Weiboでの行動の方向性。

2. 社会的関係のオリエンテーション。 たとえば、注目する大きな V メッセージの場合、ユーザーのグループが自然に形成されたソーシャル グループとして理解できる場合、この大きな V メッセージの下のファン グループは選択的に配信できます。

3. 正確な群衆のオリエンテーション。 これは、プラットフォームまたは第三者のデータ処理、または広告主が 1 回の配信結果に基づいて行うリコール、または既存の顧客情報によって形成されたユーザーの粒度集約されたパケットによって、正確なユーザーのコレクションです。

4. ユーザー属性の方向。 ユーザー画像、年齢、地域などが含まれます。

これらは全体的なオンライン配信プロセスですが、配信プロセスは、パーソナライズされた在庫戦略、広告の負のフィードバック戦略、インテリジェントな頻度制御戦略、および広告配信のためのオンラインサービスグループを形成するA/Bテストシステムを含むだけでは不十分です。

トラフィックは Weibo サイトから送信されるため、Weibo 広告リクエストはトラフィックの不正行為に対して必要ではありません。 アンチチートの存在は、主にインタラクティブなバックパス、すなわち、広告キャスト後のリンクデータのバックパスは、大規模なアンチチート戦略、そしてもちろん、社会的相互作用を持っています。 その後、リアルタイム決済センター - 決済システム、広告主が必要とするレポート、広告主と密接に関連するアカウントシステムがあり、一般的にポストリンクオンラインサービスグループを形成します。

ユーザー ベース データ、広告ターゲット データ、広告ライブ ストリーミング データ、アルゴリズム モデル トレーニング データ、広告クリエイティブ ライブラリ データなど、データ分類に従って、オンライン でのリアルタイム アクセスの必要性を決定します。

一番下のデータ ウェアハウスは、ラインの下にあります。 オンラインで配信されたデータは、データ ウェアハウスに着陸します。

これは広告データ バスであり、データ フローは、通常、kafka メカニズムなどを通じて実装され、データ ウェアハウスに集約され、データを分類します。

図の左端の広告監視システムは、システムのすべてのレベルからシステムのビジネス正常性を監視し、サービスの安定性と可用性を監視します。 これらは、ビジネス レベルで完全なツール チェーンです。 当初、複数の製品ラインは、このようなシステムに徐々に集約されています。

4.0時代のアーキテクチャ全体として「大まかな成長」のために設定されたエンジニアリングアーキテクチャシステム。この広範な成長の客観的な現実は、広告予算の継続的な増加とマイクロブログへの継続的なトラフィックの現金化、および広告数の増加、予算、および広告主の増加です。 システムの最大のテストは、システムの高可用性とビジネス要件のR&D効率の保証であり、このようなアーキテクチャは「大まかな成長の産物」です。

このアーキテクチャ アーキテクチャには、いくつかの問題 (つまり、赤いボックス) があります: 比較的ポリシー モデルが軽視され、機能アーキテクチャ レベルからアルゴリズム モデルの反復が簡単になります。 たとえば、A/B Test は、人口配当の状況で広告ビジネスの成長を急速にサポートする非常に原始的な A/B Test を使用していますが、人口配当が消えるにつれて、広告ビジネスの成長を支えるには不十分であり、戦略モデルに対するシステムのサポートは非常に重要です。

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

広告の成長を支える方法は、広範な成長(拡大、広告主の拡大、予算の拡大)を通じて、収益成長を促進する配信効果を継続的に改善する洗練された成長に移行します。 この時、対応するシステムは、戦略モデルの良好な駆動を達成するために、システムの継続的な改善に基づいて、変換する必要があります。 このような状況では、アルゴリズムが新しいディープ ラーニング モデルを導入するにつれて、全体的なエンジニアリング アーキテクチャは、元のビジネス分割方法 (Target、Filter、Rank) からアルゴリズム指向の戦略 (リコール、モデル、メカニズム、並べ替え) への移行に絶えず進化しています。

4. フローファネルモデル+

広告システムで一般的に使用されるモデル: トラフィック ファネル モデル。 再考と定義: 広告のリコールから開始し、精度に基づく最大確率表示を完了し、関連性の選択からモデル中心のスポットソートメカニズムまで。

この記事では、アルゴリズムの観点からリコールと相関のメカニズムについて説明しません。

5. ポリシー指向の次世代配信アーキテクチャ

新しいトラフィック ファネル モデルを満たすために、アーキテクチャ システム 4.0 に基づいてオンライン配信エンジンをビジネス グレーディングします。 次のキー ポイントがあります。

(1)トリガ、モデル、戦略メカニズムは、独立して深く発展します

システムは、トリガー、モデル、およびポリシーの反復をサポートする上で、それぞれの独立した深い開発を可能にし、互いに影響を与えなく迅速に反復できます。

(2)リーンドライブのアイデア、システムデュアルコアドライブ、リリースアルゴリズムの反復効率を導入します

全体的な微細変換を行うとき、システムは継続的な試みを必要とし、良い試みプラットフォームを持ってしようとするので、リーン駆動のアイデアが導入されています。 オンラインリーンプラットフォームには、ファラデ実験プラットフォームとファラデリーンインサイトが含まれます。

システム アーキテクチャは、オンライン リーン ツール プラットフォーム、オンライン配信システム、ニアライン データ アクセス、データ モデル処理 (露出機械学習プラットフォームとオンライン ライブ ストリームのメカニズム)、およびオフライン データ プラットフォームに分類されます

(3) 特徴データのリアルタイム性と密度、モデルの独立性の開発

オンライン配信サービスに焦点を当て、サービスでは、トラフィックアクセスがあり、トラフィックのトリガーがあり、マルチトリガを含むトリガメカニズムがあり、マルチトリガシステムを介して、モデル推定サービスを含むメカニズム戦略があり、モデル推定サービスは集約サービスであり、粗化、データトリミング、大規模な分散予測サービスで完了し、Rankerは予測に基づいて洗練されます。

特に、なぜ粗さや仕上げを行うのか、粗さ、仕上げの性能上の考慮事項を理解し、精算は大規模な細かい計算を伴うので、性能が耐えられない可能性があるため、粗さが必要であり、また、効果を保証する場合、性能の保証のために複数の粗さがある。

一番上には、ファラデ実験プラットフォームとファラデリーンインサイトがあります。 全体的には、デュアルコアエンジン、優れたエンジニアリングアーキテクチャ、リーン駆動ツールプラットフォームが形成されます。

6. 広告材料の正確なリコールをサポートする方法

Weibo広告のリコールメカニズムから、ユーザータグトリガ、ソーシャル伝播トリガ、正確な群衆トリガ、コンテンツトリガ、DNNベクトルトリガ、5ウェイトリガ、MIXER広告リコールレベルの要約、要約後、ラフポリシー、洗練された戦略があります。

トラフィック側や広告側など、ここで使用される情報。

• トラフィック・キュレーター：

ユーザー画像、要求コンテキスト、履歴対話動作

• 広告側:
  

広告主情報、プログラム情報、クリエイティブ情報

7. DNN ベクトルはモデルをトリガします

ここでは、ユーザー側と広告側を含むツイン タワー モデルを使用して、深度ベクトル トリガー モデルについて説明します。 ユーザ側はユーザ情報に基づいてユーザ側のベクトルを生成し,3層のニューラルネットワークを用いて広告側も同様であり,全体としてトレーニングはオフラインで行い,次にリアルタイムベクトル推定を行う. さらに双塔合流点で相関の判定を行い,単純なcosとsigmoidを用いて相関の判定を行った.

8. エンジニアリングアーキテクチャをトリガします

トリガエンジニアリングシステムは、トリガの観点から、対応するサービスシステムをどのようにサポートするかについて開発されました。 リコールの要求は、ツインタワーのリコール、コンテンツ指向のリコール、ユーザー画像のリコール、正確な群衆のリコール、マイクロブログソーシャル関係のリコール、リコール後のMixer、品質見積もりサービスと組み合わせたトリミングなど、5つのリコールのためにエージェントをトリガします。 その後、リアルタイムの広告プラン ライブラリ データとオフライン データが、オンラインの 5 つのトリガーをそれぞれニーズに基づいてアクセスし、全体的な広告トリガー エンジニアリング アーキテクチャを形成します。

▌リーンチャネル思考ツール:「2つの翼計画」

17年に大ファンが立ち上がった後、マイクロブログ広告が粗大な成長から洗練された成長に変わることを考えると、より良い実験プラットフォームと、リーン主導のアイデアの源であるライン上の洞察の方法とアイデアが必要です。 これは、オンライン戦略の実験と制御、オンライン戦略の実行のためのリーンインサイト、オンライン配信システムとともに、2つの翼戦略エンジニアリングアーキテクチャシステムを構成する2つの部分で構成されています。

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

(1)ファラデ階層実験モデル

ファラディの実験は、Baiduのエジソン、アリのテスラなど、インターネット業界で一般的に使用される直交階層モデルを使用しています。 Weiboファラディモデルのアイデアは、Googleのトラフィック直交分解モデルの古典的な論文から来て、多層独立した実験のための理論的基礎を提供し、もちろん、実験はまた、マイクロブログ広告の実際の状況を組み合わせて、最初の問題を含む、論文のモデルを簡素化します。 最初はドメインの概念がなく、全体の各層で hash 関数が使用されます。

(2) 実験分樽

各実験レイヤーは hash 関数を共有しますが、hash 関数パラメーターは異なり、トラフィック ID と実験 ID ID の ID が含まれます。 また、Google の論文で言及されている割り当て条件も導入され、シーン アプリケーションは古典的であり、たとえば、実験を行う場合、トラフィックの再利用や、実験の地域や性別など、実験のいくつかの特性を考慮して、すべてのトラフィックではなく、ラップまたは制限されたトラフィックを使用します。 これにより、トラフィックが繰り返し再利用され、ポリシーの実験効果を良好に観察できます。 これは、フロー バケット タイプとフロー ルーティングの割り当て条件です。

(3)ファラデ実験プラットフォーム

これは、ファラディ実験プラットフォームの全体的なアーキテクチャ図です。 完全な自動化メカニズムを採用します。 ファラデのWebエントリにより,実験情報の記録を行い,オンライン上のフローエントリで実験の発話と解析を行い,実験のデータ情報に基づいてオンラインポリシーの制御を行い,実験ヒットデータを解析し,実験の埋め込み点を行い,リアルタイムの解析エンジンに進み,実験効果を統計する.

実験のリリースと解析には、次の 2 つの方法があります。

1 つは、トラフィックの総入り口で実験の送信と解析を統一し、1 つのステップで配置し、要求情報を 1 つ 1 つ送信し、要求リンクが移動し、最後に戻ると、ヒットするポリシーに対応する ID があります。 実験数が少ない場合,解析はストレスなく,実験相関解析は比較的小さく,実験消費帯域幅は小さいが,この場合が適している. しかし,実験規模が大きくなるにつれて,現在の広告システムは分散システムであり,完全な実験情報が要求に応じて送信され続ければ帯域消費が非常に深刻になり,リターン結果がタイムアウトし,ユーザビリティが低下し,実験時間が長くなる. そこで,対応するサービスによって対応するポリシーの実験ケースをそれぞれ解析する一方で,他のポリシーの実験ケースは解析を必要としないため,自分の興味のある情報のみを取得し,情報の冗長性を回避する別の方法が登場した.

システムは、最初は 1 つ以上ではなく、何から何まで問題を解決するため、このような設計が最初に行われないことになったのです。 最初のステップは、実験プラットフォームの作成であり、最初の方法は比較的単純であり、すぐに実験をリリースすることができます。

(4)広告側A/B実験

一般的なA/B実験は、流量側のバケット実験であり、流量の異なる比に応じて異なる実験の比較を行う。 しかし、このトラフィック側のバケット実験は、広告のニーズの一部を満たしません。 実際の広告システムでは、特定の広告業界や広告主に対して実験的な戦略が実施され、注目の広告業界や広告主の効果にも焦点が当てられます。 フロー側で実験すればダメですが、実験効果分析を行う場合、データ分析は広告主の粒度に特化する必要があり、統計分析エンジンにとって大きな課題となります。これは、広告側の実験のためのメカニズム設計を必要とします。

まず、広告主、広告カテゴリ、広告プラン、広告クリエイティブなど、ターゲットをターゲットに設定します。

次に、同質または非同質な実験を行います。

同質な実験(すなわち、プロモーションプログラムのオーディエンスをランダムに分割し、2つに分割し、異なる戦略を2つに分けて比較する)、1つのプログラムは、「擬似計画」に似た2つの概念を作成し、その後、擬似計画に同時にシステムを投入することができる。 2つのグループの分割に入り、その後、効果を比較します。

非同質実験は,実験を行う人の波を試行的に囲み,これは実験効果による縦断的な比較判定,すなわち,現在の戦略実験効果と,以前に行われない実験の戦略運用効果とを対比して判断する傾向がある.

(5) 広告予算に関する独立したA/B実験

広告実験プラットフォームは、非広告ビジネスにない特定の広告実験で遭遇する問題です。 広告の分野では、A、U、Cの3つの側面が関与するため、これらの3つの当事者は、計画された配信 - お金を費やす - 広告がダウンラインすることを考慮する単純な回路、予算が関与し、予算が消えると、ラインから降ります。 ここでは、この単純なトラフィックバケット実験を行う場合、2つの異なる戦略に分割され、これらの2つの戦略の結果は、広告主の予算の消費速度に異なっており、結果は、特定のバケット(5または5セント)が、しばらくの間、Aバレルの消費が速く、予算の独立性がなければ、Bバケットの予算を引っ張って、具体的には、広告主のお金であり、Aバケットにより多くの支出があり、トラフィックが小さい場合、結果は非常に良いかもしれない、 しかし、トラフィックが拡大するにつれて、戦略の実験効果は小さくなります。 したがって、広告予算の独立性は、広告主側の実験で考慮されます, 例えば、計画の2つの分割, 予算の均等な配分, それぞれ独立, 互いに影響しない. 最後に、予算の独立した実験をトラフィック側のバケットに適用することを検討し、現在行わないですが、実証は可能です。

(6)実験試験と効果評価

実験テストと効果評価は、リアルタイム効果評価であり、5分(保守的)のデータ遅延を達成し、1分であれば、問題は、ctr=インタラクティブ/露出などの広告効果測定に関連する場合、相互作用が遅延し、計算結果が不安定になる可能性があるので、実験効果を安定させるには5分に1回計算します。

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

全体的な実験効果は、可用性の監視 (たとえば、トラフィック バケットの監視、トラフィック レベルで異なるポリシーの可用性など) であり、2 つの実験バケットの可用性が同じレベルであることを保証します。

実験プラットフォームは、約4000万〜1億の規模のビジネス指標をサポートし、指標をカスタマイズする方法をサポートしています。同時に、実験的な支店バージョンの追跡を保持し、nodiff の対照実験などをサポートします。

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

リーンインサイトが解決したい問題は、オンライン戦略が多いため、戦略を運用する方法は、システム外でシステムの動作状態をよく見ることができるので、戦略が水のように透明に動作し、その後、リーンマトリックスの記述方法を提案し、全体的なビジネスは、マルチレベルビジネス段階に分割され、各段階は、完全な洞察を持っています。

上の図は、システムのアーキテクチャ図です。データ着陸は、ライブストリーミングメカニズムに入り、ライブストリーミングメカニズム内のデータカテゴリは分類され、キーを介して関連付けられ、オンラインデバッグログ、ユーザー情報ログ、オンライン実行戦略実行モデルログ、広告ログなど、ログ構築コンポーネント化され、さらにログ処理ストレージ、オフラインに分割されますストレージオンライン ストレージとオンライン ストレージは、PG と clickHouse の列ストレージを使用して、オンラインへの即時アクセスを可能にします。

全体的なプレゼンテーション効果は、各層がビジネス戦略段階であり、アクセスまたは広告リコールセットの処理を要求し、全体として見ると、広告量から2次元であり、広告リコールセットの数は、戦略の実行に伴って、その数は減少しています。 各レベルでは、異なるスポットタイプの割合の分布や全体的な入札レベルなど、より細かく見て、異なる戦略レベル間のパフォーマンスの違いを区別し、戦略の具体的な影響を洞察することができます。

リーンインサイトは、さまざまな視点を提供します。

トラフィック側: 全体的なトラフィックのファネル動作を確認します。

ユーザーの細分性: 個々のユーザーに対する要求がポリシー ファネルで実行される debug 機能を実装します。

計画の細分性: 広告主プログラムのプロモーションの実行など、ビジネス側が洞察を得ることができます。

この共有はここに、ありがとう。

------

PS：マイクロブログ広告R&Dセンターは、広告エンジンシニアエンジニア/技術専門家(広告戦略方向、分散アーキテクチャ方向)を募集し、チーム技術の雰囲気、技術第一、技術的パラノイア、オープン、自由、優れた株式を持っている、興味のある人は、履歴書を送信してください:

tieniu@staff.weibo.com

広告戦略の方向性:大規模なユーザー行動データに基づいて、オンライン広告戦略とモデルを最適化し、オンライン広告の相関性を向上させ、広告配信効果を最適化するために、広告配信システムの実装に参加します。

分散アーキテクチャの方向:マイクロブログ広告エンジンの設計、再構築、最適化を担当し、ビッグデータ、高同時実行、高パフォーマンスの要件をサポートします。 広告データサービスの研究開発を担当し、1億人のユーザーの広告動的リアルタイム計算とマッチング、データ分散ストレージとアクセスをサポートします。 既存のシステムの欠点を分析し、現在のシステムのボトルネックを特定し、広告システムのアーキテクチャを改善し、システムのパフォーマンスと効果を向上させます。

——END——

記事の推奨事項:

Hulu：動画広告システムにおけるアルゴリズムの実践

360検索広告NLPタスクでディープラーニングのアプリ

DataFun：

ビッグデータと人工知能に焦点を当てた知識共有プラットフォーム。

「見て」、時間!👇