ラベル設定に関するベストプラクティス
ラベル設定は、新しいレポートスイートが作成されるたびに、または既存のレポートスイート内で新しい変数を有効にする際に、確認する必要があります。 また、新しいソリューション統合が有効になっている場合は、ラベル付けが必要な可能性のある新しい変数が表示される可能性があるため、ラベル付けを確認する必要がある場合もあります。 モバイルアプリやweb サイトを再実装すると、既存の変数の使用方法が変更される可能性があります。そのため、ラベルを更新する必要がある場合もあります。
I1、I2、S1 および S2 ラベルは、Adobe Experience Platform の対応する名前の DULE ラベルと同じ意味を持ちます。 ただし、使用目的は非常に異なります。 Adobe Analytics 内では、これらのラベルを使用すると、Privacy Service のリクエストの結果として匿名化する必要があるフィールドを識別するのに役立ちます。 Adobe Experience Platform 内では、アクセス制御、同意管理、ラベル付けされたフィールドに対するマーケティング制限の適用に使用されます。 Adobe Experience Platform では、Adobe Analytics で使用されない多くの追加ラベルをサポートしています。 Analytics データコネクタを利用して Adobe Analytics データを Adobe Experience Platform に読み込む場合は、Adobe Analytics 内で適用した I1、I2、S1 および S2 ラベルが、読み込んだレポートスイートで使用される Adobe Experience Platform のスキーマにも適用されていることを確認する必要があります。
個人を直接的に特定できる ID と間接的に特定できる ID direct-vs-indirect
どの変数やフィールドにどのラベルを適用するかを把握するためには、まず Analytics データから取得する ID について理解し、データプライバシー要求でどの ID を使用するかを決める必要があります。 データプライバシーによって、何を ID とするかの範囲が広がります。 IDは、直接識別可能（ID ラベル：I1）と間接識別可能（ID ラベル：I2）の2つの大まかなクラスに分類されます。
- 直接識別可能なID （I1）：人物に名前を付けるか、直接連絡方法を提供します。 例えば、誰かの名前（John Smithのような一般的な名前で、何百人もの人が共有しているものもあります）、メールアドレス、電話番号などがあります。名前のないメールアドレスは、その世帯や事業内の特定の人物ではなく、世帯や事業のみを識別できる場合でも、直接識別可能と見なされる可能性があります。
- 間接的に識別可能なID （I2）：個人を単独で識別することはできませんが、他の情報と組み合わせて誰かを識別することができます（自分が所有している場合とそうでない場合があります）。 例えば、個人を間接的に特定できる ID は、顧客のロイヤルティ番号や、企業の CRM システムで使用される顧客ごとの一意の ID などが該当します。 Analytics で使用されるトラッキング Cookie に保管される匿名 ID は、データプライバシーでは個人を間接的に特定できる ID と見なされる可能性があります。特定できるのが個人ではなく、デバイスのみの場合でもそれは同様です（共有デバイス上では、これらの Cookie でシステム内の複数のユーザーを識別することはできません）。 例えば、Cookie を使用して、その Cookie を持つコンピューターを検索することはできませんが、ユーザーがコンピューターにアクセスして Cookie を見つけた場合は、Analytics の Cookie データをそのコンピューターに関連付けることができます。
IP アドレスも個人を間接的に特定できる ID と見なされます。これは、特定の時点で単一デバイスのみに割り当てられる場合があるからです。 ただし、ISPは、ほとんどのユーザーのIP アドレスを定期的に変更できるため、時間の経過とともにIP アドレスがユーザーのいずれかで使用されている可能性があります。 また、ISPの顧客や、同じイントラネット上にある企業の複数の従業員が、同じ外部IP アドレスを共有することも珍しくありません。 このため、アドビではデータプライバシーリクエストの ID として IP アドレスを使用することをサポートしていません。 ただし、アドビが許可している ID が削除要求で使用されていた場合は、アドビはその ID に伴って発生した IP アドレスも削除します。 I1 または I2 のこのカテゴリに分類される可能性のある収集された ID が他に存在するかどうかを判断する必要がありますが、データプライバシーリクエストの識別 ID としての使用には適していません。
Analytics データ内の様々な ID を収集している場合でも、データプライバシー要求では ID のサブセットのみを使用するよう設定します。 その理由には、次のようなものがあります。
- 独自のシステム内で、1つのID （電子メールアドレスなど）を別のID （CRM IDなど）にマッピングできます。 その場合は、一貫性を保つために、データプライバシーの処理時にはデータプライバシー要求で CRM ID のみを使用するようにします。
- IDに関連付けられている人物が実際に存在することを検証する方法はありません。 例えば、IP アドレスが1人のユーザーのみが使用したことがあり、リクエストを送信したユーザーが実際にそのユーザーであることを検証するのは非常に困難な場合があります。
- 一部の ID は複数の人物に対応していることがあり、ある人物に関する情報を、同一の ID を持つ別の人物に返すことは避ける必要があります。 例えば、誰かの名前がJohn Smithであることを確認できたとしても、システム内のすべてのJohn Smithに関するすべてのデータを返したくないことがあります。
- 別の例として、Analytics Cookie IDなどのデバイス IDがあります。 IDが携帯電話のアプリで発生した場合、そのIDを使用するすべてのインタラクションを携帯電話の所有者が利用できるようにすることを決定できます。 ただし、ホームコンピューターやライブラリーやインターネットカフェなどの共有デバイスで発生した場合、そのデバイスのユーザーを区別できず、別のユーザーのデータを返すリスクが大きすぎて、このタイプのIDを使用できないと判断する場合があります。
Analytics がサポートしている ID に関するベストプラクティス best-practices-an
この表を使用して、データプライバシー要求を Analytics に送信する際に使用する ID のタイプを判別します。 この情報がわかれば、変数に使用するその他のラベルを容易に特定できるようになります。
Cookie ID
- （従来の）Analytics Cookie
- ID サービスの Cookie（ECID）：旧 Marketing Cloud ID（MCID）
これらのCookieは、デバイス、より具体的にはデバイスのユーザーのブラウザーを識別します。 共通ログインが使用される共有デバイスの場合、このIDはデバイスのすべてのユーザーに適用されます。 アドビは、データプライバシー要求でこうした Cookie を使用できるように、Web サイトに挿入して Cookie を収集するための統合 JavaScript を作成しました。
Adobe Analytics のモバイル SDK のユーザーも Experience Cloud ID（ECID）を持っています。 SDK には、この ID を読み取るための API 呼び出しがあるので、アプリを拡張してデータプライバシー要求用にこの ID を収集できます。
多くの企業では、ブラウザーの Cookie ID は共有デバイス ID と考えられています。 その結果、法務チームと相談しながら、データプライバシーリクエストで許容可能な ID として使用することをサポートしないことにする場合があります。 または、これらの ID を使用する場合に、ごく限られた量のデータのみを返すように選択したり、削除リクエストに対してのみデータを受け入れるように選択したりできます。
これらのCookieには、変更できないID-DEVICE ラベル（I2およびDEL-DEVICE ラベル）があります。 デフォルトのAdobe Analytics設定では、デバイスの種類、OS、ブラウザーなどの一般的な情報に加えて、これらのIDを使用する際にweb サイトにアクセスした日時が返されます。 ただし、データプライバシー要求でこれらの ID を利用する場合は、以下で説明するように、ACC-ALL ラベルを追加または削除して、データプライバシーアクセス要求で返されるようにしたいフィールドを設定できます。
レポートスイートがログインを必要とするモバイルアプリに対応している場合、デバイスの Experience Cloud ID が特定のユーザーに対応しているかどうかを判断することもできます。 その場合、訪問したページ名、閲覧した製品名など、より多くのフィールドに ACC-ALL ラベルを付ける必要があります。
カスタムトラフィック変数（prop）またはカスタムコンバージョン変数（eVar）に ID を挿入しているお客様もいます。 最も一般的なのは CRM ID ですが、それ以外にも、電子メールアドレス、ユーザーログイン名、顧客のロイヤルティ番号、またはこれらの値のハッシュなどがあります。
- データプライバシー要求でこれらのいずれかの ID を使用する場合は、その ID を含むフィールドに ID-PERSON ラベルを設定する必要があります。
- （一般的ではないケース）これらのいずれかのカスタム変数に含まれている ID で、複数のユーザーが共有するデバイスのみが識別される場合は、その代わりに ID-DEVICE ラベルを使用できます。
- これらのフィールドにはI1またはI2のラベルも必要であり、DEL-PERSONまたはDEL-DEVICE ラベルも含める必要があります。 通常、DEL ラベルの「PERSON/DEVICE」オプションは、ID ラベルの「PERSON/DEVICE」オプションと一致します。
データプライバシーリクエストのデータ主体の識別に使用する ID を含むカスタム変数が、レポートスイートに複数あるのは稀です。 I1 や I2 のラベルが割り当てられている変数が複数あることもありますが、通常、ID-PERSON または ID-DEVICE ラベルもあるのは、そのうちの 1 つまたは 2 つのみです。
この機能は広く使用されていませんが、Analyticsでは、カスタム訪問者IDを指定できる実装もサポートしています。これは、既存のAnalytics トラッキング Cookieの代わりに使用される場合です。 このフィールドには、I2、ID-PERSON、DEL-PERSONというラベルがあります。
多くの実装では、CRM ID からこの ID を派生させて、ユーザーがサイトにログインしている間だけこの ID が存在するようにしています。 これにより、同じカスタム訪問者IDを複数のデバイスで使用できるようになります。 技術的な欠点のひとつは、ユーザーがログインする前に発生したトラッキングを、ログイン後に収集されたトラッキングと関連付けることができない点です。 代わりに、カスタム訪問者IDを使用してデバイスを簡単に識別する場合は、ID-PERSONおよびDEL-PERSON ラベルをそれぞれID-DEVICEおよびDEL-DEVICEに変更する必要があります。
削除ラベルの設定に関するベストプラクティス best-practices-delete
削除ラベルの DEL-DEVICE および DEL-PERSON は、慎重に使用してください。 データプライバシー要求で使用された ID を含まない変数に適用すると、Analytics の過去のレポートのカウント数（指標）がほとんどのケースで変更されます。
-
このいずれかのラベルを、I1、I2 または S1 というラベルが設定された変数に適用することをお勧めします。 I1、I2 または S1 のラベルが設定されていない変数には適用できません。
-
DEL- ラベルを設定した変数は匿名化されます（ID が「Data Privacy-」という接頭辞が付いたランダムの文字列に置き換えられます）。 同じ匿名化された値は、リクエストで使用されるIDによって識別されたすべてのヒットで、元の値のすべてのインスタンスを置き換えます。 このフィールドの元の値がそれらのIDの1つであった場合、レポート指標は変更されません。
-
通常、フィールドにID-DEVICE ラベルがある場合は、DEL-DEVICE ラベルも割り当てる必要があります。
-
同様に、フィールドにID-PERSON ラベルがある場合は、DEL-PERSON ラベルも割り当てる必要があります。
-
フィールドにID ラベルがなく、匿名化する識別情報が含まれている場合、適切なラベル（デバイスまたは人物）は実装によって異なります。 データプライバシー要求で Cookie ID のみを使用している場合は、DEL-DEVICE を使用します。
-
ID-PERSON ラベルが設定された別のフィールドでカスタム ID を使用しており、該当の ID を含む行のみを消去したい場合は、DEL-PERSON を使用します。
-
DEL-DEVICEまたはDEL-PERSON ラベルが、そのリクエストのID （拡張IDを含む）としても使用されない変数で指定された場合、その変数の一意の値は、指定された（または拡張された） IDが発生したヒットでのみ匿名化されます。 他のヒットに同じ値が含まれている場合、その他の場所では更新されません。 これにより、カウント（指標）が変化する可能性があります。
例えば、eVar7 に値「foo」を含む 3 つのヒットがあり、それらの 1 つだけが削除に一致する異なる変数の ID を持つ場合、そのヒットの「foo」は、「Data Privacy-123456789」のような値に変更され、他の 2 つのヒットは変更されません。 eVar7 の一意の値の数を表示するレポートは、以前表示されたよりも 1 つ多く一意の値を表示します。 eVars の上位の値を表示するレポートは、（以前の 3 つのインスタンスではなく）2 つのインスタンスのみの「foo」が含まれ、新しい値の 1 つのインスタンスも表示されます。
アクセスラベルの設定に関するベストプラクティス best-practices-access
他のラベルが設定されるフィールドはほとんどありませんが、多くの場合は大部分のフィールドに ACC ラベルが設定されます。 適切なアクセスラベルは、データプライバシー要求で使用する ID によって異なります。
使用しているIDがCookie IDまたはID-DEVICE ラベルを持つIDのみである場合は、ACC-ALL ラベルのみを使用してください。
アクセスリクエストごとに 1 組のファイルが取得されます。1 つのファイルには指定したすべての ACC-ALL フィールドに一致する各ヒットの行が含まれ、もう 1 つのファイルにはこのデータの概要をまとめた概要ファイルが含まれます。