こんにちは、野田です
昨今、Safari ITPの影響でクライアント発行のCookieの寿命が短くなる中、ユーザーを安定して識別しづらい状況になっています
この課題を解決するため、サーバーサイド発行のクッキーを使うケースが増えています
今回は、Adobe Analytics WebSDKにて、サーバーサイド発行のクッキーを使い、ユーザー識別子であるECIDを復元する様子を詳細に検証していきます
目次
どんな仕様かざっくり
- ユーザーの識別は基本的にcookieで管理している
- クライアントサイド（JavaScript）発行のcookieでは、寿命が短い（＝ユーザー識別子：ECIDはここに該当）
- サーバーサイド発行cookieは、寿命が長い
- 先にいなくなるユーザー識別子用のcookieをサーバーサイドクッキーで復元してユーザーを安定的に識別する
登場人物
| AMCV_{組織ID}@AdobeOrg : cookie | ECIDやその他情報を保持 |
| kndctr_{組織ID}_AdobeOrg_identity : cookie | ECIDやその他情報を暗号化して保持 |
| fpid : cookie | サーバーサイドで発行（名称は任意） |
| ECID | ユーザー識別子 |
| IdentityMap | Edge Network（WebSDK）にfpidを送信する機能 |
ECIDが変わるタイミングの検証
結論：AMCV_, kndctr_クッキーがない場合、ECIDが変わる
※ この段落は、結論さえわかっていれば読み進められます
↑ 現在のクッキー
// ECID確認用
(await alloy('getIdentity')).identity.ECID
↑ 現在のECIDを確認
fpid(cookie)がない状態でAMCV_のみ削除からの復元を確認
手動でAMCV_クッキーを削除して、更新します
↑ AMCV_クッキー削除
画面を更新します
↑ 更新後のクッキー
↑ コード確認
結果：AMCV_クッキー削除 → ECID復元
fpid(cookie)がない状態でkndctr_のみ削除からの復元を確認
手動でkndcr_削除して、更新します
↑ kndctr_クッキー削除
画面を更新します
↑ 更新後のクッキー
↑ コード確認
結果：kndctr_クッキー削除 → ECID復元
fpid(cookie)がない状態でAMCV_, kndctr_の削除からの復元を確認
手動でAMCV_、kndcr_削除して、更新します
↑ AMCV_, kndctr_クッキー削除
※ kndctr_{組織ID}_AdobeOrg_clusterは、Adobe Edge Networkのリージョン情報のため、ECIDとは関係ありません
各種cookieについての参考URL:
https://experienceleague.adobe.com/ja/docs/core-services/interface/data-collection/cookies/web-sdk
↑ 更新後のクッキー
↑ コード確認
結果：2つのクッキー削除 → ECID新規発行
これで2つのクッキーがECIDを構成する上で必要なことがわかりました
次は、「今のECIDがある」状態からサードパーティクッキーを発行してFPIDをIdentityMapに設定します
すでにECIDがある状態でfpid発行
この段落が最重要です！
↑ 現在のコードを再確認
ECID: 71759742233093926852486172409537972541
fpidクッキーを発行して、画面を更新します
↑ fpidクッキーがあることを確認
↑ fpidクッキーと同じ値（4ae1f28c-2719-4ebe-87f9-5dc15f8f41bf）をWebSDKの送信データに設定し送信していることを確認
※ サーバーサイドから発行されたクッキー名（今回はfpid）は任意ですが、identityMapで送信するための名前空間は「FPID」と全て大文字である必要があります
では、ここでECIDを構成する2つのクッキーを削除して更新します
identityMapにもFPIDが設定されるのでECIDを復元できそうです
↑ ECIDに必要な2つのクッキーを削除、fpidは存在している状態
画面を更新します
↑ 更新後のクッキー
気づいている方もいるかもですが、ECID=AMCV_クッキーのMCMIDだったりします
↑ コードでも確認
先ほどの数値と違う（先頭7なのでぱっと見で勘違いしそう）
更新前ECID: 71759742233093926852486172409537972541
更新後ECID: 75020280887124336220211987196775701845
FPIDでのECID復元がうまくいきませんでした
再度、ECID系クッキーを削除します（ネタバレ：復元します）
FPIDがある状態でECIDを発行
もう一度、ECIDを削除します
↑ fpidクッキーのみ残し
画面を更新します
↑ 更新後のクッキー
おお、MCMIDが同じそう
↑ コードでも確認
更新前ECID: 75020280887124336220211987196775701845
更新後ECID: 75020280887124336220211987196775701845
FPIDからECIDの復元を確認できました
次は、FPID, ECIDを削除して動作を確認します
FPID, ECID削除
では、fpid, AMCV_, kndctr_クッキーを削除します
ここでの観点は、FPID, ECIDを新たに発行後に、ECIDをFPIDで復元できるかを検証します
↑ 全消し
画面を更新します
↑ 更新後のクッキー
コードでの確認割愛します
ECID: 34180933153157445047597657547883793036
次にfpidクッキーのみ残しで更新します
↑ ECID系クッキー削除
画面を更新します
↑ 更新後のクッキー
ECID: 34180933153157445047597657547883793036
FPIDでまたもや復元が成功しています
まとめ
簡単に整理します
①ECIDが発行された後にFPIDが発行される＝FPIDによる復元はできない
②FPIDはあるが、ECIDがないところからECIDが発行される＝FPIDによる復元ができる
③FPID、ECIDが同時？＝FPIDによる復元ができる
③を補足すると、以下の順でFPID, ECIDが生成、使用されています
- サイトにアクセス
- サーバーからHTMLを返却（サーバーサイドクッキー：fpidとともに）
- クライアント側でfpidをidentityMapで送信
- fpidがある状態で新たにECIDが発行される
→ つまり、FPIDがある状態でECIDが発行される
③は、内部的には②と同じ動きをしています
結果：FPIDを元に生成されたECIDのみFPIDから復元できる
この記事を読んだ後に以下の公式ドキュメントを読むとより理解が深まると思います
※ 特に2回目の訪問 → 3回目の訪問が①のケースに該当します
https://experienceleague.adobe.com/ja/docs/experience-platform/web-sdk/identity/first-party-device-ids#migrating-to-fpid
