モバイルアプリ向け TMP
モバイルアプリは、各インプレッションをどのアドネットワークが提供するかを選択するためにメディエーション層を使います。メディエーターは需要ソース — アドネットワーク、入札パートナー、直接ディール — を評価し勝者を選びます。TMP はこのモデル内の追加需要ソースとして統合します。メディエーターのオークションまたはウォーターフォールで既存のネットワーク需要と並んで競う、事前交渉された AdCP パッケージをアクティベートします。今日どう機能するか
モバイルパブリッシャーは、アドネットワーク、ウォーターフォール優先度またはインアプリ入札ルール、プレースメント定義でメディエーション SDK を設定します。広告機会が生じると、メディエーターは期待収益に基づいて最良のソースを選択します。AdCP パッケージはこの決定へのパスを持ちません — AdCP システムに存在しますが、メディエーション層はそれらを評価する方法を持ちません。 TMP はこのギャップを橋渡しします。パブリッシャーのアプリは、広告機会が生じると TMP ルーターを呼ぶ TMP SDK を含みます。アクティベートされたパッケージは、事前交渉された CPM を伴うカスタム需要ソースとしてメディエーション層に渡されます。メディエーターはその標準の選択ロジックを使ってそれらをネットワーク入札と並んで評価します。統合モデル
TMP SDK はアプリとメディエーション層の間に位置します。メディエーターを置き換えません — パッケージをそれに供給します。-
アクティベーション: バイヤーが ID でパッケージをアクティベートする。TMP SDK はパッケージをその事前交渉された CPM とともにメディエーターに渡す。メディエーターはその標準のレンダリングパスを通じてクリエイティブをフェッチする。これはメディエーションを通じて提供されるインタースティシャル、リワード動画、バナーの典型的なパターン。プロダクトの
trusted_match設定がアクティベーションをサポートされるレスポンスタイプとして宣言する。 -
クリエイティブ: バイヤーが完全なクリエイティブマニフェストをインラインで返す。アプリはメディエーターを通さずに広告を直接レンダリングする。これはアプリがレンダリングを制御するネイティブインフィード広告の典型的なパターン。プロダクトの
trusted_match設定がクリエイティブをサポートされるレスポンスタイプとして宣言する。
Context Match
広告機会が生じると、TMP SDK は Context Match リクエストをルーターに送ります。リクエストはプレースメントのコンテンツコンテキストを記述します。インタースティシャルの例
フィットネスアプリがワークアウト完了後にインタースティシャルをトリガーします:Request
interstitial_main プレースメントのすべての適格なパッケージを評価します。同じパッケージがすべてのユーザーについて評価されます — ユーザーによるフィルタリングはアイデンティティをコンテキストパスに漏らします。
Response
trusted_match 設定がアクティベーションをレスポンスタイプとして宣言するとき、オファーは package_id（と任意の summary）のみを運びます。メディエーターがクリエイティブフェッチを扱います。
ネイティブフィードの例
レシピアプリがそのレシピフィードにスポンサーコンテンツカードを表示します:Request
Response
trusted_match 設定がクリエイティブをレスポンスタイプとして宣言するとき、バイヤーは完全なクリエイティブ詳細をインラインで返します。アプリは別途クリエイティブフェッチなしにネイティブカードをレンダリングするのに必要なすべてを持ちます。ミールキットパッケージ（pkg-meal-native-03）は一致せずレスポンスから欠けています。
Identity Match
TMP SDK は、パブリッシャースコープのデバイストークンとパブリッシャーのseller_agent_url を伴う Identity Match リクエストを送ります。このリクエストは Context Match から構造的に分離されています — コンテンツシグナルを運ばず、時間的相関除去とともに送られます: 100-2000ms のランダムな遅延、加えてランダム化された順序（各機会は Context Match または Identity Match が先に送られるほぼ等しい確率を持つ）。
バイヤーは seller_agent_url からアクティブなパッケージセットを解決します。SDK が（下記のように）package_ids を明示的に送るとき、構成は現在のプレースメントと独立でなければなりません（MUST） — all-active（この publisher でのバイヤーのすべてのアクティブパッケージ）または fuzzed（バイヤーが黙って落とす合成の存在しない ID でパディングされたランダムサンプル）のいずれか。プレースメント固有のサブセットは禁止されています — それはバイヤーがパッケージセットを比較して Identity Match を Context Match と相関させることを許します。
Request
Response
pkg-telecom-inter-03 がなぜ不適格かを学びません — リストに欠如していることだけです。
serve_window_sec はルーターにこのレスポンスをどのくらいキャッシュするかを伝えます。TTL ウィンドウ中、ルーターはバイヤーに再クエリせずにキャッシュされた適格性を使ってインタースティシャル、バナー、リワード広告を埋めます。
結合とアクティベーション
TMP SDK は Context Match と Identity Match の結果をローカルで結合します。両方のレスポンスに現れるパッケージ — コンテキストによってアクティベートされ、アイデンティティによって適格 — のみがメディエーターに進みます。インタースティシャルアクティベーション
上のインタースティシャルの例から:
2 つのパッケージが通過:
pkg-sports-inter-01 と pkg-nutrition-inter-02。TMP SDK はそれらを事前交渉された CPM とともにメディエーション層にカスタム需要ソースとして登録します。
ネイティブフィードアクティベーション
プロダクトのtrusted_match 設定がクリエイティブをレスポンスタイプとして宣言するネイティブ広告については、アプリは Context Match レスポンスで返されたクリエイティブマニフェストから直接レンダリングします。メディエーターは関与しません。アプリは context match オファーを identity match の eligible_package_ids と交差させ、独自のランキングロジックを使って最良の適格オファーを選び、creative_manifest アセットを使ってネイティブカードをレンダリングします。
リワード動画
リワード動画はインタースティシャルと同じアクティベーションパターンに従います。プレースメントはリワードスロットを識別します:プライバシー考慮事項
モバイル TMP はすべてのサーフェスと同じ構造的分離に従います:- Context Match はコンテンツシグナルとプレースメントデータを運ぶ。リクエストにデバイス識別子なし、ユーザートークンなし、IDFA/IDFV なし。
- Identity Match はパブリッシャースコープのデバイストークンとバイヤーパッケージ ID の完全なリストのみを運ぶ。コンテンツシグナルなし、画面名なし、トピック ID なし。
- 時間的相関除去 が 2 つのリクエスト間のタイミングと順序ベースの相関を防ぐ。TMP SDK はランダムな遅延（100-2000ms）を導入し かつ どちらのリクエストが先に送られるかをランダム化する — 各機会は Context Match または Identity Match が先に行くほぼ等しい確率を持つ。
- パッケージセット相関除去: Context Match はパッケージリストを送らない — プロバイダーはプレースメント上のすべてのユーザーについて同じ同期されたパッケージセットを評価する。Identity Match はバイヤーのすべてのパッケージを送る。どちらのパスも、どのパッケージが現在の機会に関連するかを明かさない。