広告サーバーのインフラストラクチャ オプション(パート 3)

この記事では、広告配信プラットフォームを構築する際に使用できる Google Cloud Platform(GCP)の機能とプロダクトについて説明します。

この記事は、次のシリーズの一部です。

このシリーズ全体で使用される広告技術用語の概要をご覧ください。

広告配信とは、多くの広告主のうちの 1 つから、1 人の顧客に対し、パブリッシャーのプロパティについての広告(一般に最も関連性の高い広告)を表示するプロセスです。プロパティはウェブサイト、アプリ、ゲームなどです。

広告サーバーの複雑さは、それが提供する機能によって異なります。業界用語では、広告サーバーは、パブリッシャーや広告主がキャンペーン、広告、広告入稿を管理するためのツールです。広告サーバーは、沿道で広告板に静的な広告を表示するように、広告を表示するだけではありません。広告を表示することはコア機能ですが、Google アド マネージャーなどの広告配信技術プラットフォームには、顧客にユニークな広告を表示するだけではない、さらに多くの機能が備わっており、多くのメリットが提供されます。

この記事では、次の主要機能を含む堅牢な広告配信プラットフォームの構築のアプローチのしかたについて説明します。

  • キャンペーン、アカウント、請求、レポートの管理。
  • 最も関連性の高い広告の選択。
  • ターゲット ユーザーへの広告の表示。
  • インプレッション、クリック、コンバージョンなどのイベントの管理。
  • 分析データストアへの関連操作のパブリッシュ。

通常、広告サーバーは毎秒数万件の広告リクエストを処理し、各レスポンスが数ミリ秒以内に送信されます。きわめて多くのリクエストにきわめて迅速に応答できることは、可用性、スケーラビリティ、低レイテンシのすべてが広告配信ソリューションの重要な要件であることを意味します。また、単一のサーバー ソリューションでこれらすべての要件を満たすことはできないため、この記事では分散システムを設計する意味について説明します。

広告サーバーには次の 2 つのタイプがあります。

  • 販売サイド: これらのサーバーにより、パブリッシャーは広告サーバーの UI から広告主を直接管理することで、広告収入を最大にすることができます。販売サイドサーバーは、多くの場合に広告をホストしますが、広告への参照をホストすることもできます。一部の広告サーバーでは、購入者用のセルフサービス UI も用意されています。
  • 購入サイド: これらのサーバーにより、広告主、マーケティング部門、広告代理店は広告の更新を管理できます。パブリッシャーに実際の広告を提供する代わりに、これらのプラットフォーム ユーザーは、販売サイド広告サーバーと通信して、広告を取得するコード スニペットを提供します。

次の図は、考えられる 1 つの広告サーバー システムのアーキテクチャを示しています。

広告サーバー システムの可能な実装

広告サーバー プラットフォームへの主要エントリ ポイントは、Cloud Load Balancing によって提供されます。

  • 広告をリクエストする。
  • クリエイティブを取得する。広告は、最も近い Cloud CDN キャッシュから取得されます。
  • インプレッションや(ユニークな)ユーザーのアクション / クリックなどのイベントをトラックする。

ロードバランサへのリクエストは、HTTP(S) 負荷分散ロギングおよびモニタリングまたはコレクタで実行されているカスタムコードによってログに記録され、Cloud Pub/Sub にパブリッシュされてから、分析とユーザー プロファイリングを行うために Cloud Dataflow で処理されます。

リクエストを処理するワーカーは以下を利用します。

  • 予算の情報。
  • (ユニークな)ユーザー プロフィール。
  • キャンペーンの詳細。
  • カウンタ。
  • 選択するためのトレーニング済みモデル。

上記のいくつかは、固有の要件に合わせる必要があります。

  • 広告の選択に複数の異なるデータベースを使用せず、簡単にするために階層型データベースやリレーショナル データベースで妥協することを望む場合もあります。その場合は、Cloud BigtableCloud Spanner を使用できます。
  • 入札リクエストを処理する際にミリ秒未満の読み取りレイテンシが必要であり、追加の操作オーバーヘッドを受け入れられる場合があります。その場合、可能であれば、ローカル レプリケーションを含む第三者のリージョン メモリ内データベースを使用できます。
  • コストを最小限に抑えるために、プリエンプティブ VM に設定されたイベント コレクタを使用したいと考える場合があります。オンライン処理を行う必要がない場合は、Stackdriver Logging を使用してイベントをキャプチャし、BigQuery で分析できます。

キャンペーンの管理

キャンペーンを管理するには、広告主は、少なくともユーザー インターフェース(UI)とともにウェブ フロントエンドから構成されるユーザー フロントエンドが必要です。さらに、広告主はいくつかのレポート機能を提供する必要もあります。推奨されるオプションについては、ユーザー フロントエンド(パート 1)をご覧ください。

この UI によって設定されたリソースの共有階層には、広告主、キャンペーン、予算、クリエイティブ、請求が含まれます。この階層を作成すると、システムによって、広告選択の意思決定プロセスの部分を形成する一連のルールが記録されます。このデータは、メタデータ管理ストア(パート 1)に格納されます。

