広告プラットフォームの構築(概要)

この記事は、Google Cloud Platform(GCP)での広告プラットフォームの構築について説明する、複数のパートからなるシリーズの概要です。この広告プラットフォームは各種のサービスで構成され、さまざまなユーザーに対応します。そのため、このシリーズでは、共有インフラストラクチャ オプションと特定インフラストラクチャ オプションの両方を取り上げます。

このシリーズの構成

このシリーズでは次の 2 つを主軸として説明を進めます。

用語

次の用語は、このシリーズ全体で使用され、広告業界でも使用されているものです。

  • 広告枠: 広告の購入者に提供される広告スロット。
  • 広告スロット: 広告が表示されるウェブページまたはモバイルページ上のスペース。
  • 広告タグ: 広告スロットを記述するパラメータを含む小さなコード。
  • 広告サーバー: 広告配信プラットフォームで、サイト運営者が所有するスペース上の広告スロットにクリエイティブを配信するために使用されるテクノロジー。広告サーバーには通常、クリエイティブの選択、カウント、配信などの機能が含まれます。
  • 広告主: さまざまなメディアを通じて直接、または他の広告購入者を介して商品のプロモーションを行う組織。
  • オーディエンス: サイト運営者が所有するスペースにアクセスする、またはそのスペースを利用する(一意の)ユーザー。
  • オーディエンス セグメント: 分類のサブセットに基づいて選択された、広告主がターゲットとする(一意の)ユーザー群。
  • 購入者: クリエイティブを配置する広告スロットの購入者。ネットワーク、代理店、広告主などが購入者となります。
  • コンバージョン: 広告主が所有する広告でユーザーが行う可能性のあるアクションであり、広告主によって事前に定義されています。
  • CPA: アクション単価。購入者がアクションごとに支払う金額。アクションやコンバージョンには、できるだけ多くのユーザーを獲得する、重要な得意客を維持する、広告主のウェブサイトでターゲット ユーザーがなんらかの商品を購入するように誘導するなど、さまざまな目標があります。アクションとしては、ホワイトペーパーをダウンロードする、ニュースレターに登録する、広告主のウェブサイトでなんらかの商品を購入する、などがあります。
  • CPC: クリック単価。購入者が広告クリックごとに支払う金額。
  • CPM: インプレッション単価。購入者が 1,000 インプレッションごとに支払う金額。
  • クリエイティブ: ターゲット ユーザーに表示される広告。
  • CTR: クリック率。クリック数をインプレッション数で割った値。
  • CVR: コンバージョン率。コンバージョン数をインプレッション数で割った値。
  • DMP: データ管理プラットフォーム(DMP)によって、広告技術の利用者はユーザーに関する追加情報を得られます。DMP を利用するとデータダンプへのアクセスが可能になり、DMP によってユーザーのプラットフォームにデータが読み込まれる場合もあります(Cloud Storage などのオブジェクト ストレージへのアクセス権を DMP に付与した場合)。
  • インプレッション: 広告が提供元から取得され、課金対象になったことを表します。
  • サイト運営者: このシリーズのコンテキストの場合、サイト運営者は、クリエイティブをホストする広告スロットを提供するデジタル資産(ウェブサイトやモバイルアプリなど)の所有者を表します。
  • (サイト運営者の)資産: サイト運営者が広告スロットを設けるウェブサイト、アプリ、ゲーム。
  • サプライヤ: 複数のサイト運営者の代理として、購入可能な広告スロットを提供します。
  • ターゲット ユーザー: 広告のターゲット。広告を表示する対象として想定された人。
  • 分類: オーディエンスの特性を(通常、階層状に)分類したもの。
  • (一意の)ユーザー: ターゲットとなり得る、一意であることがわかっている、または一意と見なされるユーザー。一意であるかどうかの判断は難しく、複数の人が同じデバイスを使っている場合や同じ人が複数のデバイスを使っている場合などの要因を考慮すると、多くは最善の努力による推測となります。

リアルタイム入札に関する用語は、次のとおりです。

  • Ad Exchange: SSP から広告リクエストを受け取る、広告のマーケットプレイス。リクエストの受け取り後、SSP はすべての DSP から入札を付加した広告を受け取ったうえで、落札価格を選定し、販売サイドに返します。この取引は迅速に行う必要があります。たとえば、Google の場合、購入者が入札を返すのを待つ時間は約 120 ミリ秒です。
  • DSP: デマンドサイド プラットフォーム(DSP)は、広告リクエストを受け取って、SSP または Ad Exchange が設定した時刻までに回答する必要があります。与えられる時間は 100 ミリ秒から最大でも数秒までです。DSP は入札するかどうかを決定します。入札する場合、DSP は、広告を選択し、入札価格を決定して、その価格を Ad Exchange に返します。
  • RTB: リアルタイム入札。オンライン オークションの仕組みを通じてプログラマティック購入者に広告枠(広告スロット)を公開するプロセスです。
  • SSP: サプライ(セル)サイド プラットフォーム(SSP)は、広告サーバーに組み込まれる場合も、スタンドアロン ツールとしてサイト運営者または広告サーバーから広告リクエストを受け取る場合もあります。SSP は通常、広告リクエストを Ad Exchange に送信しますが、このリクエストを直接 DSP に送信する場合もあります。SSP は、追加のオーディエンス コンテキスト(ユーザー層など)を付加することでこのリクエストの内容を具体化して、広告スロットの価値を高めます。SSP はオークションで落札された広告を受け取り、それをサイト運営者か広告サーバーに返します。

