ラベル設定に関するベストプラクティス

NOTE
ラベル設定は、新しいレポートスイートが作成されるたびに、または既存のレポートスイート内で新しい変数を有効にする際に、確認する必要があります。 また、新しいソリューション統合が有効になると、ラベル設定が必要になる可能性のある新しい変数を公開できるので、ラベル設定を確認する必要があります。モバイルアプリまたは Web サイトを再実装すると、既存の変数の使用方法が変わる可能性があり、これにより、ラベルを更新する必要が生じる可能性があります。

個人を直接的に特定できる ID と間接的に特定できる ID direct-vs-indirect

どの変数やフィールドにどのラベルを適用するかを把握するためには、まず Analytics データから取得する ID について理解し、データプライバシー要求でどの ID を使用するかを決める必要があります。データプライバシーによって、何を ID とするかの範囲が広がります。ID は、個人を直接的に特定できるもの(ID ラベル:I1)と、間接的に特定できるもの(ID ラベル:I2)の 2 種類に大別されます。

  • 個人を直接的に特定できる ID(I1):個人の名前を示す ID や、個人に直接連絡できる手段となる ID。例えば、人の名前(同じ名前が何百人もいる可能性がある、John Smith のようなよくある名前も含む)や電子メールアドレス、電話番号が該当します。名前を含まない電子メールアドレスは、特定できるのが世帯または企業のみで、その中のどの個人かは特定できない場合でも、個人を直接的に特定できる ID と見なされることがあります。

  • 個人を間接的に特定できる ID(I2):単独では個人を特定することはできないものの、他の情報(お客様が所有しているものとそうでないものを含む)と組み合わせることで個人を特定できる ID。例えば、個人を間接的に特定できる ID は、顧客のロイヤルティ番号や、企業の CRM システムで使用される顧客ごとの一意の ID などが該当します。Analytics で使用されるトラッキング Cookie に保管される匿名 ID は、データプライバシーでは個人を間接的に特定できる ID と見なされる可能性があります。特定できるのが個人ではなく、デバイスのみの場合でもそれは同様です(共有デバイス上では、これらの Cookie でシステム内の複数のユーザーを識別することはできません)。例えば、Cookie を使用して、その Cookie を持つコンピューターを検索することはできませんが、ユーザーがコンピューターにアクセスして Cookie を見つけた場合は、Analytics の Cookie データをそのコンピューターに関連付けることができます。

    IP アドレスも個人を間接的に特定できる ID と見なされます。これは、特定の時点で単一デバイスのみに割り当てられる場合があるからです。ただし、ISP が多くのユーザーの IP アドレスを変更することがよくあるので、時間が経つと、ある IP アドレスが ISP のすべてのユーザーに使用されていた可能性があるというケースも出てきます。また、ISP の多くのユーザーや、企業の同一イントラネット上の複数の従業員が同じ外部 IP アドレスを共有することも稀ではありません。このため、アドビではデータプライバシーリクエストの ID として IP アドレスを使用することをサポートしていません。ただし、アドビが許可している ID が削除要求で使用されていた場合は、アドビはその ID に伴って発生した IP アドレスも削除します。I1 または I2 のこのカテゴリに分類される可能性のある収集された ID が他に存在するかどうかを判断する必要がありますが、データプライバシーリクエストの識別 ID としての使用には適していません。

Analytics データ内の様々な ID を収集している場合でも、データプライバシー要求では一部の ID のみを使用するよう設定します。その主な理由は次のとおりです。

  • 独自のシステム内で、いずれかの ID(電子メールアドレスなど)を別の ID(CRM ID など)にマッピングできます。その場合は、一貫性を保つために、データプライバシーの処理時にはデータプライバシー要求で CRM ID のみを使用するようにします。
  • あるユーザーが実際に ID に関連付けられているユーザーであることを確認する方法はありません。例えば、ある IP アドレスを使用したのが 1 人のユーザーのみで、要求を送信した人物がそのユーザーであることを確認するのは、非常に難しい場合があります。
  • 一部の ID は複数の人物に対応していることがあり、ある人物に関する情報を、同一の ID を持つ別の人物に返すことは避ける必要があります。例えば、あるユーザーの名前が John Smith であることを確認できたとしても、システム内のすべての John Smith に関するすべてのデータを返すのは避けるようにします。
  • 別の例としては、Analytics Cookie ID などのデバイス ID が挙げられます。携帯電話のアプリの ID では、その ID を使用するすべてのインタラクションを、携帯電話の所有者が利用できるようにすることもあります。ただし、自宅、図書館、インターネットカフェのパソコンなどの共有デバイスの ID の場合は、そのデバイスのユーザーを識別できないように設定することもあります。こうしたケースでは、違うユーザーのデータを返すおそれが十二分にあるので、このタイプの ID は利用できません。

