（翻訳：Asia Plus 黒川賢吾）

2012年からRubicon Projectではヘッダータグが利用されてきた。現在このヘッダー入札のソリューションはアプリ広告での活用に向けたベータテストの段階に入った。

ExchangeWireとのインタビューにて、Rubicon Projectのモバイル統括であるJoe Prusz氏は、ヘッダー入札の活用で多様化する需要に応えることが出来る点や入札のプロセスや今後の可能性について話をしてくれた。

ExchangeWire: インアプリのヘッダー入札とはどのようなもので、どのようにして作動するのでしょうか？

Joe Prusz氏: Rubicon Projectは世界最大規模のモバイルエクスチェンジとして運用されており、何千ものブランドとマーケターを何万ものモバイルアプリやウェブ上にいる何十億ものユーザーにつなげる手助けをしています。また、私たちは業界初で唯一のヘッダー入札ソリューションの「FastLane」を、モバイル向けアプリとデスクトップのインベントリの全エコシステム向けに提供しています。

FastLaneの根本となるバックエンドのオークションの仕組みはモバイルアプリ、モバイルウェブ、デスクトップの全てで全く同じものです。しかしながらモバイルアプリ向けのFastLaneはモバイルデバイス上で、よりテクノロジーを要するもので、効率的にエクスチェンジを呼び、自身もしくは選択したパブリッシャーのアドサーバーに入札ヘッダーを返す為の非常に優れたテクノロジーがSDKに必要とされます。これは業界初、かつ業界を大きく変える可能性のあるテクノロジーです。なぜなら、モバイルアプリのデベロッパーといいますのは、無数のバラバラで、それぞれが効果的に動作しない、複雑で負担の大きいモバイルメディエーションウォーターフォールの犠牲になっており、結果として、セラーにとり最適とは言えないCPMを提供しています。これらのモバイルアプリのセラーは、ハイクオリティーのエクスチェンジを非常に必要としており、影響力の高まるプログラマティックのバイヤーからの収益を最大化したいと考えています。そのため、それぞれの入札が一つや二つのラインアイテムではなく、アドサーバー内で直接全ての価格ポイントにおいて入札競争にある状態を望んでいます。

重要なのは、ヘッダー入札を行うデスクトップファーストの会社の多くが、モバイルデバイスと直接やりとりをする経験が乏しいか、または皆無の場合もあるということです。私たちはSDKを介し、モバイルデバイスと直接やりとりをしてきた５年以上もの実績があります。これは競合にとり、なかなか追いつくことができない経験値です。

パブリッシャーやアプリのデベロッパーはどのようにこのテクノロジーを取り込むのでしょうか？どのようなプロセスが必要となりますか？

アプリデベロッパーは、私たちのSDKを組み込み、SDK経由でRubicon Projectが全てのインプレッションにおいて最初に呼ばれるようにします。このSDKは、全てのインプレッションにおいて、私たちのエクスチェンジでオークションを行い、全てのアプリデベロッパーのビジネスルール（例えば承認された広告主や最底値、プライベートマーケットプライスのルール等）を満足する最も高い価格を確認、そしてデバイスに対してビットの承認に応じたキーやバリューを返します。このSDKはその後アプリデベロッパーのプライマリーアドサーバーに対し、キーやバリューの値と共にリクエストを戻し、アドサーバー内の対応するRubicon Projectのラインアイテムに着火させます。モバイルアドサーバーはその後、決定ロジックを実行、我々のラインアイテムが入札した場合は、アドサーバーがキャッシュされた広告を届ける為にSDKを呼び込みます。ここで重要なのは、私たちはパブリッシャーのモバイルアドサーバーのロジックを変えることはしておらず、最適な決定が出来るようにより正確なデータをアドサーバーに送っている点です。

どうしてモバイルアプリのデベロッパーやパブリッシャーはインアプリヘッダー入札を必要とするのでしょうか？

