アプリ配信の成長: RTA

RTA （RealTime API）は、中国語で「リアルタイム広告API」を意味し、広告検索の段階でRTAインターフェースを通じて広告主に自社の広告が入札に参加しているかどうかを尋ねるプラットフォームです。プラットフォームは情報を受け取った後、広告を検索して呼び出します。

1. 背景

新しいものの出現には、必ず一定の需要背景が伴います。まずは、RTA 製品の需要背景を理解しましょう。上の記事「マーケティングAPIについて」では、広告主が広告を出すための3つの方法について触れました。広告主自身のデータと技術に依存するADXに接続された自社構築DSPを除き、残りの2つの方法、つまりメディアバックエンドにアカウントを開設する方法と、MAPIに接続してトレーディングデスクを構築する方法は、どちらも広告プラットフォームの能力構築に依存しています。広告主は独自の DSP を構築するために深い技術的経験を必要とするため、通常はメディア バックエンドでアカウントを開設するか、MAPI に接続してトレーディング デスクを構築し、独自のアプリ プロモーションのニーズを満たすことを選択します。

プロモーションの初期段階では、広告主は広告プラットフォームが提供するターゲティング機能を通じて顧客を獲得できます。しかし、インターネットの配当が消滅したことにより、広告主が顧客を獲得することはますます困難になり、コストが上昇しています。以前の広範な配信は現在の市場には当てはまらなくなり、洗練された配信は広告主にとって不可欠な選択肢となっています。広告主のデータと広告プラットフォームの技術的機能を組み合わせて配信を支援することは、効果的なソリューションです。

では、広告プラットフォームが誕生する前は、広告プラットフォームのターゲティング機能の欠如を補うために、どのようにサードパーティのデータを使用していたのでしょうか?とても簡単です。「マーケティング API について」でも触れましたが、MAPI の非常に重要な機能はデータのフィードバックです。 DMP APIでもユーザー行動データフィードバックAPIでも、広告主はこれを利用して必要なターゲティングデータをDMPプラットフォームに返すことができます。広告プラットフォームは自社のDMPとDSPを連携させ、広告主がアップロードしたデータを使ってターゲティング配信を行います。広告主データは、ターゲティングを補うだけでなく、OCPX という重要な応用シナリオもあります。広告プラットフォームが OCPX の使用を推奨するのは、バックリンク データを取得し、データ機能を充実させ、モデルの最適化を支援するためです。

データ転送用の MAPI がすでにあるのに、なぜ広告プラットフォームは RTA を導入したいのでしょうか?検討の理由は主に以下のとおりです。

1. ユーザーのプライバシーとデータセキュリティを保護するため、広告主は API を介して外部プラットフォームにデータをエクスポートすることはなくなりました。ユーザーデータは自社のプラットフォームでのみ使用できます。
2. MAPI 経由のデータ転送には遅延があり、データのリアルタイム性は保証されません。RTA インターフェイスを使用すると、プラットフォームのリアルタイム方向機能の欠如を補うことができます。

2. RTA広告プロセス

広告検索段階では、広告プラットフォームは RTA インターフェースを通じて広告主に広告が入札に参加しているかどうかを尋ねます。情報を受け取った後、広告プラットフォームは広告の検索とリコールを実行します。完全な RTA 広告プロセスを下の図に示します。

1. フロントエンドは広告リクエストを開始し、バックエンドの広告サービスを要求します。
2. 広告サービスでは通常、広告が最終的にフロントエンドに送信され、ユーザーに表示されるまでに、広告の検索、広告のリコール、大まかな広告ランキング、広告の詳細なランキングなど、いくつかのプロセスが実行されます。
3. RTA 要求タイミング: 上記のプロセスのいずれにも RTA が挿入されないのはなぜでしょうか。その理由は、RTA は広告取得から広告配信までのあらゆるリンクに適しているためです。ただし、広告プラットフォームと広告主の処理ロジックはリンクごとに異なります。そのため、RTA に接続する場合、広告主開発者は相手側と RTA を要求するタイミングを明確にする必要があります。
4. RTA タイムアウト制御: RTA はタイムリーさに対する要件が非常に高いため、タイムアウトなどの問題が発生した場合、プラットフォームによって処理メカニズムが異なります。一部のプラットフォームでは、タイムアウト後に広告主はこのトラフィックを必要としないと想定しますが、一部のプラットフォームではその逆で、広告主はこのトラフィックを必要としていると想定します。したがって、開発者が RTA に接続する場合、RTA のタイムアウト期間とタイムアウト処理ロジックを相手側と明確にする必要があります。
5. RTA 制御ディメンション ロジック: RTA の制御粒度は、広告アカウント、広告プランなどのディメンションに設定できますが、プラットフォームによって制御粒度は異なります。粒度が細かくなるほど、広告主はより洗練された制御を行うことができます。現在、ほとんどのプラットフォームは、まだ広告アカウント ディメンションに設定されています。開発者が RTA と接続する場合、RTA の制御範囲を相手側と明確にする必要があります。
6. RTA 入札: 現在主流の広告プラットフォームの RTA インターフェースは、入札 (または価格係数) の設定をサポートしています。広告主開発者は、独自のデータに基づいてこのトラフィックの価値を見積もり、入札を主導できます。一部の RTA インターフェースは、入札に似ており、現在のトラフィックの値を返す品質スコアもサポートしています。RTA に接続する場合、開発者は、RTA が入札をサポートしているのか、品質スコアをサポートしているのかを相手に明確にする必要があります。
7. DPA 広告: 現在、主流の広告プラットフォームの RTA は商品 ID を返す機能をサポートしています (事前に広告プラットフォームの商品ライブラリに接続する必要があります)。つまり、DPA 広告を配置することができ、リマーケティングやトラフィックに対するさらに細かい操作に適しています。 RTA に接続する場合、開発者は RTA が DPA 広告をサポートしているかどうかを相手に確認する必要があります。
8. モニタリングリンク: 露出とクリックのモニタリングをサポートする広告プラットフォームの場合、一部のプラットフォームのモニタリングマクロは RTA_ID をサポートしています。これにより、RTA 戦略によってどの広告が勝ったかを区別し、広告トラフィックの品質を監視できます。たとえば、露出とクリックのモニタリングデータに不明な RTA_ID が表示された場合、トラフィックに問題がある可能性があります。 RTA に接続する場合、開発者は、監視リンクが RTA_ID マクロ パラメータの置き換えをサポートしているかどうかを相手に確認する必要があります。

