re:Invent 2024: AWSでPrebid Server導入による広告収益化の効率化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Streamline ad monetization with Prebid Server Deployment on AWS (ADM302)
この動画では、AWS上でのPrebid Server導入による広告収益化の効率化について解説しています。オムニチャネルのコンテンツプロバイダーが広告プラットフォームと直接接続するニーズが高まる中、オープンソースのPrebid Serverを活用した解決策を提示しています。このソリューションは10万TPS以上の処理能力を持ち、AWS Well-Architected原則に従って設計されています。Amazon CloudFront、ECS、AWS WAFなどのAWSサービスを活用し、低レイテンシーで安全な広告オークションを実現。さらに、Amazon Athena、Amazon Redshift、Amazon SageMakerとの連携により、広告データの分析も容易に行えます。実装ガイドやCloudFormationテンプレートも提供され、Video広告やAMP対応など、今後の機能拡張も計画されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Prebid Serverによる広告収益化の効率化：課題と解決策
ご紹介ありがとうございます。私はStephanie Layserです。このヘッドセットを初めて着けることができて、とてもうれしく思います。私はWorldwide Head of Publisher Ad Techとして、Webサイト、モバイルアプリケーション、CTVアプリケーションにおける収益化について、お客様のサポートを行っています。本日は、AWS上でのPrebid Server導入による広告収益化の効率化についてお話しさせていただきます。そして私はMike Olsonです。AdTechとMarTechソリューションのSoftware Development Managerを務めており、本日ご紹介する解決策を構築したチームを率いています。
こちらは私たちの写真で、お名前とお顔を結びつけていただけると思います。 本日のアジェンダですが、まず最初にお客様が抱える課題についてお話しします。次にPrebidの簡単な紹介として、Prebidとは何か、そして広告収益化にどのように役立つのかについてご説明します。その後、MikeからAWS上でのPrebid Server導入についての概要をご説明します。最後に、今後の展開として、現在開発中の内容や、この製品をどのように進化させていくのかについてお話しします。
ご存知の方も多いと思いますが、オムニチャネルのコンテンツプロバイダーが広告プラットフォームと直接接続するケースが増えています。例えば、DisneyはDRAXという形で広告プラットフォームとの直接接続を展開しており、Paramount PlusはConduitと呼ばれるものを通じて広告プラットフォームと直接つながっています。また、小売メディアネットワークも、収益化を促進するために独自のSSPを構築し、DSPやSSPとの直接接続を目指しています。
広告プラットフォームとの接続を自社で所有することには、大きなメリットがあります。その一つが、オークションの仕組みの透明性です。つまり、オークションがどのように実行されているかを正確に把握し、それをコントロールできることです。また、判断ロジックを修正する能力も重要です。例えば、私がNews Corpにいた時は、MagniteやIndexを通じて来るすべてのDeal IDを優先できるように、Prebid Serverの判断ロジックを修正していました。この カスタマイズはPrebidのコード内で行われ、広告収益化を支援するために私たちが独自に修正を加えたものでした。
さらに、Log-levelデータの完全な所有権も得られます。従来の広告サーバーを使用する場合、Log-levelデータはバッチで提供されるため、リアルタイムでの意思決定が難しい状況でした。広告接続を自社で所有することで、そのLog-levelデータの完全な所有権を持つことができ、既存のインフラストラクチャやツールにストリーミングすることが可能になります。これにより、高価値ユーザー向けのサブスクリプションペイウォールの管理や、広告価値の低いユーザーに対する調整など、購読傾向に応じた製品パフォーマンスの最適化が可能になります。コンテンツ体験や製品体験が生成AIによって推進される時代において、このデータをリアルタイムで所有し、コントロールできることは、ビジネスの発展に大きく貢献するでしょう。
Prebid Serverとは一体何なのでしょうか？実は、Prebid Serverは現在市場に存在する最も人気のある統合オークションソリューションです。OpenRTBをベースとし、透明性のあるオークションを実行するコネクターを備えています。完全にオープンソースで、アドテックコミュニティによって開発が進められています。誰でもGitHubにアクセスして変更を加え、オープンソースコミュニティに貢献することができます。また、設定変更も可能です。大企業から小規模企業まで、必要に応じて変更、修正、設定ができるため、あらゆるニーズに対応できます。多くのお客様から、Prebid Serverを導入したいが、インフラ構築が難しいという声が寄せられていました。大規模で低レイテンシーのワークロードの運用経験がなく、ロードバランシングをAWS Well-Architected原則に従って適切に設定したいと考えていたのです。また、SSPを構築したいと考えているお客様も多く、Prebid Serverはその出発点となります。Prebid Serverは、パブリッシャーが広告オークションをコントロールする機能を提供します。
AWS上のPrebid Server導入：アーキテクチャと将来展望
そこで、スケーラブルでコスト効率の高いPrebid Server Deployment on AWSソリューションをご紹介します。このソリューションを使用すると、お客様独自のAWSインフラストラクチャ上にPrebid Serverを展開することができます。10万TPSを超える本番環境レベルの可用性、スケーラビリティ、低レイテンシーを備えたPrebid Server用のエンドツーエンドインフラストラクチャを手に入れることができます。これはお客様独自のVPC内にあるため、すべての運用データとビジネスデータの所有権はお客様にあります。Prebid Serverのメトリクスは、Amazon Athena、Amazon Redshift、Amazon SageMakerなど、さまざまなクライアントとシームレスに統合できるAWS Glue Catalogで利用可能です。
このソリューションの主な利点は非常に重要です。大規模で低レイテンシーのワークロードと大量のリクエストを処理できるスケーラビリティを備えながら、コスト効率の高い展開が可能です。意思決定ロジックとトランザクションデータの完全な管理権限を持つことができます。BIツールとの簡単な統合が可能で、Expoホールでご覧いただける多くのパートナー企業が、Amazon QuickSightやQuickSight with Qなどの AWSツールと同様に、私たちのPrebid Serverソリューションと直接統合することができます。さらに、コードベースは完全にオープンソースでコミュニティ主導であり、公平性が確保され、オークションを完全にコントロールすることができます。
Prebid Server Deployment on AWSを利用すると、AWSが完全にサポートおよび保守する、本番環境対応のPrebid Serverパッケージを受け取ることができます。ソリューション自体は完全に無料で、使用したAWSサービスの分のみお支払いいただきます。このソリューションは完全にオープンソースで、Apache 2ライセンスの下でGitHubで公開されており、お客様のチームがコードを確認し、必要に応じてカスタマイズすることができます。ただし、ソリューションを一緒に進化させるため、検討されている変更についてお聞かせいただければ幸いです。このプロジェクトはCDKプロジェクトであり、事前生成されたCloudFormationテンプレートとしても利用可能です。実装ガイドには包括的なドキュメントが含まれており、厳密なセキュリティテストと負荷テストを含む、AWSサービスと同じ高い基準で維持されています。開発チームによる継続的なサポートとアップデートも提供されます。
アーキテクチャの詳細に入る前に、このソリューションの設計時に対処した課題をいくつかご紹介します。QRコードから実装ガイドのアーキテクチャページにアクセスできます。リアルタイムビディングの性質上、オークションを迅速に実行し、広告をすばやく表示するために、大量のトラフィックを低レイテンシーで処理できるソリューションが必要でした。また、レポート、インサイト、意思決定のために、お客様がデータを完全にコントロールできる必要性にも対応しました。Prebid Serverは簡単に設定でき、ソリューション全体もカスタマイズ可能である必要がありました。お客様のAWSアカウントにおけるさまざまな制限やガイドラインを特定し、それらを設定オプションとしてソリューションに組み込むことで、ソースコードを修正する必要性を減らしました。もちろん、セキュリティと可観測性も重要な要件でした。
Prebid Auctionのリクエストがどのように処理されるのか、そのアーキテクチャを順を追って見ていきましょう。左側から順に説明すると、ユーザーがあなたのWebサイトのページを読み込むと、そのWebページがPrebid.jsを読み込みます。
Prebid.jsは、Prebid.orgが提供するオープンソースライブラリで、クライアントサイドでの大部分の処理を担当し、オークションリクエストの準備とPrebid Serverへの送信を行います。クライアントサイドでは他のHeader Biddingラッパーを使用することもできますが、ここではPrebid.jsを使用するケースを想定して説明します。Prebid Serverへのリクエストには、ユーザーに関する情報、ページリクエスト、そしてオークションを実施したい広告枠に関するすべての情報が含まれています。この時点で、ユーザー同期やCookie同期など、さらに多くの処理が行われる可能性があります。
入札リクエストはAmazon CloudFrontに届きます。 CloudFrontを使用することで、リクエストをできるだけ早くAWSネットワークに取り込み、レイテンシーを低く抑えることができます。また、セキュリティを強化するためにAWS WAFも統合されています。これはソリューションのカスタマイズ可能な部分の1つなので、別のCDNを使用したい場合はその選択肢もあります。もし、トラフィックの大部分がデプロイ先のリージョン付近から発生すると予想される場合は、コスト削減のためにこの部分を省略することも可能です。
リクエストはロードバランサーに届き、 そこからPrebid ServerをホストしているECSクラスターに分散されます。ECSクラスターではPrebid ServerのJavaバージョンが稼働しています。ここでは、メンテナンス負荷を低く抑えるためにECSのサーバーレスバージョンであるFargateを使用しています。自動スケーリングが有効になっており、このクラスターは1秒あたり10万リクエスト以上まで処理できることが確認されています。スケーリングは最初、コストを抑えるために2つのタスクから始まりますが、AWSアカウントの制限まで拡張可能です。ソリューションをデプロイした後は、コンソールでクラスターの設定を調整することができます。
そこから、 Prebid Serverがオークションを実施し、すべての入札リクエストをビッダーに送信します。ここでは1つのビッダーしか表示していませんが、実際にはもっと多くのビッダーがあるでしょう。オークションが完了し、すべての入札が返ってくると（設定によっては一部の入札がタイムアウトする可能性があります）、結果はユーザーに戻され、Prebid.jsが処理を引き継ぎます。その後の流れは、セットアップ方法によって異なります。Ad Serverを使用している場合は、結果をAd Serverに送信し、そこで広告枠に対する他の需要源を評価して、最終的にどの広告を表示するかを決定します。Ad Serverを使用していない場合は、Ad Serverをバイパスするか、広告を直接表示することもできます。
アーキテクチャのもう一つの重要な部分は、Prebid Serverのメトリクスに関するものです。Prebid Serverは、リクエスト時間、Bidderごとのリクエスト時間、平均価格など、様々なメトリクスを常時出力しています。これらのメトリクスはEFSボリュームに流れ込み、AWS DataSyncを使用して定期的にS3バケットに転送されます。その後、AWS Glue Jobがデータの変換処理（ETL）を実行し、最終的にメトリクスはAWS Glue Catalogに格納されます。これらのログやメトリクスには、Amazon Athenaを通じてアクセスでき、Athenaやクエリを直接使用して、ほぼすべてのBIツールと連携することができます。実際にどのようなクエリが可能かを示すサンプルクエリも、Implementation Guideで提供しています。最後に、上部にはCloudWatchのメトリクス、アラーム、ランタイムログがあります。
このスタックを導入する最も簡単な方法は、事前に生成されたAWS CloudFormationテンプレートを使用することです。ここにあるQRコードをスキャンすると、CloudFormationテンプレートにアクセスできるソリューションのランディングページに移動します。CDKプロジェクトを通じてデプロイしたい場合や、まずコードを確認したい場合は、GitHubリポジトリにアクセスすることができます。GitHubリポジトリへのリンクは、Implementation GuideのDeveloper Guideセクションで確認できます。デプロイ時には、いくつかのオプションを指定することができます。その一つが、先ほど説明したAWS CloudFormationを使用するかどうかです。もう一つのオプションは、私たちが提供するPrebid ServerのDockerコンテナを使用するか、独自のものを提供するかです。完全にテスト済みで動作が確認されているため、私たちが提供するものを使用することを強くお勧めしますが、アナリティクス用にカスタムのPrebid Serverモジュールを作成する場合は、独自のDockerコンテナをパッケージ化してデプロイ時に指定することも検討に値します。
スタックのデプロイが完了したら、次はPrebid Server自体の設定に移ります。Prebid Serverには数多くの設定オプションがあり、非常に柔軟性が高いことが大きな利点の一つですが、すぐに使える適切なデフォルト設定ファイルも提供しています。最初に本当に設定する必要があるのは、実際のBidderだけです。Prebid Serverでは、Bidderがオープンソースのアダプターを提出または作成し、それがPrebid Serverプロジェクトに組み込まれます。これらのアダプターは、リクエストがファンアウトする際にBidderへの呼び出しを行う役割を担っており、それぞれのアダプターに固有のオプションセットがあります。これらの情報はすべて、広告パートナーに問い合わせて入手する必要があります。
その後、クライアントとアドサーバーの設定に移ります。クライアントについては、先ほど説明したPrebid.jsを使用します。基本的には、オークションを実行するためにPrebid Serverを指定するように設定するだけですが、Prebid Server同様、多くの設定オプションが用意されています。アドサーバーを使用する場合は、ライン項目などの設定が必要になることがあります。これらの情報については、Prebid.orgで詳しく解説されています。この時点で、デプロイメントの監視を開始する準備が整います。
今後の展望についてですが、このソリューションは今年の夏にリリースされたばかりで、現在は初期のお客様やユーザーからフィードバックを収集し、 それらをロードマップに反映している段階です。最近リリースされたv1.1バージョンには、すでにいくつかの改善点が組み込まれています。現時点では、標準でBanner広告のみをサポートしていますが、Video広告、AMP、モバイル対応の追加に向けて積極的に取り組んでいます。Stephanieも言及したように、Prebid Serverのデプロイと運用を容易にすることには大きな価値がありますが、お客様が特に関心を持っているのはリアルタイムの意思決定機能であり、これが私たちの次なる注力ポイントとなります。すべての広告取引記録を含むトランザクショナルデータレイヤーの構築を検討しており、これによってこれらの意思決定が可能になります。
これらの意思決定には、トラフィックシェーピングのさまざまな側面が含まれます。リクエストが届いた時点で、ユーザーの種類、ページ、広告枠に基づいて、どのBidderにリクエストを送信するかを判断できます。Bidderの数を減らすことができれば、オークション中の時間とコストを節約できる可能性があります。これらの機能の定義はまだ初期段階ですので、ご興味のある方はぜひお声がけください。詳しくお話させていただきたいと思います。セッション終了後、会場の端で待機していますので、お気軽にお声がけください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion