Web SDK でのファーストパーティデバイス ID

Adobe Experience Platform Web SDK は、 Adobe Experience Cloud ID(ECID) cookie を使用して web サイト訪問者に送信し、ユーザーの行動を追跡します。 cookie のライフスパンに関するブラウザーの制限を考慮するには、代わりに、独自のデバイス識別子を設定および管理するように選択できます。 これらはファーストパーティデバイス ID(FPID) と呼ばれます。

このドキュメントでは、Platform Web SDK 実装でファーストパーティデバイス ID を設定する方法について説明します。

前提条件

このガイドは、ECID や ECID の役割など、Platform Web SDK での ID データの動作について既に詳しいことを前提としています identityMap. 概要については、 Web SDK の ID データ を参照してください。

FPID の使用

FPID はファーストパーティ Cookie を使用して訪問者を追跡します。 ファーストパーティ cookie は、DNS を使用するサーバーを使用して設定される場合に最も効果的です。 レコード （IPv4 の場合）または AAA レコード （IPv6 の場合）。DNS CNAME または JavaScript コードとは異なります。

FPID Cookie が設定されると、その値を取得し、イベントデータの収集時にAdobeに送信できます。 収集された FPID は、ECID を生成するシードとして使用されます。ECID は、引き続きAdobe Experience Cloudアプリケーションの主な識別子です。

Web サイト訪問者の FPID を Platform Edge Network に送信するには、 identityMap を選択します。 このドキュメントの後半の節を参照してください。 での FPID の使用 identityMap を参照してください。

ID 形式の要件

Platform Edge ネットワークは、 UUIDv4 形式. UUIDv4 形式でないデバイス ID は拒否されます。

UUID を生成すると、ほとんどの場合、一意のランダムな ID が生成され、衝突の発生確率は無視できます。 UUIDv4 は、IP アドレスやその他の個人情報 (PII) を使用してシードすることはできません。 UUID はあらゆる場所に存在し、ほぼすべてのプログラミング言語でライブラリを見つけて生成できます。

独自のサーバーを使用した cookie の設定

所有しているサーバーを使用して Cookie を設定する場合、ブラウザーポリシーによって Cookie が制限されるのを防ぐために、様々な方法を使用できます。

Cookie を設定するタイミング

FPID Cookie は、Edge ネットワークにリクエストを送信する前に設定するのが理想的です。 ただし、この方法が使用できない場合でも、ECID は既存のメソッドを使用して生成され、cookie が存在する限り、プライマリ識別子として機能します。

ECID が最終的にブラウザー削除ポリシーの影響を受けますが、FPID が影響を受けない場合、FPID は次の訪問時の主な識別子になり、後続の訪問のたびに ECID のシードに使用されます。

cookie の有効期限の設定

Cookie の有効期限の設定は、FPID 機能を実装する際に慎重に検討する必要があります。 これを決定する際は、組織が運営する国や地域と、それらの各地域の法律やポリシーを考慮する必要があります。

この決定の一環として、会社全体の Cookie 設定ポリシーまたは、を使用する各ロケールのユーザーごとに異なる Cookie 設定ポリシーを採用することができます。

cookie の初回有効期限に対して選択した設定に関係なく、サイトへの新しい訪問が発生するたびに cookie の有効期限を延長するロジックを含める必要があります。

cookie フラグの影響

異なるブラウザーでの cookie の処理方法に影響を与える様々な cookie フラグがあります。

HTTPOnly http-only

を使用して設定された Cookie HTTPOnly フラグには、クライアント側のスクリプトを使用してアクセスできません。 つまり、 HTTPOnly フラグを設定する場合、サーバー側のスクリプティング言語を使用して、cookie の値を読み取り、 identityMap.

Platform Edge Network に FPID Cookie の値を読み取らせる場合は、 HTTPOnly フラグを設定することで、クライアント側のスクリプトによって値にアクセスできなくなり、Platform Edge ネットワークの cookie を読み取る機能に悪影響を与えなくなります。

Secure secure

