Show Menu
トピック×

ID 拡張

送信する ID では、Analytics でデータ主体に関連付けることができるヒットデータの一部をカバーできない場合もあります。Analytics では、ID のセットを拡張し、関連付けられているデータをデータプライバシー要求に含めることができます。このオプションを要求するには、送信する各データプライバシー要求に対するオプションのパラメーターを JSON 要求に追加します。
"expandIds": true

このオプションを要求に含める方法の例については、 サンプルの JSON 要求 を参照してください。詳しくは、 プライバシーサービス API のドキュメント を参照してください。
タイプ 注意点
Cookie ID の拡張
Analytics をご利用の多くのお客様は、以前までは(従来の) Analytics Cookie を使用していましたが、現在は ID サービス(ECID) (旧称 Marketing Cloud ID サービス(MCID))を使用しています。移行後に、こうしたお客様の Web サイトを初めて訪問したユーザーの場合は、ECID のみが使用されます。ただし、従来の Cookie しか利用できなかった時期に Web サイトを初めて訪問し、それ以降も訪問し続けているユーザーの場合は、一部のデータで両方の Cookie が使用され、古いデータでは Analytics Cookie のみ、最新のデータでは稀に ECID のみが使用される場合もあります。
Analytics(訪問者 ID)Cookie または ECID で識別された 1 人の訪問者に関するすべてのデータが確実に検出される必要があります。このため、現在は ECID を使用し、以前は Analytics Cookie を使用していた場合、いずれかのタイプの ID を使用して要求を送信する場合はいつでも、要求に両方の ID を含めるか、expandIDs オプションを指定する必要があります。expandIDs を指定すると、指定した任意の Cookie ID に対応する他の ECID または Analytics Cookie がないかどうかチェックされます。新しく特定されたこれらの Cookie ID を含めるように要求が自動的に拡張されます。
カスタム ID から 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 が検出されたヒットのデータのみ含まれています。
データプライバシーの施行後最初の数ヶ月の間、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」という値もサポートされています。この値は、データ主体による要求の結果として発生した要求ではないために 30 日以内に完了しなければならないという法的義務が課せられていない要求に対して指定する必要があります。アドビでは、データ主体からの要求以外の目的でプライバシーサービス API を使用すること推奨していません。プライバシーサービス API はデータの消去や修正を目的としたツールではなく、そのような目的にこの API を使用すると意図しない結果が生じます。
プライバシーサービス API は、時間的制約が厳しいデータプライバシー要求を着実に実行できるようにすることを目的として提供されています。この API をその他の目的に使用することはサポートされておらず、そのような利用はユーザーからの優先度の高いデータプライバシー要求をアドビの他のお客様のためにタイムリーに処理する能力に影響を及ぼす可能性があります。大規模な訪問者グループ全体にわたって間違って送信されたデータを消去するなど、本来の目的とは異なる用途にプライバシーサービス API を使用することは避けください。
また、データプライバシー削除要求の結果、ヒットが削除(更新または匿名化)された訪問者の状態情報はリセットされるということを認識しておく必要があります。そのような訪問者が再び Web サイトを訪問した場合は、新規訪問者として扱われます。eVar の割り当ては最初からすべてやり直され、訪問回数、リファラー、最初に訪問したページなどの情報も最初から収集し直されます。データフィールドを消去すると、このような望ましくない副次的効果が生じます。これは、プライバシーサービス API がそのような用途に適していない理由の 1 つでもあります。
PII やデータに関連する問題が発生した場合は、アカウントマネージャー(CSM)に連絡し、エンジニアリングアーキテクトコンサルティングチームと協力して問題解決に必要な労力のレベルを確認したうえで、問題を解決するよう依頼してください。