みなさんこんにちは、フォーエムのマーケティングチームの森澤です。
今回は高いパフォーマンスを発揮するヘッダービディングの一種Prebidについて、そしてサードパーティCookieやIDFAに替わる代替手段として日に日に注目が集まっているIDソリューションの活用に向けてPrebidがどのような役割を担うのかについて解説します。
この記事では、そもそものPrebidの仕組みや、アプリで活用するPrebid、IDソリューションとの関わりについて詳しく解説していきます。
目次
アドテクにおけるHeader Biddingの登場
Prebidを説明するにあたって、まずはアドテクにおけるHeader Biddingの登場の背景から説明いたします。
多くのパブリッシャーにおいて導入されているGoogle社のGoogleAdManager（以下GAM）を利用している場合、GAM内ではダイナミックアロケーションという仕組みによって、Google社のSSPであるGoogleAdExchange（以下AdX）に広告リクエストが渡り、AdXが購入しなかった場合に、3PASとして接続しているSSPに広告リクエストが飛ぶ、という仕組みで組まれています。
つまりGoogle社のプラットフォーム内でGoogle社が優先的に広告在庫を購入することができる仕組みになっているのです。本記事ではアドサーバーにGAMが利用されていることを前提に話を進めます。
一方、Google社以外のSSPにとっては良質で高単価な広告在庫を獲得する機会を得ることができず、AdXが買い付けなかった広告在庫しか買い付けることができなくなってしまいます。
一般的に単価が高いとされるAdXですが、SSP事業者から見ると、場合によってはAdX以上の単価での買い付けが可能かもしれないのに、そのチャンスさえも与えられないというのはSSP事業者にとっても、パブリッシャーにとっても大きな機会損失となってしまいます。
そうした背景から、SSPがより良質な広告在庫を買い付けする機会を創出するためにHeader Biddingという新たなソリューションが登場するのです。
Header Biddingの仕組み
Header Biddingとはその名の通り、Headに広告タグを埋め込むことで（GAMよりも先に）広告をBiddingしてしまう仕組みであり、アドネットワークやSSPがGoogle社のプラットフォーム外で、Google社よりも先に、広告在庫の買い付けを行うためのソリューションです。
具体的な仕組みについて説明いたします。
まず最初にユーザーがウェブサイトに訪れると、アドサーバーのタグが読み込まれるよりも先に、Headにある広告タグが発火し、Header Biddingのソリューションであるwrapper（ラッパー）にリクエストが送信されます。
このwrapper内で、接続されている各事業者（Bidder）からの入札を受けて、一番高い案件がこの後アドサーバーに送信されることになります。
そしてアドサーバー独自の案件と価格を競った末の勝者の広告がウェブサイト上に表示されることになります。
こうした仕組みによって、GAM内のダイナミックアロケーションでAdXが先に買い付けて機会を失ってしまうことなく、SSPの各事業者はAdXと同じ土俵で広告の買い付けのチャンスを得ることができるようになりました。
Header Biddingの概要
Header Biddingは使われるサーバーの違いによって大きく2種類に分けられます。
1つ目は入札がウェブサイトのサーバーで行われるパターン（Client to Server）。これにはオープンソース（作成方法が公開されている）のソリューションであるPrebid.jsが該当し、2つ目は入札が別のサーバーで行われるパターンがあります（Server to Server）。これにはAmazon社の提供するTransparent Ad Marketplace（TAM）または、Unified Ad Marketplace（UAM）、そしてGoogle社の提供するOpen Biddingが該当します。
Prebid.jsに関しては詳しく後述しますが、Amazon社のHeaderBiddingソリューションに関しては、前述の仕組みでオークションが行われます。
一方Google社のOpenBiddingはあくまでGAM内で行われるソリューションになります。
広告リクエストが発生し、GAM内のアドサーバーに情報が渡されるとダイナミックアロケーションと同期的に処理される流れとして、接続されている収益パートナー（SSP）に入札リクエストが送信されます。
そして、その入札リクエストに沿ってオークションが行われ、最も高い入札単価がGAMに返信されます。そしてGAM内にて、統一オークションというものが実施され、収益パートナーから返ってきた入札単価、AdXの入札単価、仮想CPM、純広告の申込情報が比較され、最も単価の高い案件が広告として配信される仕組みになっています。
Prebidの概要
ここまでHeader Biddingの登場の背景や仕組みについて説明してきましたが、ここからは前述したHeader Biddingの一種であるPrebid.jsについて説明します。
Prebid.jsとはメディアの広告マネタイズにおける、Header Biddingというソリューションの一種で、https://prebid.org/ において開発されているサービスであり、最大の特徴としてはオープンソースのテクノロジーであることが挙げられます。
そのため、各wrapper事業者によって、接続しているBidderは多少異なるものの、技術的には同じテクノロジーを使用しており、Prebid.jsのテクノロジーを使ったwrapper事業者は非常に多く存在します。
フォーエムにおいてもFourM Wrapper（フォーエムラッパー）というwrapperソリューションを有しており、10社以上のBidderと接続しています。
Prebidの特徴〜導入におけるメリットとデメリット〜
Prebid導入のメリット、そしてデメリットについてお話しします。パブリッシャーサイドから見たメリットは何よりも広告単価収益の向上になります。第2章でも説明しましたが、Header Biddingの登場によって、Google以外のSSPが良質な広告を買い付ける機会が生まれました。
これによって、パブリッシャーは従来よりもより高単価で広告在庫を販売することが可能になりました。
また、Prebidにおいては、オープンソーステクノロジーのため、透明性の高い取引が行われ、また、技術的に対応すれば、他のソリューションに比べてより多くの広告配信事業者の参入が可能になり、より収益性の高い取引の期待が見込まれます。
Prebid導入のメリット
1.広告単価収益の向上
2. Google以外のSSPが良質な広告を買う機会が発生
一方でデメリットとしてはまずはレイテンシーがあげられます。第3章で少し触れましたが、Prebidはパブリッシャーサイドのサーバーで行われるため、デマンドソースの接続が増えると、サイトの読み込み時間の遅延につながってしまうのです。
また、GAMへの広告リクエストを一度止めてから入札を行うことになるので、広告表示の遅延のリスクも懸念されます。
ただ、後者に関してはタイムアウト値というものを設定すれば、指定した時間内に入札がなければ、GAMへのリクエストが飛ばされるようにすることができます。
デメリット
デマンドソースの接続が増えると、サイトの読み込み時間と広告表示の遅延につながる
Prebid for app
ここまでPrebid.jsについて説明してきましたが、このPrebid.js、実はモバイルアプリにも導入することが可能となっているのです。
モバイルアプリ向けのPrebidはPrebidMobileと呼ばれるオープンソースのSDK（Software Development Kit – ソフトウェア開発キット）が存在します。
このSDKをアドサーバーのモバイルSDKとともに実装することによって、アドサーバー内（GAMやAdMobなどのアドサーバーおよびは広告配信事業者）における入札と競合することが可能になります。
PrebidMobileの特徴メリットとしては以下のポイントが挙げられます。
1.Prebidサーバーとの単一の統合ポイントを提供することによって、より多くのモバイル購入者に直接アクセスすることが可能になる
2.Bidderの接続構成を変更する際に、アプリ自体の更新をする必要がなく、運用による事業者変更などの際の開発者側の工数が少なく済む
3.オープンソースで透明性の高いHeaderBiddingソリューションであること
4.リアルタイムビッディングのため、メディエーションに比べて、パートナー管理や広告運用の工数がかかりづらい
5.メディエーションに比べて、レイテンシーが起こりづらい
これらの特徴からより効率的にモバイルアプリの広告収益の向上が期待できるソリューションであると考えられます。
一方、デメリットとしては、
1.ウェブサイト向けのPrebid.jsやモバイルアプリにおけるGoogle社のOpen Biddingに比べて、実装工数がかかる
2.ウェブサイト側のPrebidに比べて在庫が少ない
というデメリットもあり、実装工数に対してどれだけの収益向上が見込まれるのか？は一つの論点になると考えられます。
Prebid with ID solution
最後にPrebidのもう一つの話題、IDソリューションとの関わりについてもお話しします。
サードパーティCookieの代替手段として期待される共通IDソリューションですが、
パブリッシャーサイドにおいては、そのパブリッシャーのサイトに訪れたユーザーの同意に応じて、データが収集され、IDを作成するプロバイダによってIDとなり、サイトのファーストパーティCookieに保存されます。
このように保存されたIDが広告取引において実際にどのように活用されるのか。
ここで登場するのが、「Prebid.js」であり、そこで使用されるUserIDモジュールが関わってきます。
パブリッシャーサイドはこのPrebidのUserIDモジュールを介して、数多くのIDソリューションにアクセスすることができるようになり、ラッパー内において、ファーストパーティCookieを管理することになります。そしてラッパー内において管理されるIDによって、ユーザーの特定が可能になり、Prebidでの広告取引において、デマンド側にとってより効率的で需要の高い広告リクエストが実現することになります
まとめ
今回は、「HeaderBiddingとPrebidの仕組みと概要」と題して、基本的な仕組みや導入のメリットデメリットについてお話しさせていただきました。
すでにHeaderBiddingを導入しているパブリッシャーの方は多いかと思います。
改めてHeaderBiddingの中でもそれぞれの特徴や、仕組みについて理解が深まっていれば、また、現在導入を検討している、あるいは、導入しているものの今後の運用について悩んでいる、というようなパブリッシャーのご担当者さまにとって改めて認識の確認や、検討の材料になっておりましたら幸いです。
役立つ最新情報をお届けしている『FourM（フォーエム）』では、毎週木曜日に無料購読可能なニュースレターで配信しております。
「広告業界の最新トレンドを把握しておきたい」というマーケターの方は、ぜひこの機会に、ニュースレターの無料購読を始めてみてはいかがでしょうか。
