配信先でのオーディエンスの活用

このガイドでは、Adobe Real-Time Customer Data Platform （RT-CDP）から外部の宛先にオーディエンスをアクティブ化するための完全な実装リファレンスを提供します。 オーディエンスセグメントを評価し、ターゲティング、抑制、類似モデリング、分析の強化のために、広告プラットフォーム、クラウドストレージ、CRM システム、データパートナーに公開する必要があるソリューションアーキテクト、マーケティングテクノロジスト、実装エンジニア向けに設計されています。

また、トレードオフ分析、意思決定ガイダンス、UI ナビゲーションパス、Experience Leagueドキュメントのリファレンスなど、実行可能なあらゆる実装オプションを提示します。

このガイドでは、オーディエンスのアクティベーションのライフサイクル全体をカバーしています。オーディエンスセグメントの定義と評価から、宛先接続の設定とオーディエンスの公開、アクティベーションの健全性の監視、ガバナンスコンプライアンスの適用に至るまで、あらゆるライフサイクルをカバーしています。

ユースケースの概要

企業は、有料メディアキャンペーンの実施、CRM レコードの拡充、パートナーとのデータ共有、下流プロセスでの分析の実行などを目的として、オーディエンスデータを外部システムに配信する必要があります。 Audience Activation to Destinationsは、RT-CDPの基本的なアクティベーションパターンです。ターゲットオーディエンスに適格なプロファイルを評価し、1つ以上の外部宛先に接続し、プロファイル属性を宛先固有のフィールドにマッピングし、ダウンストリームでの使用のためにオーディエンスを公開します。

このパターンは、オーディエンスデータを適切な形式の外部システムに的確なタイミングで取得することが目標である場合に適用されます。 メッセージの配信、オンサイトでのパーソナライゼーション、分析は含まれていません。 これは、RT-CDP実装の最も一般的な出発点であり、他のパターンがその上に構成するビルディングブロックとして機能します。

典型的な関係者には、有料メディアを管理するデジタルマーケティングチーム、データチームによるデータウェアハウスの強化、キャンペーンのコンタクトリストの準備、アウトバウンドデータフローのガバナンスコンプライアンスを確保するプライバシーチームなどがあります。

主なビジネス目標

このユースケースパターンでは、次のビジネス目標をサポートしています。

新規顧客の獲得

ターゲットを絞った獲得キャンペーン、類似オーディエンス、有料メディアの最適化により、顧客基盤を拡大できます。

KPI:​新規顧客、顧客獲得コスト、見込み顧客/リードコンバージョン

新規顧客の獲得についてさらに詳しく

顧客獲得コストの削減

ターゲティング効率を改善し、獲得キャンペーンから既存顧客を除外し、メディア支出を最適化します。

KPI:​顧客獲得コスト、リード単価、効率性

顧客獲得コストの削減について詳しく見る

マーケティングの支出とROIの最適化

ターゲティング、アトリビューション、オーディエンスの抑制、予算配分の改善を通じて、マーケティングのROIを向上できます。

KPI: コスト削減、顧客獲得コスト、増分収益

関連トピックス

戦術的なユースケース

主要業績評価指標

ユースケースパターン

Audience Activationから宛先 — ターゲティングまたは抑制のために、オーディエンスセグメントを評価して外部の宛先に公開します。

関数チェーン： オーディエンス評価/宛先設定/ Audience Activation > モニタリング

アプリケーション

基本関数

このユースケースパターンでは、次の基本機能を使用する必要があります。 各機能について、ステータスは、通常それが必要か、事前設定が想定されているか、適用できないかを示します。

サポート機能

次の機能は、このユースケースパターンを強化しますが、コア実行には必要ありません。

アプリケーション関数

この計画では、アプリケーション機能カタログから次の機能を実行します。 関数は、番号付きのステップではなく実装フェーズにマッピングされます。

Real-Time CDP （RT-CDP）

前提条件

