SFMCトラッキングサーフェス

同意の観点では、SFMCを単一の製品としてではなく、それぞれ独自の統合パターンを持つ4つの重なり合うトラッキングサーフェスとして扱うことが有益です。

Web Analytics Connector と Collect トラッキングコード

Collect トラッキングコード（しばしば collect.js と呼ばれ、または cdn.evgnet.com を通じて参照される）は、SFMCの行動トラッカーです。_etmc および関連するクッキーを設定し、セッションをまたいで訪問者を識別し、Journey Builder トリガーとメールリターゲティングに使用するためのページビュー、クリック、コンバージョンイベントをSFMCに転送します。規制の観点から見ると、これは明らかにマーケティングトラッカーです — イベントがアナリティクスのように見えても、データはダイレクトマーケティングオートメーションを支えています。

Marketing Cloud Personalization スクリプト

Personalization スクリプト（レガシー Interaction Studio）は Collect より重いです。DOM全体を監視するSDKをロードし、クリックストリームとフォームインタラクションデータをキャプチャして、リアルタイムでページコンテンツを書き換えることができるパーソナライゼーション決定エンジンに転送します。設定されるクッキーには _ev_* 識別子とセッショントークンが含まれます。これは明確にマーケティング目的の処理であり、EUまたはUKのいずれの管轄でもオプトイン同意が必要です。

CloudPages フォームとトラッキングリンク

CloudPages がホストするランディングページと、SFMCを経由するトラッキングメールリンクは、独自の識別パラメーター（URLの subscriberkey、jb、mid パラメーター）を持ちます。訪問者がトラッキングリンク経由で到着すると、SFMCはページ内トラッキングが起動する前でも、セッションをその購読者レコードと関連付けることができます。これは匿名トラッキングとは法的に意味のある違いがあります — 購読者の身元は最初の接触時に既知です — そしてマーケティングコミュニケーションへの同意が既に存在している必要があります。

Data Cloud コネクター

SFMCのData Cloud統合（顧客データプラットフォーム層）は、ウェブトラッキング、モバイルSDK、CRMレコード、およびオフラインデータから識別子を統合プロファイルに取り込みます。同意状態は、サーフェスレベルのトラッキングピクセルだけでなく、Data Cloudにも伝播する必要があります。そうすることで、広告ネットワークへのダウンストリームアクティベーションが訪問者の記録された設定を尊重します。

ネイティブSFMCプライバシーコントロール

SFMCはいくつかのネイティブコントロールを公開していますが、ほとんどのエンタープライズマーケティングプラットフォームと同様に、同意決定がアップストリームで収集され、渡されることを前提としています。ネイティブコントロール自体は同意を収集しません。

Web Analytics Connector のトラッキングオプトアウト

Collect スクリプトは do_not_track フラグと設定可能なオプトアウト関数を読み取ります。これらを設定するとCollectがデータを送信するのを防ぎますが、スクリプト自体のロードは防ぎません。事前同意が必要な管轄では、フラグを切り替えるだけでなく、スクリプトのロードをゲートする必要があります。

購読者レコードの同意設定

SFMCの購読者プロファイルには、コミュニケーション同意、プロファイルデータ同意、および適法根拠のフィールドがあります。これらは、既知の連絡先がマーケティングされる法的根拠を追跡するための適切なプリミティブであり、訪問者が受け入れまたは撤回したときにCMPがこれらのフィールドに書き戻す必要があります。

Marketing Cloud Personalization の同意

Personalization SDKは初期化時に同意フラグを受け入れます。訪問者がCMPバナーでマーケティングカテゴリを受け入れるまで false に設定し、同意が付与されたときにSDKを再初期化します。

ステップバイステップのCMP統合

信頼性の高いアーキテクチャは、すべての4つのトラッキングサーフェスをCMPの背後にゲートし、同意が付与されたらSFMCのネイティブフラグを使用してダウンストリームの動作を調整することです。

1. Collect スクリプトのデフォルトロードを停止する

Collect スクリプトをドキュメントヘッドから削除し、CMPがアクティベートできるプレースホルダーに置き換えます。訪問者がマーケティングカテゴリを受け入れると、CMPはプレースホルダーを書き換えて collect.js をロードします。キューに入ったイベントはロード時にフラッシュされます。

2. Marketing Cloud Personalization の初期化を延期する

