ID 拡張
送信する ID は、Analytics でデータ主体に関連付けることができるすべてのヒットデータを常にカバーしているわけではありません。Analytics では、ID のセットを拡張し、関連付けられているデータをデータプライバシー要求に含めることができます。このオプションを要求するには、送信する各データプライバシー要求に対するオプションのパラメーターを JSON 要求に追加します。
"expandIds": true
詳しくは、プライバシーサービス API のドキュメントを参照してください。
Analytics をご利用の多くのお客様は、以前までは（従来の）Analytics Cookie を使用していましたが、現在は Experience Cloud ID サービス（ECID）を使用しています。移行後に、こうしたお客様の web サイトを初めて訪問したユーザーの場合は、ECID のみが使用されます。ただし、従来の Cookie のみが使用可能だったときに最初に訪問し、その後訪問した場合、一部のデータには両方の Cookie が含まれています。ただし、古いデータには Analytics Cookie のみが含まれており、最新データに ECID のみが含まれている場合も稀にあります。
Analytics（訪問者 ID）Cookie または ECID で識別された 1 人の訪問者に関するすべてのデータが確実に検索されます。現在は ECID を使用し、以前は Analytics Cookie を使用していた場合、いずれかのタイプの ID を使用してリクエストを送信する場合はいつでも、リクエストに両方の ID を含めるか、expandIds オプションを指定する必要があります。expandIds を指定すると、指定した任意の Cookie ID に対応する他の ECID または Analytics Cookie がないかどうかチェックされます。これらの新しく識別された Cookie ID を含めるようにリクエストが自動的に拡張されます。
e コマース Web サイトでは、訪問者がログインせずにサイトを閲覧して商品を買い物かごに追加し、チェックアウトプロセスに入ることも珍しくありません。データプライバシーリクエストのユーザーを識別するために使用される ID が、ユーザーがログインしているときにのみカスタム変数に保存される場合、このログイン前のアクティビティは ID に関連付けられません。Analytics Cookie ID を使用すると、Cookie ID がログインをまたいでも保持されるので、ログイン前の閲覧行動をログイン後の購入操作に関連付けることができます。
実装でログイン ID（CRM ID、ユーザー名、ロイヤルティ番号、電子メールアドレスなど、またはこれらの値のハッシュ）がカスタム変数（prop や eVar）またはカスタム訪問者 ID に保存され、この ID をデータプライバシーアクセス要求に使用しているとします。データ主体は、すべてのブラウジングに関する情報がアクセスリクエストの一部として返されないことを意外に思うかもしれません。特に、表示されたが購入には至っていないアイテムを宣伝した場合はなおさらです。そのため Analytics によるデータプライバシーの処理では、ID 拡張に対応しており、任意のカスタム ID と同じヒット内のすべての Cookie ID を検出してから、要求を拡張してそれらの ID も含めます。
Cookie の名前空間以外の任意の名前空間と共に expandIDs を指定すると、指定した ID のいずれかを含んでいるヒットから検出された任意の Cookie ID（ECID または Analytics Cookie）を含めるようにリクエストが拡張されます。上記のように、Cookie ID の拡張は、新しく検出された任意の Cookie ID に対して実行されます。
アクセスリクエストに expandIDs オプションが使用され、指定した ID に ID-PERSON のラベルが付いている場合、2 つのファイルセットが返されます。最初のファイルセット（ユーザーセット）には、指定した ID が検出されたヒットのデータのみ含まれています。2 番目のファイルセット（デバイスセット）には、指定した ID は存在していなかったが拡張 ID が検出されたヒットのデータのみ含まれています。
ID 拡張を使用するタイミング
データプライバシーが公開されてから最初の数か月間、Analytics データプライバシーリクエストの大部分は ID 拡張をリクエストしませんでした。ただし、組織にとって適切な値を決定するのは、お客様次第です。使用する ID を含むデータおよび Adobe Analytics 内で収集するデータに対して ID 拡張が必要かどうかを法務チームに問い合わせる必要があります。
第一に考慮すべきことは、複数のユーザーがサイトに訪問した共有デバイス上で ID 拡張を使用すると、アクセスリクエストで返される（デバイスファイル内の）データに、他のユーザーのデバイスヒットからのデータが含まれます。ラベル付けのベストプラクティスに従っている場合でも（例えば、訪問したページなどのプライベートデータがデバイスファイルに含まれていない場合）、デバイスファイルには、訪問したページの数と各訪問の時間が含まれます。次のように自問してみてください：この情報を、訪問者ではない可能性のある人と共有してもよろしいですか？
ID 拡張が削除リクエストに使用されて いない 場合：Cookie 以外の ID（ECID または Analytics Cookie 以外の任意の ID）を使用して、削除する必要があるヒットを識別し、その ID に ID-DEVICE ラベルを追加すると、レポートの個別訪問者数が変化します。これは、Cookie ID の一部のインスタンスのみが匿名化され、その他のインスタンスは変更されないからです。ID 拡張を指定していない場合、リクエストに Cookie ID を使用するか、ID-PERSON ラベル付きの ID を使用することをお勧めします。
アドビが ID 拡張を実行する場合、追加のフルデータスキャンが必要になる場合があります。これにより、アドビがリクエストを完了するまでにかかる時間が長くなり、多くの場合、処理時間が 1 週間長くなります。
その他のデータプライバシー要求フラグ
Analytics では、「expandIDs」フラグに加え、データプライバシー要求の一部として渡すことができるフラグが 2 種類サポートされています。これらのフラグとそのデフォルト値は次のとおりです。
"analyticsDeleteMethod": "anonymize"
"priority": "normal"
今後、analyticsDeleteMethod では、デフォルト値の「anonymize」に加え、「purge」の値をサポートする可能性があります。この値をサポートする場合、DEL ラベル付きのヒットフィールドの値を単に更新するのではなく、ヒット全体を削除するようになります。
デフォルト値に加え、priority フィールドでは、「low」の値もサポートします。この値は、データ主体によるリクエストの結果ではなく、特定の期間内に完了する必要がある法的義務が課せられていないリクエストに対して指定する必要があります。
Privacy Service API の使用
また、データプライバシー削除要求の結果、ヒットが削除（更新または匿名化）された訪問者の状態情報はリセットされるということを認識しておく必要があります。そのような訪問者が再び Web サイトを訪問した場合は、新規訪問者として扱われます。eVar の割り当ては最初からすべてやり直され、訪問回数、リファラー、最初に訪問したページなどの情報も最初から収集し直されます。この結果は、データフィールドを消去する状況では望ましくなく、Privacy Service API がこの用途に適していない理由の 1 つが強調されています。
Adobeアカウントチームに連絡し、エンジニアリングアーキテクトコンサルティングチームと協力して、さらに検討し、PII の削除やデータに関する問題の解決にどの程度の労力が必要かをお知らせください。