実装オプション

このユースケースパターンでは、次の実装オプションを使用できます。 各オプションと比較表を確認して、要件に最適なアプローチを決定します。

オプション A: ストリーミング宛先のアクティベーション

広告プラットフォームまたはパートナーシステムに関するリアルタイムのオーディエンスメンバーシップの更新に最適： Facebook Custom Audiences、Google Ads Customer Match、LinkedIn Matched Audiences、The Trade Desk、および同様のストリーミング API ベースの宛先。

仕組み：

ストリーミング宛先のアクティベーションにより、プロファイルがセグメントに適格または不適格になるため、オーディエンスメンバーシップの変更がほぼリアルタイムで宛先に配信されます。 プロファイル属性が変更されたり、プロファイルがオーディエンスに入ったり離脱したりする行動イベントが発生したりすると、メンバーシップの更新は数分以内に宛先にストリーミングされます。

このアプローチには、ストリーミング宛先コネクタ（ほとんどの主要な広告プラットフォームがこれをサポートしています）と、ストリーミングまたはエッジオーディエンスの評価方法が必要です。 オーディエンス評価では、適格なプロファイルの変更を継続的に監視し、アクティベーションデータフローが発生すると更新をプッシュします。 宛先には、完全なオーディエンススナップショットではなく、メンバーシップの増分変更が反映されます。

ストリーミングアクティベーションは、RT-CDP カタログのほとんどの広告プラットフォーム宛先のデフォルトです。 宛先コネクタは、API認証、レート制限、再試行ロジックを自動的に処理します。

重要な考慮事項：

利点：

制限：

Experience League:

オプション B：バッチ宛先のアクティブ化（ファイルの書き出し）

最適： スケジュールされたオーディエンスのクラウドストレージ、データウェアハウス、またはファイルベースの読み込みを使用するシステム（Amazon S3、Azure Blob Storage、Google Cloud Storage、SFTP、データランディングゾーン）への書き出しに最適です。

仕組み：

バッチ宛先アクティベーションでは、スケジュールされた頻度でオーディエンスを評価し、結果をファイル（CSV、JSON、Parquet）として、設定されたストレージ宛先に書き出します。 書き出しには、完全なオーディエンススナップショットまたは増分変更（最後の書き出し以降の新しい条件と失格）を含めることができます。

この実装には、ストレージ資格情報、ファイル形式の環境設定（区切り文字、圧縮、命名規則）、書き出しスケジュール（毎日、3時間ごと、6時間ごと）を使用したファイルベースの宛先接続の設定が含まれます。 各エクスポート実行では、オーディエンスメンバーシップとマッピングされたプロファイル属性を含むファイルが生成されます。

ファイルベースのデータ交換が一般的にサポートされているため、このアプローチでは、さまざまなダウンストリームユーザーをサポートできます。 また、クラウドストレージとデータウェアハウスのエンリッチメントのユースケースに対応する唯一の選択肢でもあります。

重要な考慮事項：

利点：

制限：

Experience League:

オプション C：複数の宛先でのアクティベーション

最適な用途：​同じオーディエンスを複数の宛先に同時にアクティベートする（例：すべての広告プラットフォームに抑制リストをプッシュする、価値の高いセグメントをCRMと広告プラットフォームの両方に同期する、複数のメディアパートナーをまたいでオーディエンスリーチを調整する）。

仕組み：

複数宛先のアクティベーションは、個別の技術的メカニズムではなく、複数の宛先接続にわたって同じオーディエンスに適用されるオプション AとBの構成です。 同じオーディエンスが2つ以上の宛先に対してアクティブ化され、それぞれ独自の接続設定、フィールドマッピング、スケジューリングが行われます。

宛先接続は個別に動作します。FacebookへのストリーミングアクティベーションとS3へのバッチエクスポートは、同じソースオーディエンスから同時に実行できます。 フィールドマッピングは宛先ごとに設定されるため、各宛先が必要とするものやガバナンスポリシーで許可されているものに基づいて、異なる属性を異なるシステムに送信できます。