3. RTAアクセス

RTA は、リアルタイム ターゲティング機能を拡張する API として、広告の効果を高めることができます。まず、広告主は確かにアクセスしたいのですが、広告プラットフォームは一般的にデータのセキュリティと適時性を考慮してアクセスしきい値を設定しており、これは ADX への接続と似ています。

1. 消費閾値: 広告プラットフォームが RTA 機能を開放するとデータ出力のリスクがあるため、広告プラットフォームは通常、KA 顧客向けにのみ RTA 機能を開発します。
2. 技術的なハードル: RTA は、高いタイムリーさが求められるリアルタイム インターフェースです。そのため、広告主の開発者は、RTA に接続するには優れた技術的経験が必要です。
3. データ機能: RTA の効果を最大化するには、広告主データと広告プラットフォームの技術的機能を組み合わせる必要があります。そのため、広告主開発者は、特定のデータ機能を備え、ファーストパーティ データに基づいてトラフィック品質を評価し、トラフィックの価値を測定できる必要があります。

RTA プラットフォームを構築する際、広告主はインターフェースのタイムアウト問題に注意する必要があります。タイムアウト率が高すぎると、プラットフォームは RTA 機能をシャットダウンする可能性があります。特に、広告主が広東通、Juliang、Baidu のトラフィックなどの主要プラットフォームの RTA に接続している場合、RTA リクエストが毎回広告主に送信されると、必然的に広告主のサーバー上の QPS が大量に発生し、圧力に耐えられなくなる可能性があります。

したがって、QPS を向上させるために、広告主開発者はキャッシュ メカニズムを設定し、キャッシュされたデータの使用を優先することができます。この時点で、キャッシュの有効期限の問題を考慮する必要があります。有効期限を設定することに加えて、ユーザーがアプリをインストールしてアクティブ化したときや、ユーザーが広告された製品を購入したときなどのシナリオでは、ビジネス ロジックに基づいてキャッシュを積極的に削除する必要もあります。広告プラットフォームは、対応するキャッシュ メカニズムを設定することもできます。つまり、広告主によって「マーク」されたユーザーをキャッシュまたは記録し、広告主が次回リクエストを開始する必要がないようにします。 RTA データが蓄積され続けると、広告プラットフォームは広告主のユーザーのより多くのデータ特性を把握できるようになり、RTA の数が減ります。同時に、OCPX モデルのトレーニングに使用されるなど、広告主から広告プラットフォームへのデータの蓄積によるメリットも明らかです。

RTA を構築する際、広告主は次の指標に注意する必要があります。

1. タイムアウト率: タイムアウト率が高いと、広告プラットフォームと広告主開発者の両方にとって好ましくない状況になります。プラットフォームは RTA 機能をシャットダウンする場合があります。
2. RTA 有効収益率: 有効な RTA 結果の比率。この比率が低すぎると、RTA の消費量が少なくなります。プラットフォームは、RTA が広告主に大きな効果の改善をもたらさなかったと判断し、RTA 機能をシャットダウンする可能性があります。
3. RTA 消費比率: RTA に参加している消費が市場全体の消費に占める比率。RTA 参加率に類似。
4. RTA マッチング分析: 監視リンク内の RTA_ID データと RTA 有効な戻りデータを組み合わせて、最終的な RTA マッチング状況を分析します。
5. …

4. RTAアプリケーション

