前回記事：Adobe Web SDK クロスドメイン計測【第1部】ECID連携の仕組みと検証 の続きです
前回の記事では、Adobe Web SDKのクロスドメイン対応で ECID（Experience Cloud ID）をGETパラメタを使い、別ドメインに引き継ぐ仕組み を検証しました
最後の検証では、遷移先のFPIDによるECIDの復元を行いましたが、結果として遷移元ではなく、書き換え前のECIDで復元されていました
第二部では、ECIDとFPIDとともにクロスドメイン対応し、ユーザー識別永続化の方法を確認します
今回のやり方はあくまで１例となります
目次
FPID Cookieと別ドメインの問題
FPIDはサーバーサイド発行による1st Party Cookie（寿命が長い）です
Adobe Analytics WebSDKではこれを使用し、クライアントサイドで作成されたECID用Cookie（寿命が短い）を復元します
しかし、別ドメインで作成したCookieの値を使うことはできません
では、どのようにして別ドメイン発行のFPID Cookieを遷移先の1st Party Cookieとして扱うか？が問題となります
今回はサーバーサイドのコードに少しを加えます
サーバーサイド構成
これまでの構成
FPID Cookieが存在する
Yes: 値はそのままで有効期限を更新しFPID Cookieに上書きする（有効期限は更新する）
No: 値を新規発行しFPID Cookieを設定する
今回の想定
GETパラメタにFPIDが存在する
YES: GETパラメタの値をFPID Cookieに設定する
No: これまでの構成と同様
ECID, FPIDの書き換えの流れ
- （ブラウザ）サーバーに遷移元の情報をリクエスト
- （サーバー）FPID Cookie(123)を発行し、コンテンツ配信
- （ブラウザ）Adobe EdgeNetworkにFPID(123)をわたす
- （EdgeNetwork）ECID(abc)を返却
- （ブラウザ）ECID(abc), FPID(123)の情報をCookieに保持
- （ブラウザ）遷移先ページへECID（adobe_mc=abc）、FPID(123)のGETパラメタとともに遷移する
- （サーバー）遷移してきたURLからFPID(123)のGETパラメタを取得
- （サーバー）FPID CookieとしてGETパラメタを設定すし、コンテンツ配信
- （ブラウザ）Adobe EdgeNetworkにadobe_mcパラメタの値(123)をわたす
- （EdgeNetwork）ECID(abc)を返却して、ブラウザで保持
こんなイメージです
シンプル化します
想定：
上記の方法だと遷移元ページでFPIDを元に生成したECIDという組み合わせと同じ組み合わせを遷移先のページでも再現できそう
その結果、遷移先でECIDを削除してもFPIDによる復元で遷移元のECIDと一致できそう
それでは、検証に入ります
検証
以下の流れで検証をします
- 遷移先（main.local）のECIDとFPIDを確認
- 遷移元（other1.local）のECIDとFPIDを確認
- main.localへ遷移し、ECIDとFPIDを確認
- main.localでECIDを削除し、FPIDによる復元を確認
遷移先（main.local）のECIDとFPIDを確認
FPID: 5f71ce52-768f-4d16-808a-7bc4bf31b42b
ECID: 31024044954417295732371409892241953723
遷移元（other1.local）のECIDとFPIDを確認
FPID: 05c1a124-2186-4008-adf1-4a411da700e6
ECID: 32806461225239209280301725509063335031
main.localへ遷移し、ECIDとFPIDを確認
遷移する前にクライアント側のコードを説明します
<body>
<h1>Cross Domain Test</h1>
<a href="https://main.local:8443" class="cross-domain">setting DataCollection</a>
<a href="https://main.local:8443" id="cross-domain-code">setting Code</a>
<script>
const crossDomainLink = document.getElementById("cross-domain-code");
crossDomainLink.addEventListener("click", (e) => {
e.preventDefault();
alloy("appendIdentityToUrl", { url: crossDomainLink.href }).then(result => {
const FPID = _satellite.cookie.get("FPID");
document.location = result.url + "&FPID=" + FPID;
});
});
</script>
</body>setting Code(id=“cross-domain-code”)に対して、ECIDとFPIDをパラメタに付与します
appendIdentityToUrlでECIDパラメタ付きURLを生成します
URL生成後にFPIDを取得し、パラメタに付与します
パラメタにECID, FPIDがついていることを確認します
FPID: 05c1a124-2186-4008-adf1-4a411da700e6
ECID: 32806461225239209280301725509063335031
main.localのFPID, ECIDを確認しましょう
FPID: 05c1a124-2186-4008-adf1-4a411da700e6
ECID: 32806461225239209280301725509063335031
FPIDとECIDが遷移元（other1.local）から遷移先（main.local）へ渡り、遷移先の値が書き換わったことを確認しました
main.localでECIDを削除し、FPIDによる復元を確認
CookieをFPID以外削除します
また、URLもパラメタによって、再設定されないために外しておきます
イメージとしては、寿命が短いECIDが消えた後（最後の訪問から1週間以上経過）、寿命が長いFPIDが存在している状態で再訪問したケースです
FPID: 05c1a124-2186-4008-adf1-4a411da700e6
画面際読み込み
FPID: 05c1a124-2186-4008-adf1-4a411da700e6
復元されたECID: 32806461225239209280301725509063335031
正常にFPIDでECIDを復元できました
これでクロスドメインからのECID永続化が（ほぼ）できたといって差し支えないでしょう
まとめ
クロスドメインのFPIDによるECID永続化にはサーバーサイドの実装が必要です
とはいえ、FPID発行にも必要なので一緒に実装する方が良さそうですね
クライアントサイドも遷移URLにパラメタ付与の対応が必要となります
FPID, ECIDが一緒に書き換わることでクロスドメインのECID永続化を実現できます
懸念点
クロスドメインの設定が入っていないドメインが存在する場合、どことも紐づかなくなってしまうECIDが存在してしまいます
では、すべてのクロスドメインリンク、サーバーにクロスドメイン＋FPID対応を入れればいいのか？となるとドメイン数、リンク数によっては大変です
クライアントサイドでも単純にa[href]でのクロスドメイン遷移であれば、比較的簡単に（やりようによっては一括で）対応できます
JSによる遷移やsubmitなど遷移方法が各々違うものは、都度その箇所に合わせた実装が必要になるため、大変ですね
