Prebidの役割を改めて解説！AppやIDソリューションに活用されるPrebid

1. アドテクにおける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事業者にとっても、パブリッシャーにとっても大きな機会損失となってしまいます。

提供元：https://solutions.dac.co.jp/blog/p1-prebidjs

そうした背景から、SSPがより良質な広告在庫を買い付けする機会を創出するためにHeader Biddingという新たなソリューションが登場するのです。

2.Header Biddingの仕組み

Header Biddingとはその名の通り、Headに広告タグを埋め込むことで（GAMよりも先に）広告をBiddingしてしまう仕組みであり、アドネットワークやSSPがGoogle社のプラットフォーム外で、Google社よりも先に、広告在庫の買い付けを行うためのソリューションです。

具体的な仕組みについて説明いたします。

まず最初にユーザーがウェブサイトに訪れると、アドサーバーのタグが読み込まれるよりも先に、Headにある広告タグが発火し、Header Biddingのソリューションであるwrapper（ラッパー）にリクエストが送信されます。

このwrapper内で、接続されている各事業者（Bidder）からの入札を受けて、一番高い案件がこの後アドサーバーに送信されることになります。

そしてアドサーバー独自の案件と価格を競った末の勝者の広告がウェブサイト上に表示されることになります。

こうした仕組みによって、GAM内のダイナミックアロケーションでAdXが先に買い付けて機会を失ってしまうことなく、SSPの各事業者はAdXと同じ土俵で広告の買い付けのチャンスを得ることができるようになりました。

提供元：https://solutions.dac.co.jp/blog/p1-prebidjs

3. 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、純広告の申込情報が比較され、最も単価の高い案件が広告として配信される仕組みになっています。

4.Prebidの概要

ここまでHeader Biddingの登場の背景や仕組みについて説明してきましたが、ここからは前述したHeader Biddingの一種であるPrebid.jsについて説明します。

Prebid.jsとはメディアの広告マネタイズにおける、Header Biddingというソリューションの一種で、https://prebid.org/ において開発されているサービスであり、最大の特徴としてはオープンソースのテクノロジーであることが挙げられます。

そのため、各wrapper事業者によって、接続しているBidderは多少異なるものの、技術的には同じテクノロジーを使用しており、Prebid.jsのテクノロジーを使ったwrapper事業者は非常に多く存在します。

5. Prebidの特徴〜導入におけるメリットとデメリット〜

Prebid導入のメリット、そしてデメリットについてお話しします。パブリッシャーサイドから見たメリットは何よりも広告単価収益の向上になります。第2章でも説明しましたが、Header Biddingの登場によって、Google以外のSSPが良質な広告を買い付ける機会が生まれました。

これによって、パブリッシャーは従来よりもより高単価で広告在庫を販売することが可能になりました。

また、Prebidにおいては、オープンソーステクノロジーのため、透明性の高い取引が行われ、また、技術的に対応すれば、他のソリューションに比べてより多くの広告配信事業者の参入が可能になり、より収益性の高い取引の期待が見込まれます。

6. Prebid for app

ここまでPrebid.jsについて説明してきましたが、このPrebid.js、実はモバイルアプリにも導入することが可能となっているのです。

モバイルアプリ向けのPrebidはPrebidMobileと呼ばれるオープンソースのSDK（Software Development Kit – ソフトウェア開発キット）が存在します。

このSDKをアドサーバーのモバイルSDKとともに実装することによって、アドサーバー内（GAMやAdMobなどのアドサーバーおよびは広告配信事業者）における入札と競合することが可能になります。

これらの特徴からより効率的にモバイルアプリの広告収益の向上が期待できるソリューションであると考えられます。

というデメリットもあり、実装工数に対してどれだけの収益向上が見込まれるのか？は一つの論点になると考えられます。

7. Prebid with ID solution

最後にPrebidのもう一つの話題、IDソリューションとの関わりについてもお話しします。

サードパーティCookieの代替手段として期待される共通IDソリューションですが、

パブリッシャーサイドにおいては、そのパブリッシャーのサイトに訪れたユーザーの同意に応じて、データが収集され、IDを作成するプロバイダによってIDとなり、サイトのファーストパーティCookieに保存されます。

このように保存されたIDが広告取引において実際にどのように活用されるのか。

ここで登場するのが、「Prebid.js」であり、そこで使用されるUserIDモジュールが関わってきます。

パブリッシャーサイドはこのPrebidのUserIDモジュールを介して、数多くのIDソリューションにアクセスすることができるようになり、ラッパー内において、ファーストパーティCookieを管理することになります。そしてラッパー内において管理されるIDによって、ユーザーの特定が可能になり、Prebidでの広告取引において、デマンド側にとってより効率的で需要の高い広告リクエストが実現することになります

8. まとめ

今回は、「HeaderBiddingとPrebidの仕組みと概要」と題して、基本的な仕組みや導入のメリットデメリットについてお話しさせていただきました。

すでにHeaderBiddingを導入しているパブリッシャーの方は多いかと思います。