Analytics がサポートしている ID に関するベストプラクティス best-practices-an

この表を使用して、データプライバシー要求を Analytics に送信する際に使用する ID のタイプを判別します。この情報を知れば、変数に使用すべき他のラベルを簡単に判別できます。

ID タイプ
レコメンデーション

Cookie ID

この 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、ブラウザーなど)と、Web サイトにこれらの ID を使用する訪問があった日時のみが返されます。ただし、データプライバシー要求でこれらの ID を利用する場合は、以下で説明するように、ACC-ALL ラベルを追加または削除して、データプライバシーアクセス要求で返されるようにしたいフィールドを設定できます。

レポートスイートがログインを必要とするモバイルアプリに対応している場合、デバイスの Experience Cloud ID が特定のユーザーに対応しているかどうかを判断することもできます。その場合、訪問したページ名、閲覧した製品名など、より多くのフィールドに ACC-ALL ラベルを付ける必要があります。

注意:データプライバシー要求で「expandIds」オプションを指定すると、要求には常に Cookie ID に加えて、指定した他の ID が含まれるようになります。詳しくは、ID 拡張を参照してください。そうした場合、Cookie ID のみを持ち、他の ID を持たないヒットは、アクセス要求の一部として ACC-ALL のラベルが設定されたデータのみを返します。

カスタム変数の ID

