ヘッダービディングとは？仕組みや導入、効果的な活用方法について

ヘッダービディング（入札）の登場により、パブリッシャーが広告枠をオークション取引する方法が変化しました。30,000の人気ウェブサイトドメインを調査した結果、そのうち60% がヘッダービディングを提供する事業者のタグを含んでいたことが分かりました。このメソッドを利用することでより多くの収益を生み出し、パブリッシャーの31%の収益が増加しています。また、同じような変化がモバイルでも起きており、アプリ内でヘッダービディングが行われています。本稿では、プログラマティックに機能するヘッダービディングの仕組みと現在の傾向、さらにパフォーマンスを最大化するための効果的な方法について解説します。

ヘッダービディングとは

ヘッダービディングは、プログラマティック メディア バイイング（広告枠の自動買付け）の一手法で、パブリッシャー（メディア）がアドサーバーへ広告リクエストをする前に、複数のアドエクスチェンジにインベントリ（広告在庫）を提供するための仕組みです。事前入札としても知られているヘッダービディングは、複数のデマンドソースを同じインベントリに入札させ、エコシステムをより公平かつ競争の激しいものにして、パブリッシャーの収益を最適化するメソッドです。YieldbotのCEO、ジョナサン・メンデス（Jonathan Mendez）氏はDigidayの記事で次のように話しています。「ヘッダービディングは、現状のメソッドに比べて、収益パートナーとアドテック企業、パブリッシャー間で、よりクリーンで優れた技術連携ができます」

ヘッダービディングを導入するには、パブリッシャーのWebサイトのページのヘッダーに、専用のタグであるJavascriptを実装します。これによって、Webサイトを訪問するユーザーに広告を表示することができます。

ここで、広告配信の流れを簡単におさらいしましょう。まず、ユーザーが広告をクリックし、Webサイトまたはアプリに移動すると、パブリッシャーが複数のアドネットワーク（媒体）に広告をリクエストします。アドネットワーク（媒体）側は、その広告枠の価値に合わせて入札を行います。一番高い価格を提示した広告は、広告主のアドサーバーとユーザーを接続するパブリッシャーのアドサーバーに送信され、その広告クリエイティブが表示される仕組みです。インベントリを単一のアドサーバー側のサプライに組み合わせることで、パブリッシャーはインプレッションごとにインベントリを販売できるため、各インプレッションの価値に透明性が出ます。

ヘッダービディングを実装するかどうかを決めるにあたり、アプリのトラフィックやビューアビリティー、収益目標を分析する必要があります。また、実装するラッパーは、独自のものか、それともオープンソースかを選び、そして、クライアント側とサーバー側のどちらのヘッダービディングにするかを選択することも大切です。このガイドでは、これらの用語をすべて解説していきます。

ヘッダービディングが登場する前に何が起こったのか

マーケターがプログラマティック ヘッダー ビディングの恩恵を受ける前は、広告枠はウェブページ上で広告の掲載が始まってから配信されていました。ベン・モリズロー（Ben Morrisroe）氏はPubliftの記事で次のように話しています。「ユーザーがWebサイトを訪れた時に、アドサーバーで最も優先順位の高いパブリッシャーのダイレクトオーダーが最初に表示されます。ダイレクトオーダーを使い切ると、アドサーバーは、連続したウォーターフォールシステムにおけるラインアイテムに、自動的にインプレッション（広告が表示された回数）を渡します。そのオークション環境は、リアルタイムに機能します」

ただし、これらのシステムでは、マーケターのインプレッションは実際の価値を反映することが保証されていない価格で販売されるのが現状です。最もランクの高いアドエクスチェンジは、最高入札者に対してではなく、売れ残っているインベントリに最初に提供されます。それらが拒否されると、入札されるまでそのオファーが受け継がれます。最高入札者よりもランクが低い者がそのインプレッションに高い価格を支払ったとしても、同様のことが起こり得るのです。つまり、パブリッシャーは収益を失うことになります。プログラマティック広告にヘッダービディングが重要な理由は、このためです。

ヘッダービディングラッパーとは