これは、複数の広告プラットフォームをまたいで運用したり、メディアのアクティベーションと並行してCRMの同期を維持したり、オーディエンスデータを運用システムと分析システムの両方に配信する必要がある組織にとって一般的な制作パターンです。

重要な考慮事項：

利点：

制限：

Experience League:

オプションの比較

適切なオプションの選択

以下の意思決定ロジックを使用して、適切な導入方法を選択します。

実装フェーズ

導入は、これらのフェーズに従います。 各段階では、設定の詳細、意思決定ポイント、Experience Leagueドキュメントへのリンクが含まれます。

フェーズ 1：オーディエンスの評価

アプリケーション関数： RT-CDP: Audience Evaluation、RT-CDP: Audience Composition

設定する内容：​宛先に対してアクティブ化するターゲットオーディエンスを定義します。 これには、オーディエンス基準（どのプロファイルが適格であるかが含まれます）、評価方法の選択（メンバーシップの更新の速度）、オーディエンス母集団の検証が含まれます。 これが、あらゆるアクティベーションの出発点となります。オーディエンスを定義し、評価しなければ、アクティベーションは一切不要です。

このフェーズの​決定ポイント：

UI ナビゲーション：​顧客/オーディエンス/オーディエンスを作成/ルールを作成（セグメントビルダー用）またはオーディエンスを作成（オーディエンス構成用）

キー設定の詳細：

オプションが異なる場所：

オプション A （ストリーミング宛先のアクティブ化）の場合：
オーディエンスは、リアルタイムのメンバーシップ更新を配信するために、ストリーミングまたはエッジ評価を使用する必要があります。 セグメントルール式がストリーミング評価に適格であることを確認します。時間ベースの集計関数、マルチエンティティクエリー、およびバッチのみのセグメントへのinSegment()参照を回避します。

オプション B （バッチ宛先のアクティブ化）の場合：
どんな評価方法でも機能します。 バッチ評価は、書き出し自体がスケジュール上で実行されるため、最も一般的な選択肢です。 バッチ評価スケジュールがサンドボックスに存在することを確認するか、作成します。

オプション C （複数宛先のアクティベーション）の場合：
評価方法は、最も要求の厳しい目的地に対応する必要があります。 任意の宛先でストリーミングが必要な場合、オーディエンスはストリーミング評価を使用する必要があります。 すべての宛先がバッチである場合は、バッチ評価で十分です。

Experience League ドキュメント：

フェーズ 2：宛先設定

アプリケーション関数： RT-CDP：宛先設定

設定する内容： オーディエンスが公開される外部宛先への認証済み接続を確立します。 これには、カタログから宛先を選択したり、認証資格情報を提供したり、ファイル形式、保存場所、書き出しスケジュールなどの宛先固有のパラメーターを設定したりすることが含まれます。 各宛先には、独自の接続設定が必要です。

このフェーズの​決定ポイント：

UI ナビゲーション：​接続>宛先> カタログ > [宛先を選択] >設定

キー設定の詳細：

オプションが異なる場所：

オプション A （ストリーミング宛先のアクティブ化）の場合：
カタログ（Advertisingまたはソーシャルカテゴリ）からストリーミング先を選択します。 OAuth認証フローを完了します。 認証が確認されると、接続はアクティベーションの準備が整います。

オプション B （バッチ宛先のアクティブ化）の場合：
カタログ（クラウドストレージカテゴリ）からファイルベースの宛先を選択します。 ストレージパス、ファイル形式、圧縮、命名規則、書き出しスケジュールを設定します。 ストレージの場所への書き込みアクセスを検証して、接続をテストします。

オプション C （複数宛先のアクティベーション）の場合：
各宛先に対してこのフェーズを繰り返します。 各接続は独立しています。ストリーミングとバッチの宛先が混在している可能性があります。 運用上の参照のために、各接続の認証と設定を文書化します。

