Adobe Experience Cloud ID

Adobe Experience Platform Web SDKは、AdobeIDサービスを利用します。 これにより、各デバイスには、デバイス上で保持される一意の識別子が割り当てられ、ページ間のアクティビティを結び付けることができます。

ファーストパーティID

Identity Serviceは、IDをファーストパーティドメインのcookieに保存します。 Identity Serviceは、ドメインのHTTPヘッダーを使用してCookieの設定を試みます。 失敗した場合、Identity ServiceはJavaScriptでのcookieの設定にフォールバックします。 Edgeドメイン設定にCNAMEを設定することをお勧めします。

Platform Web SDKからのすべてのヒットには、Edgeネットワーク上のIDサービスによってECIDが追加されます。 初回訪問者の場合、ECIDが生成され、ペイロードに追加されます。 繰り返し訪問者の場合、ECIDはkndctr_{YOUR-ORG-ID}_AdobeOrg_identity Cookieから取得され、ペイロードに追加されます。

ECIDはxdmのidentityMapフィールドに追加されます。 ブラウザーの開発ツールを使用して、タイプのペイロードの下で応答のECIDを表示できます。identity:resultですが、リクエスト内のECIDは確認できません。

CNAME 実装を使用すると、アドビで使用される収集ドメインをカスタマイズして、独自のドメインと一致させることができます。 これにより、アドビは JavaScript を使用して、クライアントサイドではなくサーバーサイドでファーストパーティ Cookie を設定できます。 以前は、これらのサーバー側ファーストパーティcookieには、Safariブラウザー上のAppleのIntelligent Tracking Prevention(ITP)ポリシーに基づいて課された制限は適用されていませんでした。 ただし、2020年11月に、Appleは、CNAMEを使用して設定されたCookieにもこれらの制限が適用されるようにポリシーを更新しました。 現在、CNAMEによってサーバー側に設定されたCookieとJavaScriptによってクライアント側に設定されたCookieの両方が、ITPでの7日間または24時間の有効期限に制限されています。 ITPポリシーについて詳しくは、tracking preventionに関するAppleのドキュメントを参照してください。

CNAME実装はcookieの有効期間に関してメリットを提供しませんが、広告ブロッカーや一般的でないブラウザーなど、データがトラッカーとして分類するドメインに送信されないというメリットがあります。 このような場合、CNAMEを使用すると、これらのツールを使用するユーザーのデータ収集が中断されるのを防ぐことができます。

サードパーティID

Identity Serviceには、IDをサードパーティドメイン(demdex.net)と同期して、サイト間での追跡を有効にする機能があります。 これを有効にすると、訪問者（ECIDのない訪問者など）に対する最初のリクエストがdemdex.netに対しておこなわれます。 これは、ChromeなどのChromeを許可するブラウザーでのみ実行され、設定のthirdPartyCookiesEnabledパラメーターで制御されます。 この機能をすべて一緒に無効にする場合は、thirdPartyCookiesEnabledをfalseに設定します。

IDの移行

訪問者APIを使用してから移行する場合は、既存のAMCV Cookieを移行することもできます。 ECID移行を有効にするには、設定でidMigrationEnabledパラメーターを設定します。 ID移行を使用すると、次のような場合に役立ちます。

• ドメインの一部のページが訪問者APIを使用し、他のページがこのSDKを使用している場合。 この場合をサポートするために、SDKは既存のAMCV Cookieを読み取り、既存のECIDで新しいCookieを書き込みます。 さらに、SDKは、SDKが実装されたページで最初にECIDを取得した場合、訪問者APIが実装された後続のページで同じECIDを持つように、AMCV Cookieを書き込みます。
• Adobe Experience Platform Web SDKが、訪問者APIも持つページで設定されている場合。 このケースをサポートするために、AMCV Cookieが設定されていない場合、SDKはページ上で訪問者APIを探し、呼び出してECIDを取得します。
• サイト全体でAdobe Experience Platform Web SDKを使用していて、訪問者APIがない場合は、再訪問者の情報を保持できるように、ECIDを移行すると便利です。 idMigrationEnabledを使用して一定期間SDKをデプロイした後、ほとんどの訪問者Cookieが移行されるように、設定をオフにできます。

移行用の特性の更新

XDM形式のデータがAudience Managerに送信される場合、このデータは移行時にシグナルに変換する必要があります。 XDMが提供する新しいキーを反映するには、特性を更新する必要があります。 このプロセスは、Audience Managerが作成したBAAAMツールを使用することで容易になります。

サーバー側転送

現在サーバー側転送が有効になっていて、appmeasurement.jsを使用している場合。 visitor.jsサーバー側転送機能を有効にしたままにしておくと、問題は発生しません。 バックエンドで、AdobeはAAMセグメントを取得し、Analyticsへの呼び出しに追加します。 Analyticsへの呼び出しにこれらのセグメントが含まれる場合、Analyticsは、データを転送するAudience Managerを呼び出さないので、二重のデータ収集はおこなわれません。 また、Web SDKを使用する際にロケーションヒントを使用する必要もありません。これは、同じセグメント化エンドポイントがバックエンドで呼び出されるからです。

訪問者IDおよび地域IDの取得

一意の訪問者IDを使用する場合は、getIdentityコマンドを使用します。 getIdentity は、現在の訪問者の既存のECIDを返します。ECIDを持たない初回訪問者の場合、このコマンドは新しいECIDを生成します。 getIdentity は、訪問者の地域IDも返します。詳しくは、『Adobe Audience Managerユーザーガイド』を参照してください。

alloy("getIdentity")
  .then(function(result) {
    // The command succeeded.
    console.log("ECID:", result.identity.ECID);
    console.log("RegionId:", result.edge.regionId);
  })
  .catch(function(error) {
    // The command failed.
    // "error" will be an error object with additional information.
  });

IDの同期

さらに、Identity Serviceを使用すると、syncIdentityコマンドを使用して独自のIDをECIDと同期できます。

IDの同期では、複数のIDを使用してデバイスやユーザーを識別し、認証状態を設定して、どのIDを主要な識別子と見なすかを決定できます。 識別子がprimaryとして設定されていない場合、プライマリはデフォルトでECIDになります。

alloy("sendEvent", {
  xdm: {
    "identityMap": {
      "ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
        {
          "id": "1234",
          "authenticatedState": "ambiguous",
          "primary": true
        }
      ]
    }
  }
});

identityMap内の各プロパティは、特定のID名前空間に属するIDを表します。 プロパティ名は、ID名前空間のシンボルである必要があります。このシンボルは、Adobe Experience Platformのユーザーインターフェイスの「ID」の下に表示されます。 プロパティ値は、そのID名前空間に関連するIDの配列である必要があります。

ID配列内の各IDオブジェクトは、次のように構造化されています。

id

これは、指定した名前空間の同期するIDです。

authenticationState

IDの認証状態。

primary

このIDを、統合プロファイルでプライマリフラグメントとして使用するかどうかを指定します。 デフォルトでは、ECIDがユーザーのプライマリ識別子として設定されています。