RTA はリアルタイムのオリエンテーション機能を提供しますが、どのようなシナリオで最大限に活用できるのでしょうか?以下は、電子商取引業界でよく使用されるシナリオです。読者の皆さんがより良いシナリオをお持ちの場合は、ぜひ一緒に議論してください。

1. 新規顧客を獲得する

広告主がアプリを宣伝する場合、必ず新しいユーザーを引き付け、新しい顧客を獲得する必要があります。目標は新規顧客を獲得することであるため、既存顧客に広告を配信すると予算が無駄になり、既存顧客のユーザー エクスペリエンスに影響します。したがって、新規顧客を獲得するための広告を配信する際には、既存顧客を除外する必要があります。ユーザーがアプリの新規ユーザーか既存ユーザーかを判断する方法を知っているのは広告主だけであり、判断基準は広告主ごとに異なるため、広告プラットフォームはこれらのユーザーをブロックすることはできません。 RTA インターフェースを通じて、広告主はこのトラフィックに対して新しい広告を掲載するかどうかを自ら決定できるため、広告の効果が向上します。

2. 個人情報保護方針

現在、主流の広告プラットフォームはすべて、RTA リターン結果で製品情報を返すことをサポートしており、広告主は内部の推奨データを組み合わせて、このトラフィックに最も適した広告素材をプッシュできます。広告主の開発者は、ユーザーのパーソナライズされたデータを計算するために、リアルタイム + オフライン方式をサポートする必要があります。これには、時間消費の問題を考慮する必要があります。結局のところ、リアルタイムの推奨は、RTA の適時性要件を満たさない可能性があります。

3. 周波数制御

広告業界では、同じユーザーを複数回ターゲットにしても効果は上がらない、むしろユーザーが広告を見る頻度を一定の範囲内にコントロールする必要がある、という認識があります。広告主がアプリを宣伝する場合、通常はさまざまなチャネルを使用して広告を配置します。 RTA 以前は、広告主は通常、1 つのチャネルに対してのみ頻度制御設定を設定できました。 RTA を使用すると、すべての配信チャネルが RTA をサポートしていれば、広告主はグローバルな頻度制御を実現し、配信コストを節約し、配信結果を向上させることができます。

4. トラフィック階層化操作

アプリ運営システムでは、アクティビティレベルによってユーザーのトラフィック値が異なり、アクティビティレベルが高いほど、対応するトラフィック値も大きくなります。そのため、広告主は通常、アクティビティ レベルの異なるユーザーに異なる品質スコアを割り当て、それに応じた運用戦略を設定します。 RTA インターフェースはトラフィック品質スコアを返すことをサポートしているため、広告主はこのフィールドを使用して、このトラフィックのスコアを広告プラットフォームに伝えることができます。この情報を受け取ると、プラットフォームはプラットフォーム側に動的な入札機能を追加し、広告主がこのトラフィックに対してより競争力を高め、階層化されたトラフィック操作を実現できるようにします。

5. RTA 対 RTB

RTB（RealTime Bidding）は中国語で「リアルタイム広告入札」を意味します。広告主は、ADXトラフィックごとにトラフィック値、CTR、CVRを推定し、入札に参加するかどうかを決定できます。参加する場合は、対応する広告素材と入札を返す必要があります。広告主は自社構築のDSPを通じてADXに接続します。プラットフォームメディア側のコンテキスト情報（コンテキスト）、ユーザーメディアのユーザー行動（ユーザー）、他の広告主からの一般化されたデータが不足しているため、同じ技術力では、広告主のCTRとCVRの推定モデルも比較的限られています。

RTB と RTA は名前に 1 文字の違いしかありませんが、これらはまったく異なるツールです。主な違いを下の図に示します。

1. 広告の所有権: RTA 広告は広告プラットフォーム側で作成され、RTB 広告は自社構築プラットフォーム側で作成されます。
2. 入札: RTA の入札は、プラットフォームの入札 * ユーザー品質スコア、または RTA のリアルタイム入札になります。RTB の入札はリアルタイム入札です。
3. ターゲティング: RTA のターゲティングは、プラットフォーム側のターゲティングと広告主のリアルタイム ターゲティングを組み合わせたものです。RTB のターゲティングは、主に自社構築のプラットフォームのターゲティング機能です。
4. ターゲティングの粒度: RTA のターゲティングの粒度はアカウントおよびプラン レベルに設定できますが、RTB のターゲティングの粒度は広告レベルです。
5. データ: RTA は広告プラットフォーム データと広告主データの両方を使用しますが、RTB は広告主データのみを使用します。

VI. 結論

RTA は、過去 2 年間に登場した広告テクノロジー機能です。その中核となるのは、ターゲット最適化、入札最適化、DPA 最適化など、広告プラットフォームの技術的機能と広告主データを組み合わせて、リアルタイム広告をより効果的に支援することです。さまざまなプラットフォームによる RTA の詳細な議論と研究により、この業界はより多くの活用方法を提供することが期待されています。

著者: jdyx728

公式アカウント: 商用製品に関する日々のメモ、製品、運用、コードを理解する商用製品マネージャー