Experience League ドキュメント：

フェーズ 3：オーディエンスのアクティベーション

アプリケーション関数： RT-CDP: Audience Activation

設定する内容： アクティベーション データフローを作成して、評価されたオーディエンスを設定された宛先に公開します。 これには、アクティベートするオーディエンスの選択、プロファイル属性と宛先フィールドのマッピング、書き出しスケジュールの設定が含まれます。 アクティベーションデータフローは、ソースオーディエンスをターゲット宛先に接続し、継続的なデータ配信を管理します。

このフェーズの​決定ポイント：

UI ナビゲーション：​接続>宛先>参照> [宛先を選択] > オーディエンスをアクティブ化

キー設定の詳細：

オプションが異なる場所：

オプション A （ストリーミング宛先のアクティブ化）の場合：
オーディエンスを選択し、ID名前空間を宛先ID フィールドにマッピングします。 アクティベーションは、公開時にすぐに開始されます。オーディエンスメンバーシップは、ストリームをほぼリアルタイムで宛先に変更します。 書き出しスケジュールは必要ありません。アクティベーションは継続的に行われます。

オプション B （バッチ宛先のアクティブ化）の場合：
オーディエンスを選択し、プロファイル属性をマッピングして、書き出しスケジュールを設定します。 増分書き出しモードとフル書き出しモードのどちらかを選択します。 必要に応じて、アドホック書き出しをトリガーして、通常のスケジュール外ですばやく配信します。

オプション C （複数宛先のアクティベーション）の場合：
各宛先に対してアクティベーションワークフローを繰り返します。 同じオーディエンスを、宛先ごとに異なる属性マッピングを持つ複数の宛先に対してアクティブ化できます。 例えば、広告プラットフォームにはハッシュ化された電子メールのみを送信し、CRMにはデモグラフィック属性を含めます。

Experience League ドキュメント：

フェーズ 4：ガバナンスの検証

アプリケーション関数： RT-CDP：同意とガバナンスの適用

設定するもの： ガバナンス ポリシーと同意設定がアクティベーションの前およびアクティベーション中に正しく適用されていることを検証します。 このフェーズでは、制限されたデータ（PII、機密性の高い属性）が不正な宛先に送信されないようにし、有効な同意のないプロファイルがアクティベーションから除外されます。 ガバナンスの適用はアクティベーション時に自動的に行われますが、プロアクティブな検証により、ブロックされたアクティベーションやコンプライアンス違反を防ぐことができます。

このフェーズの​決定ポイント：

UI ナビゲーション： プライバシー/ポリシー/同意ポリシー（同意レビュー用）、データガバナンス/ポリシー（データ使用ポリシーのレビュー用）

キー設定の詳細：

Experience League ドキュメント：

フェーズ 5：監視と検証

アプリケーション関数：​監視と観測可能性

設定する内容： アクティベーションデータフローの継続的な監視の設定、失敗に対するアラートの設定、宛先でのオーディエンス母集団の検証、ライセンス使用状況の追跡を行います。 配信の失敗がキャンペーンのパフォーマンスとメディア費用に直接影響を与える本番環境のアクティベーションには、監視が不可欠です。

キー設定の詳細：

UI ナビゲーション：​接続>宛先>参照> [宛先を選択] > データフロー実行（アクティベーション監視の場合）、アラート/アラートルール/購読（アラート設定の場合）、管理/ライセンス使用状況（ライセンス追跡の場合）

Experience League ドキュメント：

実装に関する考慮事項

導入前と導入中に、次の考慮事項を確認します。

ガードレールと制限

よくある落とし穴

ベストプラクティス

トレードオフの決定

関連ドキュメント

宛先

オーディエンスとセグメント化

IDとプロファイル

データモデリングとスキーマ

データガバナンス

監視と監視

計算属性

データの収集とソース

管理

ガードレール