このほか、このシリーズで特に使用されている用語として次のものがあります。

  • バックエンド: フロントエンドによってデータの取得や処理(たとえば、機械学習モデルのトレーニング)のオフロードに使用されるサービスやデータベース。
  • 顧客: 提供されたプラットフォームを使用するプラットフォーム ユーザー。
  • フロントエンド: 外部のリクエストを処理するサービス。
  • ファンクション: プラットフォームで稼働するサービスによって提供される特定の機能。
  • オフライン: リアルタイムの意思決定には関与しないプロセスを表します。
  • オンライン: リアルタイム プロセスの一環として実施されるプロセスを表します。
  • プラットフォーム: 広告配信、広告枠の提供、入札などの主要機能のいずれかを提供するサービスの集合。
  • プラットフォーム ユーザー: プラットフォームの UI を利用する、サイト運営者、販売者、購入者、広告主などのユーザー。
  • QPS: 1 秒あたりのクエリ数。
  • サービス: 通常 1 つのアプリケーションとしてセットで提供される 1 つ以上のファンクション。
  • ワーカー: タスクを行っているサービスのインスタンス。通常、複数のワーカーが同時に稼働します。

共有コンポーネント

広告サーバー、デマンドサイド プラットフォーム、サプライサイド プラットフォーム、Ad Exchange などの各種広告プラットフォームには、以下を目的として類似の働きをするファンクション コンポーネントがそれぞれ複数含まれています。

  • プラットフォーム ユーザー(サプライヤ、購入者)がフロントエンドの UI を使用してプラットフォームを利用できるようにする。
  • 広告や入札などのリクエストを処理する。
  • イベントやデータ ライフサイクル(インプレッション数、クリック数、コンバージョン数や、場合によっては落札の成否など)を管理する。

次の図は、上記のようなコンポーネントに基づくアーキテクチャを示しています。

広告プラットフォームの共有コンポーネントのアーキテクチャ

ユーザー フロントエンド

多くの広告プラットフォームには顧客フロントエンドが必要です。通常は 1 つ以上のデータベースを基盤とする UI がそれに該当します。フロントエンドの要件は次のとおりです。

  • 快適なユーザー エクスペリエンスを実現するレイテンシで、世界中からアクセスできる。
  • 顧客が設定をいつでも管理できるように、高い可用性を備えている。
  • 顧客が自分の判断でいつでも(プラットフォーム ユーザーの特定のタイムゾーンやグローバル ベースで)プラットフォームを使用できることを確認しながら、要求に応じてスケーリングできる。

ユーザー フロントエンドは、プラットフォームに応じて広告の提供者または購入者によって使用され、場合によってはこの両者によって使用されます。また、ユーザー フロントエンドが広告サーバー、DSP、SSP、Ad Exchange に組み込まれる場合もあります。各フロントエンドはそれぞれ異なる管理機能を備え、さまざまな広告リソース(広告クリエイティブ、入札、リクエスト、ユーザー層など)を処理します。

上記のコンセプトの詳細については、ユーザー フロントエンド(パート 1)をご覧ください。

リクエストと広告の選択

広告の選択はプラットフォームによってリクエストの受信時に行われます。リクエストとしては、通常の広告配信コンテキストで広告タグから生成される広告リクエストがあります。また、RTB コンテキストで SSP や Ad Exchange から送信される入札リクエストの場合もあります。

広告の選択を行うプラットフォームの部分には、次の要件があります。

  • 高スケーラビリティ: 広告技術における日々のリクエスト数は、数十億件にものぼることがあります。
  • 高可用性: このような規模の大きさを考えると、1 秒でも使用不能になってリクエストが失敗すると、ビジネスに大きな影響を及ぼす可能性があります。
  • 低レイテンシ: 広告はできるだけ迅速にターゲット ユーザーに表示する必要があります。このことは、広告をどれだけ迅速に選択しなければならないかに影響します。RTB では、レイテンシが極めて重要な要件となります。SSP や Ad Exchange では、特定の時間(場合によってはわずか 100 ミリ秒)内に入札レスポンスを返す必要があるためです。

広告選択プロセスのコンポーネントを以下に示します。

  • 広告リクエストを受信するフロントエンド サービス。
  • フロントエンドでの意思決定に使用される 1 つ以上のデータストア。
  • 広告を選択するための選択アルゴリズム。

