Index Exchangeの視点

ラッパーの着想、中立性、将来の展望

2015年夏までに、Index Exchange(市場のパートナーとともに)は、ヘッダー入札が業界全体にもたらすメリットを認識し、手動でしたが積極的に、パブリッシャーのサイトへのヘッダー入札の統合を実施していました。ヘッダー入札はそれ以来、透明性と競争力の向上、メディア企業の収益増という約束を果たしてきましたが、今度は、パブリッシャーにとっては実装が困難であるという痛点が明らかになりました。メディア企業のパートナー数社との話し合いにより、この新しいテクノロジーの約束は素晴らしいものである一方、パートナーをヘッダーに統合するというエンジニアリング上の課題を解決する必要があることが明らかになりました。そうでない場合、すべてのパブリッシャーがこの課題を単独で負うことになります。こうして、パブリッシャーのコミュニティ自体(アドテク企業ではなく)からヘッダータグラッパーが誕生しました。

着想

ラッパーは、パブリッシャーの実際のニーズから生まれました。ヘッダー入札は、予想外であるもののエキサイティングな方法でビジネスを変革しており、CPMとプログラマティック広告収益を押し上げていました。しかしながら、パブリッシャーにとっては、ヘッダー入札実装では、貴重なエンジニアリングと広告運用に時間が取られることになります。Index Exchangeにとって解決策は明白でした。パブリッシャーに代わって統合を実施し、Index Exchangeが問題を商品化し、シームレスに導入するためのコストを負担することでした。さらに重要なことは、運用がそれほど複雑ではない並行オークションでより多くのバイヤーにアクセスできるというメリットをパブリッシャーに与えることができるという点です。参加と統合の摩擦を軽減することにより、当社は、ヘッダーテクノロジーの導入を大幅に加速させることができることを認識しました。

製品に特化した企業として、また従業員の3分の2がエンジニアリング部門に在籍する当社が、この新製品に名前を付ける(もちろん構築も)ために頼ったのは、他でもない、献身的で責任感のある当社のエンジニアのグループでした。当初の着想は、基本的には、異なるコードのブロック(外部のヘッダー入札ライブラリ)をパブリッシャー環境に統合することであり、レイテンシ制御によりこれらをラッピングすることであったため、当社のエンジニアは、シンプルでありながら実用的な名前として、この新製品を「ラッパー」と名付けました。

まもなく当社は、最も重大な課題は、ヘッダーにおいてパートナーの信頼とサポートを得ることであることに気づきました。これらのパートナーの多くは従来、Index Exchangeと競合関係にあるとみなされてきた企業でした。これらの全ての取り組みは、どのような犠牲を払っても、透明性、中立性、協力という当社の基本原則により支えられています。当社は、全てのビッダーとより緊密に協力することにより、パブリッシャーにより多くのメリットを提供できることを理解しました。このため、数多くの会議、通話、飲食を重ね、パブリッシャーおよび数多くのトップデマンドソースとの間で理解、合意、統合が実現しました。こうしてラッパーが製品化されました。

開発と費用

当社が毎日直面する問題は、残念ながらアドテク企業の標準となってしまったテイクレート、バイアス、難読化についてパブリッシャーが考えることなく、パブリッシャーに最大の価値を提供していることをどのように確認するかということです。

ヘッダー入札の時代において、当社は一人二役を担っています。Indexがビッダーであるラッパーの参加者として(prebid.jsなど他のラッパーにも当社は参加しています)、最初のステップは、パブリッシャーに対して当社の料金体系を明確に公開することでした。当社の料金が設定され、明確な1つの料金を除き、当社のエクスチェンジに入る全てのメディア料金がパブリッシャーに渡ることが保証されます。また、当社が処理する全てのデータがパブリッシャーに属することを保証し、生の取引ログをクライアントが利用できるようにします。

ラッパーソリューション自体を提供する際に、当社はこれを料金なしの無料サービスとすることを決定しました。また、サーバーサイドではなくブラウザにラッパーを常駐させ、ラッパーを定義し、実行する全てのコードを誰もが検証できるようにしました(ブラウザ上で「ソースを表示」を選択するだけで、ラッパーコードベースを100%検証できます)。製品に透明性があり公平であると主張することと、内在する検査性により永久的に監査することは別のことです。さらに当社は、Index外部のインフラにラッパーコードをホストすることを決定しました。具体的にはAkamaiの巨大なエッジネットワーク上であり、これにより高速性が保証され、Indexインフラからの外部起動が保証されます。AkamaiにホストされたラッパーがIndexのビッダーを呼び出す際には、他のビッダーとIndexは同じ距離からの呼び出しとなります。

