前回の記事で、Open Biddingアフィリエイトプログラムが国内アフィリエイト広告業界に破壊的な影響を与えるだろうと述べさせていただきました。このプログラムにより、各アフィリエイトは広告掲載に必要なクリエイティブ情報を広告リクエストごとに返却するだけでなく、その広告リクエストの広告価値も含めることが義務付けられることになります。

この記事では、主に Header Bidding や Open Bidding によってもたらされる広告入札と接続方法の変化について説明します。

アフィリエイト広告の本来の目的は、中小規模のトラフィックプロバイダーがトラフィック規模が小さく、ビジネスチームや広告システムの技術力が不足しているため、独自の広告システムを効果的に構築できないことでした。Google、Facebook、Tencent、ByteDanceといった大手広告プラットフォームの強力な広告システム機能とビジネス能力を活用してトラフィックを収益化する必要がありました。

アフィリエイト広告市場では、中小規模のトラフィックプロバイダーは、トラフィック収益を得るために独自の広告プラットフォームを構築したり、様々な広告主と提携したりする必要はありません。彼らは基本的に、技術力と事業開発能力を長期的なパートナーに委ねることになります。一方、アフィリエイトプラットフォームは、広告収益化機能を提供することで、より多くのトラフィックを獲得し、様々な広告主により良いサービスを提供しながら、サービス料を請求します。つまり、アフィリエイト広告は双方にとってメリットのあるビジネスモデルです。

最終的に、中国におけるオープンビディングソリューションの発展は、主要アライアンスのオープン性と技術サポート能力に左右されるでしょう。オープンビディングは、トラフィックメディアプラットフォームの入札ロジックと広告チェーンに変化をもたらすでしょう。

異なるユーザーベースを持つメディア トラフィック プロバイダーは、広告ネットワークに関して異なるニーズを持っています。

レコメンデーション製品の機能を評価する上で重要な指標の一つは、ユーザーへのレコメンデーションをきめ細かく管理できる能力です。近年人気の「パーソナライズされたレコメンデーション」という概念は、本質的にはユーザーを細分化した継続的なセグメンテーションを指します。同様に、収益化の効率性に加え、アフィリエイトプログラムの運用能力を評価する上で重要な指標の一つは、パートナー管理の細分性です。

大手メディアトラフィックプロバイダーは、独自の広告プラットフォームを構築し、独自の広告主と広告システムを確立し、独自の広告リンク機能を構築する。同時に、広告アライアンスとの連携を通じて、広告ソースを補完し、広告のフィルレートを向上させる。

ユーザーベースが比較的小規模なメディアトラフィックプロバイダーは、広告ネットワークSDKと直接連携し、複数のSDKを統合して戦略を調整することでトラフィック価値を最大化する傾向があります。こうした小規模プロバイダーは、広告戦略を比較的シンプルに調整し、広告プロセス全体をSDKにアウトソーシングすることで、リソースを製品の最適化に集中させることができます。

顧客セグメントが異なれば、必要なアライアンス統合方法も異なります。

全体的な広告プロセスは次のようになります。クライアントが広告をリクエストし、アフィリエイト広告プラットフォームから広告を取得し、入札し、その後、広告が表示されて変換されます。

下の図に示すように、メディア トラフィック プロバイダーがアフィリエイト広告プラットフォームに接続するプロセスには、2 つの重要な変化要因があります。

1) 広告入札はサーバー側で行われますか、それともクライアント側で行われますか?

2) 広告の露出とコンバージョンのために、SDK を直接呼び出す必要がありますか、それともカスタム広告スタイル (純粋なネイティブ広告スタイルに類似) を構築して広告チェーンを確立する必要がありますか?

広告入札機能はサーバー側で有利ですが、すべてのアフィリエイト ネットワークがこれをサポートしているわけではありません。

入札ロジックはサーバーサイドに配置されており、論理的な観点からいくつかの利点があります。広告入札プロセスの軽量化、広告戦略の調整と運用の改善、柔軟性の向上、そして更新速度の高速化などです。一方、クライアントサイドでは、入札ロジックを変更するたびにアプリケーションの更新が必要となるため、更新速度の低下、バージョンカバレッジの不完全性、そしてメンテナンスコストの増大につながります。したがって、条件が許せば、理論的には入札ロジックをサーバーバックエンドに配置するのが一般的に最適です。