ほとんどの広告サーバーは、1 日に数十億の広告リクエストを処理します。これらの広告主のルールに適用されるメタデータを格納するデータベースに、この負荷を直接かけることはおすすめできません(Cloud Spanner を使用する場合を除く)。代わりに、大量読み込みの保存パターン(パート 1)で取り上げられているオプションのいずれかを検討してください。

最も関連性の高い広告の選択

広告リクエストの受信と解析

リクエストは、パブリッシャーのプロパティに配置された広告タグによって送信されます。広告タグは次のようになります。

<script src="[URL_TO_YOUR_AD_SERVER]?key=value"></script>

タグは読み込まれると、広告サーバーへの広告リクエストをトリガーします。このリクエストには、HTTP ヘッダー、ユーザー エージェント、ページ コンテキスト、IP アドレス、ターゲティング情報、可能であればユーザー識別子、広告の詳細(サイズを含む)などの情報が含まれます。

広告サーバーは、これらのリクエストを受信して処理するために、HTTP エンドポイント [URL_TO_YOUR_AD_SERVER] を提供する必要があります。推奨されるオプションは、リクエストの処理(パート 1)で詳しく説明しています。

ユーザーのプロファイリング

広告サーバーにはそれぞれ、広告選択の独自の方法があります。このロジックはこの記事の範囲には含まれません。ただし、ユーザーを理解することは関連広告を表示するために重要です。このソリューションでは、高度なユーザー分類が要件であることを想定しています。

多くのパブリッシャーと連携している広告サーバーは、さまざまなプロパティで同じユーザーを認識する可能性があります。(ユニークな)ユーザー識別子には、ユーザーが置き換えることができるウェブ Cookie やモバイル デバイス ID などがあります。

広告サーバーは、広告リクエストによって提供される情報(IP、ページ情報)を、データストアを検索するためのこのユーザー識別子で補強できます。広告サーバーは、数テラバイトの可能性のあるデータ全体の数百万行から、ユーザー ID を検索できる必要があります。広告サーバーは、ミリ秒単位で応答を返し、管理オーバーヘッドを最小限に抑える必要もあります。

(ユニークな)ユーザー プロフィール ストア(パート 1)で概要を説明しています。その記事で説明されている任意のオプションを使用できますが、広告配信には Cloud Bigtable を使用することをおすすめします。その理由は次のとおりです。

  • 数ペタバイトのデータを格納できるワイドカラム型 NoSQL データベースである。
  • 1 桁のミリ秒単位で行を取得する。
  • リージョン間レプリケーションをサポートする。
  • フルマネージドである。

キャンペーンと広告の選択

広告選択プロセスは、広告の選択(パート 1)で説明しているように、いくつかの手順で実行されます。

  1. (ユニークな)ユーザー プロフィール ストア(パート 1)を使用してユーザーをプロファイリングします。
  2. メタデータ管理ストアのデータ(パート 1)のコピーを使用して、一致するキャンペーンと広告を選択します。コピーは、大量読み込みの保存パターン(パート 1)のいずれかを使用して行われます。
  3. コンテキスト ストア(パート 1)を使用して、関連するキャンペーンと広告をフィルタリングします。
  4. 広告を選択します。

広告サーバーは、ユーザー セグメントに一致するキャンペーンと広告を選択した後に、コンテキスト ストアのデータ値(フリークエンシー キャップ、ブラックリスト、予算不足など)に対してそれらを検証します。次に、広告サーバーは、残りのキャンペーンと広告の中から最適な広告を選択します。その最終的な選択のロジックの決定は、すべて管理者が行います。たとえば、キャンペーンに重点を置いて、CPM が最も高いものを選択したり、残りの予算が最も大きいものを選択したりできます。また、広告のクリック率の見込みを計算したり、重み付けの混合のためにパラメータを組み合わせたりすることもできます。

さらに高度な選択システムの中には、機械学習を使用して、ユーザー単位やセグメント単位で広告を推奨するものもあります。機械学習ワークフローについてはこの記事では詳しく説明していませんが、機械学習機能の構築(パート 2)で詳しく説明しています。

選択した広告のターゲット ユーザーへの配信

ここまでの詳細な手順は、パブリッシャー側の広告配信ワークロードに属するものと見なすことができます。ただし、広告の選択後、広告サーバーは、次のいずれかをポイントするリンクまたは HTML コードを返します。

  • パブリッシャーの広告サーバー上の場所。
  • 広告主に属する可能性のある外部の場所。このような広告サーバーは、購入サイドの広告サーバーと見なされ、第三者広告配信(3PAS)と呼ばれるモデルを実装します。この場所を使用することで、広告主はパブリッシャーの広告サーバーに接続したり、通信したりする必要なく広告を更新できます。さらに、この場所によって、独自のトラッキングを管理することもできます。