Personalization スクリプトは同意前に初期化してはなりません。ほとんどのCMPは遅延ロードパターンでこれを処理します：スクリプト要素はDOMに存在しますが、その type 属性は text/plain であり、同意受け入れ時にCMPが text/javascript に書き換えます。

3. CloudPages トラッキングパラメーターをゲートする

訪問者がトラッキングリンク経由で到着し、まだ同意していない場合、受信した subscriberkey パラメーターはキャプチャすべきですが、即時パーソナライゼーションを促進するために使用すべきではありません。正しいパターンは、セッション状態に保存し、同意が記録されたとき（プロファイルデータとの相関、Journey Builder イベントのトリガー）にのみアクティベートすることです。

4. 同意状態を Data Cloud に伝播する

Data Cloud 統合は、ダウンストリームアクティベーションがそれを尊重するように各訪問者の同意状態を知る必要があります。SFMCはCMPがAPIを通じてData Cloudに同意レコードを書き込むことができる同意拡張をサポートしています。CMPの同意決定がオンページスクリプトだけでなく、SFMC層全体の真実のソースになるようにこれを設定します。

5. SFMC 購読者同意フィールドへのマッピング

既知の購読者がCloudPagesプリファレンスセンターで同意を更新する場合、CMPとSFMCの購読者レコードは同期を保つ必要があります。CMPからSFMC購読者の同意フィールドへのライトバックを設定し、オンページバナーが購読者がメール設定で設定したことを尊重するようにリードバックを設定します。

よくある落とし穴

3つの統合ミスがSFMCに関するほとんどのエンタープライズ監査結果の原因となっています。

Collect をアナリティクスとして扱う

Collect スクリプトはアナリティクスのように見えるページビューとクリックイベントを報告するため、チームはそれをアナリティクス同意カテゴリの下にゲートすることがあります。SFMCはそのデータを Journey Builder マーケティングオートメーションを駆動するために使用しており、これは明確にマーケティング目的の処理です。Collect をマーケティングの下にゲートしてください。

Personalization を同意前に実行させる

Personalization はSFMCトラッキングサーフェスの中で最も重く、ページを積極的に変更するため、規制当局に最も見えます。同意前に初期化させることは、監査の観点からSFMCスタックで最も露出するパターンです。

スタック全体で同意を同期しない

オンページバナーが同意決定を記録しても、Data Cloud プロファイルが古い状態を保持している場合、広告ネットワークへのダウンストリームアクティベーションは古い同意に基づいて起動し続けます。CMPが真実のソースを所有し、SFMCスタックが到達できる場所すべてにそれを伝播する必要があります。

監査チェックリスト

EU、UK、またはカリフォルニアのトラフィックに触れるSFMC導入に対して答えるべき5つの具体的な質問。

• Collect は同意を待っていますか？バナー受け入れ前に collect.js または evgnet.com リクエストが起動しないことを確認してください。
• Personalization は延期されていますか？マーケティングカテゴリが付与されるまで Personalization SDK が初期化されないことを確認してください。
• 受信したトラッキングリンクパラメーターは同意まで保持されていますか？subscriberkey 駆動のパーソナライゼーションが明示的な同意シグナルを待つことを確認してください。
• Data Cloud は同意状態を確認していますか？同意拡張が設定されており、CMPがリアルタイムでData Cloudに決定を書き込むことを確認してください。
• 購読者の同意フィールドは同期されていますか？プリファレンスセンターの変更がオンページバナーに伝播し、その逆も同様であることを確認してください。

同意ファーストスタックにおけるSFMCの位置づけ

SFMCは最も強力なマーケティングプラットフォームの1つであり、同時に最も露出するプラットフォームの1つでもあります。デフォルトの導入パターンは現在の欧州またはカリフォルニアの期待を単純には満たせず、プラットフォームのネイティブコントロールは有用なプリミティブですが、アップストリームの同意管理層の代替にはなりません。正しいアーキテクチャは、CMPを唯一の真実のソースとして扱い、すべてのトラッキングモジュールをその背後にゲートし、SFMCの同意拡張を使用してData Cloudと購読者レコードがスタックの残りの部分全体にその真実を伝播させます。正しく行われれば、SFMCはマーケターが購入した機能 — Journey Builder トリガー、Personalization 決定、Data Cloud アクティベーション — を引き続き実行し、一方で基礎となるコンプライアンス体制はあらゆるエンタープライズマーケターに規制当局が今求めるものと一致します。