端的にいいますと、デマンド側はヘッダー入札を利用することで、これまで上手く作動していなかったウォーターフォールの利用を脱却し、アドサーバー内で、本来のプライオリティに基づいた入札行為が可能になります。
より高付加価値のデマンドが存在する場合、より正確なプライオリティに応じて取引が行われることが重要です。Rubicon Projectは、昨年比で1400%もの成長を遂げたモバイルプライベートマーケットプレースの明確なリーダーであることを考えても、ヘッダー入札は高いCPM需要をパブリッシャーのモバイルアドサーバー内で正しいプレイオリティにおいて届けるのに必須のテクノロジーです。PMPのバイヤーはパブリッシャーのモバイルアドサーバー内でより効率的に広告が配信されることを知れば、Rubicon Projectの取引プラットフォームでの支出を増やしていくことはいうまでもありません。

更に、モバイルにおいてはヘッダー入札の重要性を増すような需要の多様性があることも見逃せません。例えば、標準的な広告ユニットにおいて、セラーは320x480バナー、300x250バナー、リッチメディア広告、フルスクリーンビデオ、ネイティブ広告などをリクエスト出来、これらは全てのクリエイティブのCPM価格を釣り上げる可能性があります。しかしながらこれらの多様な需要はほとんどの場合異なるバイヤーの間で存在し、異なるSDKやサーバーネットワーク、広告タグ、DSPなどを使い取引されています。これはセラーが異なるバイヤーに対してそれぞれのプロセスを介し、異なるオークションを経由して、最良とは言えないCPMに甘んじて、結果として消費者にとって最適とはいえないユーザーエクスピリエンスを提供することに繋がります。モバイルアプリ向けFastLaneにおいては、最も高額なプログラマティックバイヤーが即座に見つけられ、込み入ったモバイルのウォーターフォールを介さずにアドサーバー内の適切なラインアイテムを届けることができます。

もちろん、パブリッシャーは既存のウォーターフォールを利用するオプションを有しており、パブリッシャーが望まない限り変える必要はありません。変化を起こすのは、アプリデベロッパーにとっての収益を最大化し、不十分なメディエーションであるウォーターフォールの遅延をなくし、より良いユーザーエクスペリエンスを提供することにあります。

このサービスによりどういった問題が解決されるのでしょうか？

モバイルアプリ向けのFastLaneはリソースの活用を実現させたいアプリデベロッパーにとり、鍵となるソリューションです。といいますのはデスクトップ向けのFastLaneを利用するパブリッシャーは、通常のタグを活用したサービス利用者に対して300%ものCPMの価値が上昇するのを確認しています。また私たちのサービスにより、モバイルアプリデベロッパーにとり問題となっていた不十分で複雑なモバイルメディエーションのウォーターフォールの問題が解決されます。といいますのも、FastLaneはハイクオリティーのデマンドは、アドサーバー内で適切なプライオリティ設定が与えられるよう調整し、広告主により優れたパフォーマンスを、パブリッシャーにより良いCPMを提供することができるからです。また、私たちのサービスは通常デスクトップよりも多岐に渡るモバイル環境においても、モバイルアドサーバー内のインベントリの効率的な競争が行われるように設計されています。

このサービスは外部のデマンドも紹介できる仕組みなのでしょうか？

FastLaneはモバイル、デスクトップに関わらず、広告主により効果的にターゲトオーディエンスへのリーチの手助けをし、パフォーマンスの改善とセラーの価値向上を実現します。それと合わせて、FastLaneは、特にプライベートマーケットプレースなどからハイクオリティーの需要を集め、業界で最も広く採用され、私たちの持つオーダープラットフォームやセラーの環境に届けることができます。

一部では、“ウェブのヘッダー入札は、外部のデマンドが「ダイナミックアロケーション」と競合できる、DFPの対抗馬である”という議論になっています。これは閉じられた環境のアプリのマネタイズにおいても同様なのでしょうか？

FastLaneが、現在DFPやMoPubもしくは他のモバイルとデスクトップを行き交うアドサーバーのどれを使われているセラーにとっても、より多くのデマンドを効率的に届ける手助けを行っているのは疑いの余地がありません。現在私たちはモバイルとデスクトップの最も大規模なエクスチェンジの一つを運営しています（Pixalateによると、両デバイスにおける「セラークオリティー」におけるTop3に入るエクスチェンジとされている。）。私たちは、ハイクオリティーのインベントリとモバイル・デスクトップの両方においてプレミアムオーディエンスを提供できる当社の様なプラッットフォームに、より多くのバイヤーが支出を集約しているのを目の当たりにし続けております。