Cookie の設定に基づいて、 Secure 属性は、暗号化されたリクエストで HTTPS プロトコル経由でのみサーバーに送信されます。 このフラグを使用すると、中間者の攻撃者が容易に cookie の値にアクセスできないようにすることができます。 可能な場合は、 Secure フラグ。

SameSite same-site

The SameSite 属性を使用すると、サーバーは、クロスサイトリクエストで cookie を送信するかどうかを決定できます。 属性は、クロスサイトフォージェリ攻撃に対する保護を提供します。 次の 3 つの値が使用可能です。 Strict, Lax、および None. 組織にとって適切な設定を判断するには、社内チームに相談してください。

いいえの場合 SameSite 属性が指定されている場合、一部のブラウザーのデフォルト設定がになりました。 SameSite=Lax.

での FPID の使用 identityMap identityMap

以下に、で FPID を設定する方法の例を示します。 identityMap:

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": true
      }
    ]
  }
}

他の ID タイプと同様に、内に他の ID を含めることができます identityMap. 認証済み CRM ID に含まれる FPID の例を次に示します。

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": true
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

ファーストパーティデータ収集が有効な場合に、Edge ネットワークが読み取る Cookie に FPID が含まれている場合は、認証済みの CRM ID のみを取り込む必要があります。

{
  "identityMap": {
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

次の identityMap Edge ネットワークに primary FPID の指標。 最後に、に存在する ID の 1 つ identityMap は、 primary.

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-12d3-a456-426614174000",
        "authenticatedState": "ambiguous"
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated"
      }
    ]
  }
}

この場合、Edge ネットワークから返されるエラー応答は次のようになります。

{
    "type": "https://ns.adobe.com/aep/errors/EXEG-0306-400",
    "status": 400,
    "title": "No primary identity set in request (event)",
    "detail": "No primary identity found in the input event. Update the request accordingly to your schema and try again.",
    "report": {
        "requestId": "{REQUEST_ID}",
        "configId": "{CONFIG_ID}",
        "orgId": "{ORG_ID}"
    }
}

ID 階層

ECID と FPID の両方が存在する場合、ユーザーを識別する際に ECID が優先されます。 これにより、既存の ECID がブラウザーの cookie ストアに存在する場合でも、その ECID がプライマリ識別子のままになり、既存の訪問者のカウントが影響を受けるリスクを回避できます。 既存のユーザーの場合、ECID が期限切れになるか、ブラウザーポリシーまたは手動プロセスの結果として ECID が削除されるまで、FPID はプライマリ ID になりません。

ID は次の順序で優先されます。

ファーストパーティデバイス ID への移行

以前の実装から FPID の使用に移行する場合は、トランジションが低レベルでどのように表示されるかを視覚化するのが困難な場合があります。

このプロセスを説明するために、以前にサイトを訪問した顧客と、Adobeソリューションでの顧客の識別方法に FPID 移行が及ぼす影響を考慮します。

FAQ

以下は、ファーストパーティデバイス ID に関するよくある質問に対する回答のリストです。

単に ID を生成するのと、ID をシードするのとでは、どのように異なりますか。

シードの概念は、Adobe Experience Cloudに渡された FPID が決定論的アルゴリズムを使用して ECID に変換される点が一意です。 同じ FPID がAdobe Experience Platform Edge Network に送信されるたびに、同じ ECID が FPID からシードされます。

ファーストパーティデバイス ID は、いつ生成する必要がありますか？

訪問者の水増しの可能性を減らすには、Web SDK を使用して最初のリクエストをおこなう前に FPID を生成する必要があります。 ただし、これができない場合、ECID はそのユーザーに対して生成され、プライマリ識別子として使用されます。 生成された FPID は、ECID が存在しなくなるまで、プライマリ識別子になりません。

ファーストパーティデバイス ID をサポートしているのは、どのデータ収集方法ですか？

現在、FPID をサポートしているのは Web SDK のみです。

FPID は、どのプラットフォームまたはExperience Cloudソリューションにも保存されますか。

FPID を使用して ECID をシードすると、その FPID は identityMap とは、生成された ECID に置き換えられています。 FPID は、Adobe Experience PlatformやExperience Cloudソリューションには保存されません。