データ収集における同意とID
Web SDKの導入では、同意とIDは密接に関連しています。 同意を収集する方法とタイミングは、Web SDKがECIDを生成し、ID Cookieを設定し、データをEdge Networkに送信するタイミングとタイミングに直接影響します。 同意を慎重に処理しないと、訪問者の予期しないインフレーション、IDの連続性のギャップ、またはその両方が発生することがよくあります。
このページでは、同意の選択がIDの行動とどのように関わるのかを説明し、一般的な落とし穴を回避するために実装を設定するためのガイダンスを提供します。 Web SDKがECID、FPID、およびその他のID シグナルを処理する方法の背景については、「 データ収集のID」を参照してください。
同意がIDに与える影響 how-consent-affects-identity
Web SDKでは、defaultConsent構成変数とsetConsent コマンドの両方を使用して、データをEdge Networkに送信するかどうかを制御します。 同意ステータスは、ECIDが生成されるタイミングとID Cookieが設定されるタイミングを直接決定します。
次の表は、データ収集、Cookie設定、およびID動作に対するdefaultConsentとsetConsentの複合効果を示しています。
defaultConsentsetConsentininininoutkndctr_ ID Cookieは、有効期限が切れるまでブラウザーに残ります。pendingsetConsentが呼び出されるまでローカルでキューに入れられます。pendinginpendingoutoutoutinoutout以前に同意を取り消した後に訪問者が同意を再付与した場合（setConsentの後"general": "in"で"general": "out"を呼び出すことにより）、Web SDKはイベントの送信を再開し、有効期限が切れていない場合はCookieから既存のECIDを使用します。 訪問者のIDは保持されます。
訪問者が同意を付与または拒否した後、Web SDKはkndctr_個の同意Cookieに自身の環境設定を保持します。 後続のページ読み込みでは、SDKはこのCookieを読み取り、保存された環境設定を自動的に適用します。訪問者の環境設定が変更されない限り、setConsentを再度呼び出す必要はありません。 defaultConsent設定値はページ読み込み間に保持されませんが、訪問者の解決済み同意（setConsentで設定）は保持されます。
pendingである間にキューに入れられたイベントはメモリに保持され、ページの再読み込みに耐えられません。 同意が解決される前に訪問者が新しいページに移動すると、前のページからのキューに入れられたイベントは失われます。実装パターン implementation-patterns
オプトインモデル（収集前に同意が必要） opt-in
このパターンは、規制（GDPRなど）がデータを収集する前に明示的な同意を必要とする場合に使用します。
alloy("configure", {
orgId: "YOUR_ORG_ID@AdobeOrg",
edgeDomain: "data.example.com",
defaultConsent: "pending"
});
// When the visitor grants consent:
alloy("setConsent", {
consent: [{
standard: "Adobe",
version: "1.0",
value: { general: "in" }
}]
});
このパターンで：
- 同意が付与されるまで、ECIDは生成されません。
- 同意前にトリガーされたイベント（最初のページビューなど）は、同意が付与された後にキューに入れられ、送信されます。
- ID Cookieは、最初のEdge Network リクエストが成功した後にのみ設定されます。
オプトアウトモデル（デフォルトで収集、拒否で停止） opt-out
このパターンは、規制でデータ収集がデフォルトで許可され、オプトアウトのオプションがある場合に使用します。
alloy("configure", {
orgId: "YOUR_ORG_ID@AdobeOrg",
edgeDomain: "data.example.com",
defaultConsent: "in"
});
// If the visitor opts out:
alloy("setConsent", {
consent: [{
standard: "Adobe",
version: "1.0",
value: { general: "out" }
}]
});
このパターンで：
- ECIDは、最初のページ読み込み時に即座に生成されます。
- 訪問者がオプトアウトするまで、すべてのイベントが送信されます。
- オプトアウト後、Web SDKはイベントの送信を停止しますが、既存のCookieは残ります。
ファーストパーティデバイス IDを使用した同意 consent-with-fpids
実装で ファーストパーティデバイス ID （FPID） を使用する場合、FPID Cookieは、Web SDKの同意状態とは関係なく、サーバーによって設定されます。 FPID Cookieは、独自のインフラストラクチャで管理する識別子です。 ただし、FPIDは、Web SDKがリクエスト（同意によってゲーテッド）を行った場合にのみEdge Networkに送信されます。
defaultConsent: "pending"では、FPIDはブラウザーに存在しますが、同意が付与されるまでECIDのシード処理には使用されません。defaultConsent: "in"を使用すると、FPIDは最初のリクエストで使用され、ECIDをすぐにシードします。
同意の実装で、同意の前に識別子を設定する必要がない場合は、同意が伝わるまでFPID Cookieの設定を遅らせてください。 Web SDKの同意ゲートだけでは、FPID Cookieはサーバーによって管理されるため、設定されるのを防ぐことはできません。
よくある落とし穴 common-pitfalls
問題：一部の同意管理プラットフォーム（CMP）は、訪問者が選択を行う前に、同意バナーを表示する際に、kndctr_個のID Cookieを含むすべてのCookieをクリアします。 訪問者が同意を付与すると、以前のECIDが削除されたため、Web SDKは新しいECIDを生成します。 訪問者がレポートに新しい人物として表示されます。
症状:
- 同意バナーをデプロイすると、ユニーク訪問者数が急増。
- 再訪問者は、同意が失効するたびに新規訪問者としてカウントされ、バナーを再度操作します。
解決策: kndctr_ Cookieを保持するようにCMPを設定します。 これらのCookieはID Cookieであり、トラッキング Cookieではありません。デバイスを識別するもので、行動データは含まれていません。 CMPでCookieを消去する必要がある場合は、除外リストにkndctr_個の接頭辞Cookieを追加します。 または、訪問者が同意を明確に拒否するまで、Cookieの消去を先回りして消去するのではなく、遅らせることもできます。
問題: defaultConsentがpendingに設定されている場合、Web SDKは同意を待ってからデータを送信します。 ページのライフサイクルの後半で同意が付与された場合（例えば、ページのリロードをトリガーするバナーインタラクションの後など）、次の順序で問題が発生する可能性があります。
- ページの読み込み：
defaultConsent: "pending"。Web SDKはリクエストを送信しません。 - 訪問者が同意を付与します。 CMPは、ページのリロードをトリガーします。
- ページが再度読み込まれます。 Web SDKは、現在の同意を得て初期化され、ECIDを生成します。
このフローは正常で、正しく機能します。 この問題は、CMPまたは実装が手順2と3の間で誤ってCookieをクリアする場合、またはリロード時にWeb SDKの設定が異なる場合に発生します。
解決策: Web SDKの設定（特にorgIdとdefaultConsent）が、ページ読み込みのたびに同じであることを確認します。 CMPが同意後にリロードをトリガーする場合は、ID Cookieがリロード後も有効であることを確認します。
defaultConsent: "in"を使用問題：一部の実装はdefaultConsent: "in"を設定し、訪問者が辞退した場合はsetConsentで"general": "out"を呼び出します。 このアプローチでは、ECIDを生成し、同意が拒否される前に少なくとも1つのリクエストを送信します。 規制要件によっては、この最初のデータ収集が組織のプライバシーポリシーに一致しない場合があります。
解決策：データの収集またはECIDの生成の前に規制環境で同意が必要な場合は、代わりにdefaultConsent: "pending"を使用してください。 この設定により、同意が明示的に付与されるまで、Web SDKがEdge Networkと通信しないようにします。