ヘッダー入札を巡ってはどうも誤解があるようです。この記事では、流布されている迷信のなかで特によく耳にするものを取り上げます。その前にヘッダー入札の基本を手早く復習する必要がある方は、PubMaticのMarcus Pousette（GCK 、SEA担当のカントリーマネージャー）による動画(英語)をご確認ください。
迷信1：ラッパーソリューションは莫大なコストがかかるものばかりだ
アドテクのプロバイダーのなかには、ラッパー内のすべてのデマンドパートナーから得られた売上について、パブリッシャーにレベニューシェアを請求するところがあり、ラッパーソリューションはパブリッシャーにとって高いものになるかもしれません。しかしこれはすべてのソリューションに当てはまることではなく、PubMaticには当てはまりません。
PrebidベースであるPubMaticのOpenWrapのように、パブリッシャーに追加コストが発生しないことを明確にしているラッパーソリューションもあります。何に対して契約するのか、そしてどれだけのコストが必要なのかをパブリッシャーに事前に正確に知ってもらう。これは大切なことだとPubMaticは強く信じています。
では、バイヤーに請求するということなのでしょうか。
ラッパーのプロバイダーとして、バイヤーや広告主から料金を徴収することはありません。費用の徴収はラッパー内の各パートナーから行われます。つまり、ビジネスモデルの一部として、本質的に各パートナーの義務なのです。
迷信2：ラッパーソリューションの実装は非常に面倒だ
コストに見合ったサービスを提供するSSPならば、パブリッシャーの代わりに全ての困難な業務を行うための専任のカスタマーサクセスチームがあります。このチームが実装プロセス全般をガイドし、バックエンドの技術的な部分は、トラブル対応を含めて全て対応してくれるはずです。
新しいラッパーソリューションの採用は、パブリッシャーからすると、ウェブページのヘッダーに1行のコードをデプロイするだけで簡単に済むこともあります。
とはいえ、パブリッシャーがSSPパートナー候補を評価する段階では、デューデリジェンスを行うことが重要です。「カスタマーサクセスチームの拠点はどこか？」「自社と同じタイムゾーンにあって、リアルタイムでサポートを受けられるか？」など、適切な質問をする必要があります。ほとんどのSSPには専任チームがありますが、チームの効果という点では、多くの微妙な違いがあるかもしれません。
迷信3：ラッパーソリューションは保守が面倒だ
適切なSSPパートナー――コードのデプロイを簡単にしてくれるところ――と組んでいれば、そんなことはありません。
ラッパーソリューションのなかには、パートナーや広告ユニットの追加や削除などの変更を加えたい時に、毎回、コードをアップデートしてデプロイしなければならないものがあります。その場合、変更は困難で時間がかかるかもしれません。パブリッシャーが新しいコードをデプロイする必要があるたびに、それによってウェブページが壊れないこと、ページの読み込みが遅くならないことを、まず品質保証チームが確かめる必要があります。この作業には時間がかかるため、多くのパブリッシャーは、コードの変更点をいくつか保留して、たとえば四半期末などにまとめて設定します。このため、一部のラッパーは、新たなデマンドパートナーの追加といった簡単な作業に何カ月もかかることがあります。
しかし、適切なパートナーと組んでいれば、ラッパーの保守は容易です。PubMaticのOpenWrapのように、コードを更新しなくてもデプロイが可能で、すぐに使用できる永続的なコードを備えたソリューションがあります。Prebidの最新版への更新、タイムアウトの変更、パートナーや広告ユニットおよび広告サイズの追加と削除など、パブリッシャーが変更したいと思う部分はすべて、簡単に利用できるUIから行えます。
迷信4：ラッパーはそのSSPのデマンドに偏る
オークションを偏向させるなどの悪質な行為を行う業者がいる一方で、主要なSSPのDNAには、透明性が組み込まれています。こうしたSSPは、GitHubのようなプラットフォームで公開されているオープンソースのコードに基づいてラッパーソリューションを構築しており、パブリッシャーはそのコードをダウンロードして調査できます。GitHubはソフトウェア開発とバージョン管理のプラットフォームで、ほとんどのテックベンダーがここにコードを格納しています。そして、PubMaticのOpenWrapがそうであるように、格納されたコードは公開されています。
適切なラッパーソリューションは、コード自体がチェックしやすいだけでなく、パブリッシャーによるリアルタイムの監視が可能です。ラッパー上のすべてのデマンドパートナーからの入札を、ブラウザ上のコンソールで見ることができ、厄介なことが起こっていないことを確認できます。
昨今、パブリッシャーが真の透明性を確実にするには、SSPからのログファイルへのアクセスが必要だという声もあります。非常に細かいデータにアクセスするのであればログファイルが最適ですが、ファイルが巨大なため、読み込んで分析することによってパブリッシャーのリソースが枯渇してしまうかもしれません。ログファイルには各パートナーと各インプレッションの入札ごとのデータが含まれているため、精査するには専門家による社内チームと膨大なリソースが必要になります。
信頼できるSSPと組むことで、頻繁に使われる分析はUIを通じて利用でき、リアルタイムで確認できます。データは通常、1時間もしくは1日といったレベルで集計されるため、より有用で、解釈に専門的なスキルを必要としません。SSPパートナーがこれまでのチェック事項を満たしているならば（すなわち、コードを自由に入手でき、すべての入札をコンソールでリアルタイムにモニターできるならば）、ログファイルへのアクセスはまったく必要ありません。
ただ、繰り返しになりますが、パブリッシャー側から適切な質問をすることが重要です。透明性は、全てのSSPが最低限おさえておくべき事項なのです。
迷信5：ヘッダー入札で得をするのはパブリッシャーだけ
ヘッダー入札はパブリッシャーにとってすばらしいものです。デマンドが増え、レイテンシー（遅延）が低下し、収益性が向上します。しかし、それだけではなく、ヘッダー入札はバイヤーにとってもプラスがあります
ウォーターフォールを廃止し、すべてのデマンドソースを単一のユニファイドオークションで競争できるようにするヘッダー入札は、バイヤーにとってインベントリへのアクセスを民主化してくれるものです。つまり、インベントリまでの経路を、パブリッシャーの広告サーバーによって決められることなく、バイヤーが望むものを自由に選べるのです。経路を自分で選択できるため、サプライパス最適化（SPO）の取り組みも、その他の関係性も自由に利用できます。.
そして、すべてのデマンドがひとつのオークションで競争することから、バイヤーは各インプレッションに公平な市場価格を支払っていることがわかります。
迷信6：ラッパーはすべて平等に作られている
全てのラッパーが平等に作られているわけではありません。ラッパーソリューションの違いによって、パブリッシャーが得ることができるマネタイズに大きな違いが生じる可能性があります。
これは、Prebidに基づくラッパーソリューションのあいだでもそうです。同じPrebidであれば、総売上はかなり似た結果になると思うかもしれませんが、そうではありません。詳しくはこちらの事例をご確認ください。香港のプレミアムパブリッシャーである9GAGが3つのラッパーをテストしたところ、市場、広告ユニット、アダプターが同じでも、マネタイズの結果に大きな違いが生じました。
導入するラッパーをRFI（情報提供依頼書）や、さらには直感だけに基づいて決めてしまうと、パブリッシャーは得られたはずの売り上げを失うかもしれません。パブリッシャーのあいだではまだなじみが薄いことですが、さまざまなソリューションのA/Bテストを実施するべきです。RFIは初期調査には有効ですが、客観的なテストを実施しないと実際のパフォーマンスは予測できません。あなたは試乗せずに新車を買うでしょうか。
新しいラッパーソリューションを検討している方は、適切な質問をするだけではいけません。テストしてみるべきです。
Originally published in Campaign Asia