ヘッダービディング「ラッパー」は、バイヤーを管理・整理し、プログラマティックに機能するオークションルールを設定するものです。ヘッダービディングコンテナまたはフレームワークとしても知られています。パブリッシャーはラッパーを使って、1つのオークションで競争できるデマンドソースの数を最大化します。新規パートナーを追加するための作業は必要ありません。また、このラッパーが、すべてのパートナーの入札リクエストを一斉に受け入れられるようにします。入札プロセスからパートナーを脱落させたりと、管理タスクを実行することも可能です。

ヘッダービディングには、主に2つのタイプのラッパーがあります。技術的な面を考慮して、どちらを選ぶかを決めましょう。

独自のラッパー： ラッパーのプロバイダーがデマンドパートナーとセットアップを管理します。Index Exchangeは業界で2番目に多く使われているラッパー（普及率23%）で、独自のコードを使用しています。デマンドサイドのパートナーの多くは、このラッパー技術を使っています。この方法は、パートナーにより依存することになる一方で、実装は簡単で必要な時にサポートが受けられます。ラッパーのプロバイダーは、通常業務の最適化・管理をサポートするアナリティクスツールも提供しており、多くの場合、オートメーションを使用してアドサーバーにデータ項目を追加することも可能です。

オープンソース型ラッパー ： オープンソース技術（通常はAppnexusのPrebid.jまたはPubfood.js）を使用したカスタムラッパー。独自のルールと機能の設定ができますが、サポートとアップデートに多くの技術的なリソース要します。Prebid.jsは業界で最も多く使用されているオプションで、26%と高い普及率です。その他のオプションとして、サーバーサイドセットアップ向けのPrebid Serverや、iOS・Androidモバイルアプリ向けのPrebid Mobileなどがあります。

サーバーサイドヘッダービディングとは

複数の広告主がヘッダービディングラッパーに直接接続する際、そのページでは多くのJavaScriptが実行されるため、読み込み時間が長くなりがちです。最も遅い入札者は、全体の入札時間を制限することにもなります。これを阻止するために、パブリッシャーは入札できるデマンドソースを制限しています。しかし、これがプログラマティックヘッダービディングによって得られる収益面でのメリットを失わせることになります。そのソリューションのひとつがサーバーサイドビディングです。外部サーバーでオークションをホストするため、全体のオークションスピードが上がります。パブリッシャーはコードのスニペットを追加して、アドサーバーからサプライサイドプラットフォームに入札リクエストを送信するだけで可能になります。

アプリ内ヘッダービディングの仕組み

アドテック企業Inmobiの調査によると、31％のパブリッシャーは、仕組みを理解していないためにヘッダービディングを導入しておらず、23％は技術的な実装上の問題からこの方法を避けていることが分かりました。アプリ内ヘッダービディングも同じ原理ですが、ラッパーを必要としません。代わりに、ヘッダービディング技術は、広告リクエストを生成するSDKを実装してモバイルに適応しています。アプリ内ヘッダービディングに関するPubmaticのEbookでは次のように説明しています。「広告リクエストが生成された後は、サーバーサイドデマンドパートナーによってクラウド上でオークションにかけられます。入札が決定すると、クライアント側のSDKにレスポンスを返します。」アプリ内ヘッダービディングには、デマンドからプライマリーアドサーバーへ直接行われる方法と、プライマリーアドサーバーなしで行われる方法の2つがあります。後者は通常、インベントリの販売を担当するセールスチームを持たない開発者のためのものです。

ヘッダービディングの6つのメリット

パブリッシャー側にとって、プログラマティックヘッダービディングには複数の利点があります。競争力と収益を高める他にも、このメソッドはパブリッシャーに次のような価値をもたらします。