クライアントサイド入札においては、アフィリエイト広告プラットフォームがサーバーサイド入札機能を一部の中規模から大規模メディアにのみ提供しているという状況が一般的です。これらの中規模から大規模メディアは、規模が大きく、強力な研究開発力と比較的安定したサービスを備えているため、一部のクライアントにサーバーサイド入札機能を提供しています。

小規模なメディアトラフィックプロバイダーは、複数のSDKを統合することで、広告のフィルレートと収益化効率を向上させることが一般的です。この場合、クライアント側で価格比較ロジックを実行するしか選択肢がありません。クライアント側では、アフィリエイトSDKの統合広告機能を使用することで、アフィリエイト広告プラットフォームをより柔軟に制御できます。

たとえば、Google AdMob Open Bidding は複数の SDK をサーバー経由で接続せずに集約するため、入札ロジックはクライアント側でのみ実装できます。

クライアント側で入札すると、広告戦略ロジック全体がクライアント側のコード内で非常に重くなり、調整が柔軟ではなくなり、データの問題のトラブルシューティングには大量のデータレポートが必要になります。

広告の表示回数やコンバージョンのために SDK を直接呼び出すと、より詳細な制御が可能になり、独自の広告ネットワークを構築すると柔軟性が向上します。

広告コンバージョンチェーンは、主に広告インプレッション、クリック、ランディングページの読み込み、広告コンバージョン、データレポートといった機能で構成されます。これらの一連の機能は、広告機能の安定性とデータレポートの正確性を確保する必要があります。そのため、これらのチェーン機能とデータレポート機能を統合した統合SDKを使用することが最適なアプローチです。

アフィリエイト広告 SDK は、広告属性 ID レポート、広告コア行動データ レポートと統計、広告ランディング ページの読み込み速度の最適化、広告ダウンロード機能の最適化、広告不正防止機能に関連するデータ識別とレポートなど、広告チェーンにおける多くの重要な機能を実際に処理します。

中小規模のトラフィックプロバイダーの場合、独自の広告チャネルを構築することは一般的に推奨されません。SDKにカプセル化された機能を利用することが、最もシンプルかつ迅速な収益化方法です。

自社構築の広告パイプラインでは、メディアは広告ネットワークプラットフォームから広告価値（ECPM）と、広告クリエイティブ、コピー、ランディングページなどの関連素材のみを受け取ります。メディアは、これらの素材を用いて広告フォーマットを組み立てるだけでなく、コンバージョンパイプライン全体とデータレポートを実装する必要があります。このアプローチは、中規模から大規模のメディアにとって広告ソースをより適切に補完し、広告フォーマットの調整と構成をより柔軟に行うことができます。

問題は、アドネットワークプラットフォームがこのリンクをほとんど制御できず、リンク機能の最適化はメディアプラットフォームの協力に依存していることにあります。広告インプレッションもメディアのレポートに左右されるため、アドネットワークSDKに実装できる不正防止機能の一部は効果的に実装できません。そのため、アドネットワークプラットフォームは、一般クライアント向けにメディア関係者へのAPI機能の公開を控えています。

海外のモバイル広告には、Appia、Mobopatner、Glispa、Avazu、IronSource、YeahMobiといった企業が代表するアドネットワークと呼ばれるビジネスモデルがあります。これは主にCPA（Cost Per Action：行動単価）広告に当てはまります。S2S（Server-to-Side：サーバーツーサイド）モデルを介してメディアサーバーに接続し、基本的な広告クリエイティブとCPA価格を返します。その後、メディア側がクリックスルーデータとラストクリックイベントデータに基づいて費用を算出し、最終的にCPAベースで課金します。このモデルでは、アドネットワークが広告配信プロセスを完全にコントロールするため、不正トラフィックが大量に発生します。しかし、この手法は非常に柔軟性が高く、多くの中小企業が成功を収めています（下図参照）。このアドネットワークモデルは、業界では「広告仲介業者」として知られる広告配信業者のグループも生み出しました。これについては別の機会に説明します。

つづく...

-終わり-