ラッパーはやがて評判を高めました。各参加者には、パブリッシャーが構築を決定した、透明性、中立性のある、協力的な市場に順応することが要求されます。実施者としてのラッパーには忠誠心はなく、全てのビッダーを平等に取り扱う必要があります。残念ながら市場には依然として、ヘッダー入札の参加者の間には憂慮すべき不平等が存在します。これらには、広告ライブラリサイズ(特にモバイルの拡大したライブラリに影響を与えるクライアント側のブラウザの帯域の「コスト」によりページ速度の遅延が発生する)、インフラ(グローバルデータセンターの存在またはその欠如)、速度(入札の高速化は言うは易し、行うは難し)、アーキテクチャ(以下で詳述)が含まれます。まもなく、ラッパーが実施者の役割を果たす前に、隠されていたレイテンシの問題が浮上しました。規則に同意することと、それに拘束されることは同じではありません。

パブリッシャーはタイムアウトの制御を開始し、ユーザー体験と運用ヘッダー戦略が改善しましたが、これを実施する上で課題を突きつけられたビッダーもいました。100%検証可能なコードベースであるラッパーが、ある意味、当社の応答速度によってIndexのビッダーに有利に働いていることが示唆されました。これは事実ではありません。実際のところラッパーは、パブリッシャーが設計した通りに動作します。つまり決定したことを執行します。しかしながら、この新しいパラダイムでは、全てのプラットフォームが成功するよう構築されているわけではありません。驚くべきことではないと思いますが、プラットフォームの再構築に多大な努力が必要される環境では、ラッパーを非難することははるかに簡単です。

当初より、当社はラッパーを、パブリッシャー向けの製品として紹介してきました。アイデアはパブリッシャーが生んだものです。素晴らしいフィードバックと協力により、その機能は日々成長しています。具体的には、広告配信プロセスに対するデマンド獲得プロセスの影響をできるだけ抑えるため、ラッパーの機能の大部分はユーザー体験に関するものです。パブリッシャーは、ユーザー体験の低下ではなく改善を求めています。

ラッパー、その機能または運用に関する不適切さの苦情に対処するため、当社は、ビッダーと関連するラッパーの要素の一覧表を作成しました。実際、これらは、この1年半にパブリッシャーから提出された要件です。当社は、Indexのビッダーのアーキテクチャの一部としてこれらのベストプラクティスに従い、これらを採用することにより明らかなメリットを得るすべての外部ビッダーを歓迎します。

ビッダーがタイムアウトを迎えるか、広告スロットを失った場合、それは完全に参加者のビッダーによるものです。その参加者には、パブリッシャーに(タイムアウトの増加、プリフェッチなどの機能の削除、ビッダーのランダム化、または特定の方法でのビッダーの順序付けなど)の執行を緩和するよう要請する、または参加者自身がパブリッシャーの要件に従う選択肢があります。当社は、今後、主張とコミュニケーションを行うことにより、全てのビッダーに対し、そのテクノロジーの開発、投資、成熟を加速するよう促すことを目指しています。これにより、入札の全てがパブリッシャーに渡り、収益損失を発生させることなく、参加者がラッパーの統一性を今後も自発的に信頼することが保証されます。

以下のラッパー要素の詳細の表をご覧ください。

今後の展望

ラッパーは静的な製品ではなく、パートナーなしでは構築できません。ヘッダー入札を持続可能なものにし、パブリッシャーの手による管理を継続するためには、全てのビッダーがパブリッシャーの進化の速度に確実に対応できるよう、協力する必要があります。パブリッシャーの変化するニーズを超えて、当社はさらに一歩先を進み、広告ブロッキングの時代において、改善された、より速く、よりシームレスな体験に対する消費者の期待に応える必要があります。当社は、当社のテクノロジーの使用を選択した数々の素晴らしいメディア企業と直接協力することにより当社が得た恩恵を維持するため、当社のビッダーとヘッダータグラッパーの両方を改善するための不断の努力を続けます。

毎年携帯電話を変える人が数多くいるのと同様、当社はラッパーが静的コードベースとなると考えることはできません。ラッパーは明日のニーズとともに進化し、ビッダーはそれと歩調を合わせる必要があります。