マーケティング担当者が独自のクリエイティブをホストしたい場合でも、パブリッシャーの広告サーバーでそれらをホストさせたい場合でも、広告の配信までのプロセスは同じです。

クリエイティブの保存

クリエイティブとは動画や画像などのメディア ファイルです。これらのアイテムを保存するには、スケーラブルで可用性の高いオブジェクト ストアが必要です。

Cloud Storage がおすすめのストアです。これは、数ペタバイトの生データや非構造化データをホストするように構築されています。また、バックアップやアーカイブのオプションも備えています。Cloud Storage を使用するだけで、クリエイティブのライフサイクルを管理し、NearlineColdline を使用してホット ストレージからコールド ストレージにクリエイティブを移動してコストを削減できます。

クリエイティブの配信

Cloud Storage などのオブジェクト ストレージは世界的に利用できますが、距離によるネットワーク レイテンシが加わる傾向があります。さらに、オブジェクト ストレージは、コンテンツ配信ネットワーク(CDN)経由で広告を配信するよりも、コストがかかる可能性があります。

広告ピクセルとクリエイティブは、多くの場合に公開コンテンツであるため、Cloud Storage にコンテンツをキャッシュするために、2 つの GCP ソリューションのいずれかを使用できます。

  • オブジェクトを公開する: キャッシュ制御により、Cloud Storage は既存の Google インフラストラクチャを使用してコンテンツをキャッシュに保存できますが、CDN のような機能は限られており、強制的にクリエイティブをグローバルに期限切れにする方法もありません。

  • Cloud Load Balancing と Cloud Storage を組み合わせる: Cloud Storage でホストされているコンテンツには、Cloud CDN を有効にした Cloud Load Balancing を使用できます。Cloud CDN は、Cloud Storage の下りと比較してネットワーク料金の割引を実現するだけでなく、署名付き URL サポートキャッシュキー無効化を提供します。

    次の図は、この 2 番目のソリューションを示しています。

    Cloud Load Balancing と Cloud Storage の組み合わせ

他のプロバイダとのパフォーマンスの比較については、これらの第三者の Cedexis レポートをご覧ください。

広告イベントの管理

以下の例のように、さまざまなタイプのイベントがシステムに有益です。

  1. 広告リクエスト: user_ABC の料理ウェブサイトから広告リクエストを受信すると、システムは、料理 > インド料理などのユーザーの興味を反映する情報を追加して、user_ABC セグメントを改善します。
  2. 広告のインプレッション: CPM モデルで、広告がターゲット ユーザーに表示されます。システムは、残りの予算を更新できるようにインプレッションを記録します。
  3. 広告クリック: ユーザーが広告をクリックします。このアクションは、特に複数の(ユニークな)ユーザーが一定期間内に同じ広告をクリックした場合に、広告最適化結果に影響を与える可能性があります。
  4. コンバージョン: ユーザーが広告をクリックし、何かを購入したり登録したりするなど、広告主のプロパティに対して期待されるアクションを実行します。

イベントの処理時に、価格、データの更新頻度、運用上のオーバーヘッドの適切なバランスを見つけることは、プロセスのあらゆる段階、特に以下のタイミングで重要です。

  • インプレッション、クリック、コンバージョン、広告リクエストから得られる大量で高速のイベントを収集して取り込む。
  • 値を抽出し、予算、上限、クリック率などのカウンタを計算するために、リアルタイムやオフラインでイベントを処理する。
  • 課金を調整したり、適切な配信操作を適用したりするために、結果を各種ストアにリアルタイムやオフラインでエクスポートする。

詳細については、イベント ライフサイクル(パート 2)をご覧ください。

リアルタイムのイベントのキャプチャと処理には、次のアーキテクチャをおすすめします。

リアルタイムのイベントのキャプチャと処理のアーキテクチャ

このアーキテクチャでは:

  • インプレッションとクリックにより、HTTP エンドポイントから Cloud Storage でホストされている静的コードまたは Google Kubernetes Engine(GKE)でホストされているウェブサーバー コレクタへのリクエストを行います。
  • リクエスト イベントがロードバランサ HTTP ログを介して記録されるか、またはコレクタによってキャプチャされたイベントが Cloud Pub/Sub に公開されます。
  • Cloud Dataflow は Cloud Pub/Sub トピックをサブスクライブし、イベントを処理します。
  • Cloud Dataflow は未処理または処理済みのイベントを分析のために BigQuery にエクスポートし、さらに残りの予算を更新するためにインテリジェンス(コンテキスト)データベースにエクスポートします。

静的コードを Cloud Storage でホストするか、GKE コレクタでホストするかの選択は、要件によって異なります。

  • 追加のバックエンド アクションを実行する必要がある場合は、GKE を使用します。
  • 運用上のオーバーヘッドが心配である場合は、Cloud Storage を使用します。
  • たまにリクエストが再試行されても問題ありませんが、GKE または Compute Engine コレクタの実行にかかる費用を削減する必要がある場合は、コンピューティング プラットフォーム(パート 1)に示すように、プリエンプティブ VM を使用します。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...