• 収益が増加する：「ウォーターフォール」方式の広告配信と異なり、ヘッダービディングは最高入札者が広告枠を勝ち取る仕組みになっているため、収益が増加します。
• より詳細なコントロールが可能： パブリッシャーは広告枠に入札するソースをよりコントロールすることができます。また、全体的な目標に応じて特定の広告主を優先することも可能です。
• 処理スピードが早くなる： プログラマティックヘッダービディングにより入札時間が短縮されるため、ページの読み込み時間も早くなります。よってサーバーサイドビディングを利用することで、パブリッシャーは結果的に優れたユーザー体験を提供できるのです。ただし、多数のパートナーに対応する際には、タイムアウト（時間制限）の設定を検討する必要があります。
• バイヤーの入札額を先に知ることができる： ヘッダービディングを使用しなければ、パブリッシャーはフロアプライスとウォーターフォールモデルに依存することになります。使用した場合は、パブリッシャーは何が入札されるかあらかじめ知っているためその必要はありません。
• より多くの広告主が入札できる： パブリッシャーはより多くの広告主と取り引きできるため、広告枠をめぐる競争がより多様化されます。オークションに参加する広告主が増えることは、企業が長期的に安定したビジネスを行い、市場の変化に適応していく上でも重要です。
• ユーザーに関連性のある広告を表示できる： より多くの広告主がオークションに参加することで、ユーザーには自身の関心や好みにより合った広告が表示されます。プログラマティックヘッダービディングを使用しないインプレッションに比べて、より良いユーザー体験が提供できます。

これらはパブリッシャー側の利点ですが、バイヤーにとっても、限られた広告主しか入札できなかったような質の高い広告配置にもアクセスできることが、メリットとして挙げられます。

ヘッダービディングの効果的な活用方法

1. デマンドサイドのパートナーの価値を知る

   パートナーが増えると競争が激化する一方で、すべてのパートナーを含めると、広告の読み込み時間が長くなってしまいます。そのため、最も高い価値をもたらすデマンドサイドのパートナーを特定し、長い読み込み時間でユーザー体験を損なうことがないように、パートナーの上限数を分析する必要があります。パートナーが提供するCPM（1,000回表示あたりの広告費）と、ページのレイテンシーを評価することで分析をしましょう。また、これらのパートナーがどれぐらいの頻度で入札し最高入札者になっているかも考慮する必要があります。

2. 入札者ごとにタイムアウトを定義する

   アドサーバーはすべての入札を評価してユーザーに表示するクリエイティブを特定するため、この処理スピードは広告リクエストに対する最も遅いレスポンスと同じくらいの速さにしかなりません。1つのパートナーがプロセス全体を遅らせてしまうこともあり得るため、すべての入札者に対してタイムアウトを設定することが重要です。 タイムアウトは、入札に時間がかかりすぎたパートナーを除外するように設定できます。特定のラッパーを使うと、セットアップの段階でこれらの時間制限を定義することができます。これは、最適な時間内で広告表示を確実にするためのスマートな方法です。

3. 入札者のためにコールオーダーをシャッフルする

   タイムアウトを設定すると、ラッパーの最後の入札者が上限までに入札をする可能性が低くなる場合があります。これがパートナーを苛立だせ、最高額を入札するのを妨げてしまう恐れがあります。このような状況を回避するには、入札者のコールオーダーをシャッフルしなければなりません。入札者のコール順をランダムにすることは、タイムアウトによりパートナーを一貫して除外しないようにするための最も公正な方法です。

4. HTTP/2プロトコルに移行する

   読み込み時間はヘッダービディングにとって重要なため、これを短縮し、ユーザー体験を最適化する方法を見つける必要があります。HTTP/2プロトコルは、単一のWebサーバーからWebファイルを同期せずにダウンロードすることで、ページのロード時間を改善するように設計されています。つまり、HTTP/2はクライアントとサーバー間のコンテンツのフローを最適化します。多くの場合、HTTP/2プロトコルを使用すると、ページのロード時間がすぐに短縮されます。ホストプランにHTTP/2への互換性がない場合は、アップグレードを検討するのが良いでしょう。また、これを行うには、HTTPS接続も必要となります。

このガイドが役に立ったら、プログラマティック広告のメディアバイイングについてのページもご覧ください。リアルタイム入札（RTB）やプライベートマーケットプレイス（PMP）、プログラマティックダイレクトに関しても説明しています。また、アプリ収益化のトレンドや、オーディエンスにとって最適なモバイル広告フォーマットの選び方（英語）についてのブログ記事も併せてご覧ください。