リクエストの処理(パート 1)はフロントエンドの実装方法を示し、負荷の高い読み取りの保存パターン(パート 1)はストアの実装方法を示しています。広告サーバーと RTB 入札者に関する詳細については、広告サーバー入札者に関する記事(パート 4)の関連セクションをご覧ください。

DSP と広告サーバーは両方とも広告選択ロジックを利用して(一意の)ユーザーをプロファイリングし、関連性のないキャンペーンや広告をフィルタで除外したうえで広告を選択します。また、入札者用の選択プロセスには、入札を行うかどうかの意思決定、入札価格の決定、さらに場合によっては入札の最適化も含まれます。両方の関連リンクが、広告ワークロードを処理するためのインフラストラクチャ オプション(パート 1)に含まれています。

イベントとデータ管理

広告プラットフォームで行われる意思決定の多くは、次のような各種データソースから送られるデータに基づいて行われます。

  • 広告サーバーのフロントエンドで受信される広告リクエスト。
  • DSP のフロントエンドで受信される入札リクエスト。
  • DSP の成功エンドポイントで受信される入札の成否。
  • 広告がターゲット ユーザーに配信された後に生成されるインプレッション イベント。ほとんどの場合、インプレッションは課金対象インプレッションです。課金対象インプレッションは表示の対象となり、視認可能と見なされます。
  • ターゲット ユーザーが広告をクリックしたときに生成されるクリック イベント。通常、イベント数はインプレッション数より数桁少ない数になります。
  • ターゲット ユーザーが広告主が所有する広告で期待されたアクションを行ったときに生成されるコンバージョン イベント。通常、イベント数は広告のクリック数より少ない数になります。
  • プラットフォーム ユーザーが管理する半静的データ。
  • 過去のイベントを分析して得られるオフライン データ。
  • DMP などの外部ソースから提供される、ユーザー セグメントや関連料金などの第三者データ。

機械学習はルールベース システムに代わる重要なコンポーネントです。機械学習では、履歴データを使用してオフラインでモデルをトレーニングしたり、リアルタイム データを使用してオンラインでモデルをトレーニングしたりできます。トレーニングしたモデルをローカルにデプロイすることで、広告サーバーなどの個々のコンポーネントやサービスでオンライン予測を実施できます。また、こうしたモデルを使用してキャッシュ / Key-Value ストアにデータを取り込むこともでき、このストアから作成済みの予測が提供されます。

このプラットフォームには以下の機能が必要です。

  • 収集、取り込み、処理、保存される数テラバイトもの日々のデータを処理する。
  • 日別のイベントの収集、取り込み、処理、保存時に、数十億件の規模までのスケーリングを行う。
  • リアルタイムのオンライン処理とオフライン処理のそれぞれのオプションを提供する。
  • 分散環境で機械学習などの処理タスクを行う。
  • 関連データを自動的に、ストリーミングによってリアルタイムで、または後から一括でインテリジェンス データベースに返す。

入札リクエスト、入札結果、インプレッション数、クリック数のデータを結合する方法について詳しくは、イベントの処理(パート 3)をご覧ください。

広告サーバー

広告サーバーは一般に、次の図のように共有コンポーネントと広告配信機能で構成されます。

広告配信を含む広告プラットフォームのアーキテクチャ

広告サーバーの中核部分である広告配信には、次の要件があります。

  • 低レイテンシ: 広告を迅速に配信することで、その広告が確実にターゲット ユーザーの目に触れるようにし(スクロールで可能になる場合)、広告の表示が妨げられないようにしなければなりません。
  • 高可用性: 広告を選択しても、プラットフォームが停止して広告を配信できないと、広告がむだになり、費用を失うことになります。
  • スケーラビリティ: 1 日あたりの広告リクエストは数十億件にものぼるため、多くのプラットフォームではリクエストに応じて数十億もの広告を処理できることが求められます。

独自のインフラストラクチャから広告を配信する DSP や SSP もありますが、この記事では、DSP や SSP が広告サーバーをプラットフォームに組み込んで実装していることを想定しています。広告の配信の詳細については、選択した広告をターゲット ユーザーに配信する(パート 3)をご覧ください。

入札者

入札プロセスの詳細については、RTB 入札者のインフラストラクチャ オプション(パート 4)をご覧ください。

DSP は一般に、次の要件がある共有コンポーネントで構成されます。

  • 入札レスポンスには定義された期限があるため、レイテンシが低いことが不可欠です。
  • 入札リクエストごとに入札が計算されるため、広告選択ロジックが複雑になります。アルゴリズム内のこうした追加ロジックは通常、追加の入札者サービスによって処理されます。詳細については、入札(パート 4)をご覧ください。

次の図は、デマンドサイド プラットフォームの概要を示しています。

デマンドサイド プラットフォームの概要

次のステップ

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

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