昨年、パブリッシャーのパートナーと共に、ヘッダービッダーとのパートナーシップも、ラッパーの成功に欠かせない要素でした。これにより当社は最高水準の中立性と透明性を獲得することができ、当社のエンジニアは毎日、継続的な改善を行い、期待に添えるよう取り組んでいます。当社は数多くのビッダーの認証も行い、プラットフォームのアーキテクチャの改善に関してパートナーとのコンサルティングを行いました。これにより、全ての参加者にとって全体的な効率が向上します。当社は、comScore 100にランクインする世界最大級のグローバルメディア企業の数社にラッパーを導入したことを誇りとしています。そして、その企業の数は増え続けています。

当社はこの進化の先頭を担い、統合パートナーを支援することを楽しみにしています。

ラッパーの要素

ラッパーの要素 定義 パブリッシャーをどのように支援するか(またはしないか) ビッダーにはどのようなメリット(またはデメリット)があるか 全てのビッダーが対応しない理由
ビッダーの順序付け(静的順序) 全てのビッダーは、同時に非同期的に、ラッパーから呼び出されます。しかしながら、ブラウザの内部キューにより、ビッダーは実際には、正確には同時ではなく、静的順序でミリ秒ごとに呼び出されます。 パブリッシャーは自分の選好に従って、ビッダーを呼び出す順序を選択できます。 呼び出しの間の遅延は通常1~2ミリ秒以下であり、ラッパーのタイムアウトは通常500~1000ミリ秒であるため、これによる影響は最小限です。 N/A
ビッダーの順序付け(ランダム化) ビッダーの順序は、静的ではなくランダム化されます。 パブリッシャーは、入札順序を選択するのではなく、選好の影響を避けるためランダム化により決定します。 上記と同じ N/A
レイテンシ制御と測定 全てのビッダーには、ラッパーがアドサーバーを呼び出す前に応答を完了するため、パブリッシャーが制御する同じ時間が与えられています。ラッパーから呼び出されてから応答するまでの時間、同じ手法を使って、全てのビッダーが測定されます。 レイテンシを減らし、最終的には調整することにより、パブリッシャーはレイテンシ、収益、ユーザー体験の間でのトレードオフを管理できます。一貫したレイテンシの測定により、全てのビッダーが平等に取り扱われることが保証されます。 短いレイテンシと素早い応答時間に投資したビッダーは、パブリッシャーがユーザー体験を改善するためにレイテンシを削減している場合でも、参加することができます。タイムアウトシステムを導入することにより、ラッパーは、潜在的な競争条件を良好に管理できるでなく、非同期イベントを調整し、アドサーバーに送信する最終的なシグナルに全てのビッダーを参加させることができます。 素早く反応する軽快なビッダーとなるには、大規模なエンジニアリング上の投資と豊富な経験が必要です。また、優れた技術を持つビッダーは、適切な規模のグローバルデータセンターが必要となり、このため相当のインフラ投資が必要となります。
軽快な入札ライブラリ ビッダーの規模はそれぞれ大幅に異なり、中には大規模なJavaScriptライブラリの読み込みを必要とするものもあります。ライブラリが大きくなればなるほど、ユーザーがブラウザに読み込むコードも大きくなり、特にモバイルでは、帯域制限によりユーザー体験に悪影響が生じる可能性があります。 軽快な入札ライブラリにより、ビッダーを有効にするためにエンドユーザーが消費するデータの量が最小となります。ページの読み込みデータ量全体の削減により、ユーザー体験に加えて全体のページ速度も改善します。 ライブラリ読み込みに必要な時間により、パブリッシャーが指定するレイテンシのタイムアウトをビッダーが満たせなくなる場合があるため、ビッダーの中には、パブリッシャーにラッパー外のライブラリを事前に読み込むよう依頼するものもあります。ラッパー外にライブラリを移動させた場合、パブリッシャーのエンジニアリングチームにとっての負荷がさらに増加し、レイテンシは未知となります。 少量の見事なコードにライブラリを最適化するよりは、多数のコードを書く方が簡単である場合も少なくありません。場合によっては、ビッダーは、単一の調整された開発の取り組みを通じてではなく、時間をかけて開発されました。投資と時間をかければ、ライブラリのサイズは今後も小さくなります。
プリフェッチ エンドユーザーがスクロールすることにより、あるウェブサイト上にどれだけの広告スロットがあるか、またはどれだけの広告スロットが生じるかを知る前に、ヘッダー入札APIに入札リクエストを行うこと できるだけ早く入札リクエストを開始することにより、パブリッシャーがタイムアウトを定義する前により多くの入札がラッパーに戻され、これによりパブリッシャーの収益増加につながります。さらに、この機能により、新しい広告がスクロールされて表示された際に広告読み込みを停止し、ラッパーが新しい入札を開始するのを待つのではなく、レスポンシブ広告が直ちにレンダリングされるようになります。 ビッダーがプリフェッチに対応することにより、タイムアウトが減り、その他のデマンドソースとの間で競合できるようになり、最終的には、パブリッシャーとエンドユーザーのためにより早く広告をレンダリングできるようになります。 プリフェッチには、大規模な技術インフラ、エンジニアリング、サポートのためのコストが必要となります。これは、エンドユーザーが実際に全てのスロットをスクロールして広告を表示したか否かに関わらず(つまり、表示されない広告スロットにもインフラコストがかかる可能性がある)、ヘッダーから早期に開始することにより、ページがレンダリング可能な全ての広告スロットが含まれるためです。
シングルリクエストアーキテクチャ(SRA) ビッダーは、N個の広告スロットのラッパーから1つのネットワークを呼び出し、ラッパーに複数の入札を返します。ページ上にスロットが8つある場合も、呼び出されるネットワークは1つのみです。 ネットワーク呼び出しにより、ブラウザのキュー内のリソースが消費され、ページ上のその他の不可欠な要素の読み込みがブロックされる可能性があります。このためパブリッシャーは、ネットワークの呼び出し数を制限することを好み、これは大いに役立ちます。 1つのリクエストのみを開始することにより、そのビッダーがブラウザの内部の順番により優先される可能性が高まり、ビッダーが特定のページ上で利用可能な全てのスロットに参加できることが保証されます。 これは、MRAからSRAにビッダーが移行するためのエンジニアリング集約型の作業となる可能性があります。また、SRAアーキテクチャでは、各リクエストの処理は単一のMRSリクエストよりもコストがかかるため、より多くのインフラ能力が必要となります。
マルチリクエストアーキテクチャ(MRA) ビッダーは、ページ上の各広告スロットに対し、ラッパーを通じてネットワークを呼び出します。ページ上にスロットが8つある場合、8つのネットワークが呼び出されます。 パブリッシャーのページには通常複数のスロットがあり、マルチリクエストアーキテクチャでは、各スロットがネットワーク呼び出すため、ウェブブラウザ内で輻輳が発生する可能性があります。また、複数のビッダーがMRAを使用した場合、この悪影響はさらに増大します。 ブラウザが処理を優先する方法とMRAビッダーの速度により、ビッダーが全てのスロットへの入札資格を持たない可能性もあります。例えばChromeでは、1つのドメインにつき特定の時間に処理されるTCPリクエストは6つのみです。 これは、ヘッダー入札アーキテクチャの早期の反復処理に起因する一般的なビッダーアーキテクチャです。
仲介レイヤあり ラッパーはオークションを効率的に実行し、1つの勝者を選択し、その入札をアドサーバーに渡します。 アドサーバー内のヘッダー入札に基づいた全ての価格競争を管理するためにパブリッシャーが必要とするラインアイテムの数は減りますが、アドサーバー内には参加者の入札(勝敗)の完全な記録は残りません。 主なデメリットは、価格以外の理由(例:保証された予算内での取引、ペーシングに関する問題など)により入札を優先するためパブリッシャーとの協力を希望するビッダーは、ラッパーにカスタムJavaScriptを実装している必要があることです。 N/A
仲介レイヤなし ラッパーはアドサーバーへのゲートウェイとして機能し、パブリッシャーが指定したタイムアウト内に受け取った全ての入札を直接アドサーバーに渡します。 パブリッシャーは、使い慣れたツールであるアドサーバーを使用し、落札広告の選択を管理できます。また、通常全ての入札がこの経路をたどるため、アドサーバーで非常に詳細なレポートも入手できます。全ての入札はラッパーにより同様に処理され、アドサーバーにより最終決定が行われます。 サードパーティのアドサーバーによる決定により、ビッダーにとってのレポートと最適化が簡素化されます。アドサーバーに全てのkey-valueを渡すことにより、各ビッダーは、仲介レイヤに頼るのではなく、どの取引/入札情報が送信されたかを正確に調整することができます。 N/

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です