カスタムトラフィック変数(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 つのみです。

カスタム訪問者 ID

一般的ではありませんが、Analytics は、従来の Analytics トラッキング Cookie の代わりに使用されるカスタム訪問者 ID を利用できる実装にも対応しています。このフィールドには、I2、ID-PERSON、DEL-PERSON の各ラベルが割り当てられています。

多くの実装では、CRM ID からこの ID を派生させて、ユーザーがサイトにログインしている間だけこの ID が存在するようにしています。そのため、複数のデバイスで同一のカスタム訪問者 ID を使用することが可能です。ユーザーがログインする前の追跡情報を、ログイン後の追跡情報に関連付けることができないという技術的な問題があります。代わりに、カスタム訪問者 ID を使用してデバイスを識別するだけであれば、ID-PERSON および DEL- PERSON ラベルをそれぞれ ID-DEVICE および DEL- DEVICE に変更する必要があります。

削除ラベルの設定に関するベストプラクティス best-practices-delete

NOTE
prop は常に大文字と小文字が区別されません。eVar もデフォルトでは大文字と小文字が区別されませんが、アドビカスタマーケア経由で区別するように変更できます。ID を含む eVar で、大文字と小文字が区別される設定になっている場合は、データプライバシー要求を送信する際に、要求で使用される大文字と小文字が、対象の ID を含むヒットで使用される大文字と小文字に一致するように、大文字と小文字を適切に区別して使用する必要があります。

削除ラベルの DEL-DEVICE および DEL-PERSON は、慎重に使用してください。データプライバシー要求で使用された ID を含まない変数に適用すると、Analytics の過去のレポートのカウント数(指標)がほとんどのケースで変更されます。

  • このいずれかのラベルを、I1、I2 または S1 というラベルが設定された変数に適用することをお勧めします。I1、I2 または S1 のラベルが設定されていない変数には適用できません。

  • DEL- ラベルを設定した変数は匿名化されます(ID が「Data Privacy-」というプレフィックスが付いたランダムの文字列に置き換えられます)。要求で使用された ID によって識別されるすべてのヒットの元の値が、匿名化された同一の値に置き換えられます。このフィールドの元の値がこの ID のいずれかだった場合は、レポートの指標は変わりません。

  • 一般的に、フィールドのラベルが ID-DEVICE の場合は、DEL-DEVICE ラベルも割り当てます。

  • 同様に、フィールドのラベルが ID-PERSON の場合は、DEL-PERSON ラベルも割り当てます。

  • ID ラベルが設定されていないものの、匿名化する識別情報が含まれているフィールドの場合は、状況によって適切なラベル(DEVICE または PERSON)が異なります。データプライバシー要求で Cookie ID のみを使用している場合は、DEL-DEVICE を使用します。

  • ID-PERSON ラベルが設定された別のフィールドでカスタム ID を使用しており、該当の ID を含む行では ID を消去したい場合は、DEL-PERSON を使用します。

  • ID の拡張を使用し、識別されたすべてのデバイスのすべてのヒットで、すべての値を消去したい場合は、DEL-DEVICE を使用します。この場合、好みに応じて DEL-DEVICE ラベルと DEL-PERSON ラベルの両方を適用できますが、ID 拡張はユーザー ID に一致するすべての行がデバイス ID にも一致することを意味するので、DEL-PERSON ラベルは不要です。

  • ID 拡張の使用を指定していないが、異なるリクエストに対してデバイス ID とユーザー ID を組み合わせて使用する場合、どちらかのタイプの ID が使用されているときに削除する必要がある変数に対して DEL-DEVICE ラベルと 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
推奨事項
デバイス ID のみ

Cookie ID のみまたは ID-DEVICE ラベルが設定された ID のみを使用する場合は、ACC-ALL ラベルのみを使用します。

アクセスリクエストごとに 1 組のファイルが取得されます。1 つには指定したすべての ACC-ALL フィールドに一致する各ヒットの行が含まれ、もう 1 つにはこのデータの概要が含まれます。

ID 拡張をおこなわないユーザー ID

ID-PERSON ラベルが設定されたカスタム ID のみを使用し、ID 拡張をおこなわない場合は、ACC-PERSON ラベルを使用します。ただし、デフォルトの ACC-ALL ラベルを変更する必要はありません。これらのフィールドは、アクセス要求に自動的に含まれます。

アクセス要求ごとに 1 組のファイルが返されます。指定された ACC-DEVICE および ACC-PERSON フィールドをすべて含む一致するヒットごとの行で構成されるファイルと、そのデータの概要を含むファイルです。

混合 ID および ID 拡張

データプライバシー要求にデバイス ID とユーザー ID の両方を含める場合や、カスタム ID(カスタム訪問者 ID か、prop または eVar に含まれている ID)を使用する場合は、使用する ACC ラベルに注意する必要があります。各アクセスリクエストは、2 組のデータファイルを返します。1 組には、一致したユーザー ID を含むヒットからのデータ、もう 1 組には、ユーザー ID には一致しないがデバイス ID には一致したヒットからのデータが含まれます。

「ユーザー ID」ファイルには、ユーザー ID に一致したすべてのヒットに関するデータと、ACC-PERSON か ACC-ALL のどちらかのラベルが設定されたすべてのフィールドが含まれます(一方のファイルには一致したすべてのヒットが含まれ、もう一方は概要となります)。

「デバイス ID」ファイルには、ACC-ALL ラベルが設定されたフィールドと、一致するユーザー ID を含まないヒットのみが含まれます。これらのファイルには、共有デバイスの他のユーザーによって生成されたデータが含まれる場合があるので、ACC-ALL ラベルを含む一連のフィールドについて慎重に検討する必要があります。Analytics 内のデフォルトのラベル設定では、このラベルは、デバイス関連の汎用情報フィールド(デバイスのタイプ、OS、ブラウザーなど)と、各ヒットの日時にのみ適用されます。

デバイスとユーザーの両方のファイルセットをアドビから受け取り、ユーザーファイルのみを共有して、共有デバイスの他のユーザーによって生成された可能性があるデータは共有しないようにすることもできます。また、片方または両方のファイルセットのデータを、データ主体について把握している他の情報と組み合わせ、独自の形式で返すことも可能です。

recommendation-more-help
2969e653-1f9b-4947-8b90-367efb66d529