Adobe Analytics Web SDKで複数ドメインをまたいで計測する場合、ユーザーを同一として扱うためにECID(Experience Cloud ID)の引き継ぎが必要になります
ただ、実際にどのようなタイミングでECIDが書き換わるのか、FPIDが存在する場合はどうなるのか、といった部分はドキュメントだけでは見えづらいところです
この記事では、Adobe Analytics Web SDKのクロスドメイン計測におけるECID連携の仕組みを検証します
第1部では、ECIDを引き継ぐためのコードやUI設定の紹介、遷移先でのECIDの切り替わり方を中心にまとめました
目次
クロスドメイン対応とは
Adobe Web SDKでのクロスドメイン対応は、異なるドメイン間で同じユーザーを識別するためにECIDを共有する仕組み です。
これを防ぐために、Web SDKではECIDをクエリパラメータとして受け渡す仕組み が用意されています。
ページ遷移時にadobe_mcというパラメータが付与され、遷移先のドメインでその値を読み取ってECIDを再設定します。
- 遷移元でECIDが発行される
- リンククリックなどで別ドメインへ遷移
- 遷移先URLに adobe_mc=TS=…|MCMID=… が付与される
- 遷移先のWeb SDKがその値を解析し、ECIDを引き継ぐ
ECIDを引き継ぐためのコードとUIの紹介
クロスドメイン対応を有効にすると、Web SDKが自動的にECIDをURLパラメータとして受け渡すようになります。
DataCollectionでの設定方法
Rulesを作成します
EVENTS

画面左
Extension: Core
Event Type: Click
画面右
specific elementsを選択し、任意のCSSセレクターを設定する
CONDITIONS
適宜設定してください
今回は検証環境のため、割愛します
ACTIONS

画面左
Extension: Adobe Experience Platform Web SDK
Action Type: Redirect with identity
画面右
特に変更する箇所はありません
画面にDataCollectionを反映します
画面確認

URL: https://other1.local:8443/
「setting DataCollection」をクリックします
遷移先URL確認

https://main.local:8443/?adobe_mc=TS%3D1761528873%7CMCMID%3D12441015964298885356786266784487727294%7CMCORGID%3D[企業ID]
別ドメインへパラメタ付きで画面の遷移を確認しました
ECIDの設定確認は後述します
コードでの設定方法
先ほどの画面の「setting Code」に対して以下のクリックイベントを付与します
<script>
const crossDomainLink = document.getElementById("cross-domain-code");
crossDomainLink.addEventListener("click", (e) => {
e.preventDefault();
alloy("appendIdentityToUrl", { url: e.currentTarget.href }).then(result => {
document.location = result.url;
});
});
</script>
appendIdentityToUrlで対象のhrefをパラメタ付きに変換して遷移します
遷移先URL確認
other1.local画面の「setting Code」をクリックします

https://main.local:8443/?adobe_mc=TS%3D1761530203%7CMCMID%3D12441015964298885356786266784487727294%7CMCORGID%3D[企業ID]
こちらも同様に別ドメインへパラメタ付きで遷移しました
2つのURL確認
このあと検証するECIDの書き換えの前準備をします
コード設定のパラメタとDataCollection設定のパラメタが同じことを確認します
DataCollectionhttps://main.local:8443/?adobe_mc=TS%3D1761528873%7CMCMID%3D12441015964298885356786266784487727294%7CMCORGID%3D[企業ID]
コードhttps://main.local:8443/?adobe_mc=TS%3D1761530203%7CMCMID%3D12441015964298885356786266784487727294%7CMCORGID%3D[企業ID]
adobe_mcの中を確認したところ、TS, MCMID, MCORGIDの3要素からなっていそうです
TSは数値の形から見るに1970/01/01の経過ミリ秒のようですね
MCMID=12441015964298885356786266784487727294 で一致しています
MCORGIDは企業IDなので無条件で一致します
補足:URL内に存在する特殊文字は、以下を意味しています(URLEncode)
%3D: =
%7C: |
ECID確認(Chrome Dev Tool – console)

パラメタのMCMIDはECIDとの一致を確認できました
遷移先のECIDを確認
遷移先であるmain.localのcookie情報を全削除し、再読み込みをします

ECID(MCMID): 61128017796549435085514692159162796768
FPID: 1920a669-226e-486e-8537-f6256a6769ed
※ FPIDは後の検証で使用するため、このタイミングで確認します
other1.localからmain.localへクロスドメイン対応用パラメタ付きで遷移します

MCMIDパラメタ:12441015964298885356786266784487727294
main.localのCookie情報を確認します

| other1.localから遷移前のECID | 61128017796549435085514692159162796768 |
| other1.localから遷移後のECID | 12441015964298885356786266784487727294 |
| other1.localからのMCMIDパラメタ | 12441015964298885356786266784487727294 |
クロスドメイン用のMCMIDパラメタでother1.localのECIDの書き換えができたことを確認できました
ただ、FPIDはmain.localからの遷移前後で同じままです
fpid: 1920a669-226e-486e-8537-f6256a6769ed
FPIDからECIDの復元を確認
別記事:Adobe WebSDK FPIDでECIDの復元を検証 のFPIDとECIDの関係が気になります
クロスドメイン対応で書き換えられたECIDが消えた場合、FPIDによる復元はどうなるか?という問題です
詳細は、上記別記事にありますが、ここでもFPIDについて説明します
度々話題になるSafari ITPなどによるCookie制限が個人を特定するためのCookieに影響を与えています
それを回避するため、Adobe Analytics WebSDKでは、サーバーサイドCookieを使い、個人識別用ECID(クライアント側のJavaScriptで生成)を復元する機能を提供しています
簡単にいうと生成する箇所(サーバーサイドかクライアントか)でCookieの寿命の長さが変わります
ECID(短い方)をFPID(長い方)で復元する方法となります
では、ECID(短い方)が時間経過によって消えたことを想定してCookieを削除してみます
main.localのCookieをわかりやすくfpid以外削除します

再読み込み実行後のCookie

MCMID: 61128017796549435085514692159162796768
当記事で前述したother1.local → main.localへの遷移前後のECIDを確認します
| other1.localから遷移前のECID | 61128017796549435085514692159162796768 |
| other1.localから遷移後のECID | 12441015964298885356786266784487727294 |
つまり、other1.localから遷移する前のECIDで復元されています
ECIDはアクセスするたびに有効期限が延びるため、これでもクロスドメイン対応としては充分な気もします
しかし、できればFPIDを使い永続的にユーザーを識別したいものです
次回に続きます
まとめ
クロスドメイン対応は以下の設定で可能です
DataCollection: Redirect with identity
コード: alloy – appendIdentityToUrl
URLには、adobe_mcパラメタがつき、TS, MCMID,MCORGIDがつきます
重要なのはMCMIDで、この値が遷移先でECIDとして使用されます
おまけ: サブドメインについて
結論から言うと、通常の遷移で問題ありません
遷移先のmain.localのECIDを確認します
ECID: 12441015964298885356786266784487727294

遷移元のsub1.main.local(サブドメイン)で一旦クッキーを全削除します

画面を更新をし、ECIDを確認します
ECID: 63779235042090455392926996351952278274

to_main_domainリンクからmain.localへ遷移します

①ECIDがsub1.main.localと同じであることが確認できます
②また、パラメタにも何も付与されていないことを確認できます
Cookieがドメイン単位、パスは/で作成されるため、自動的にサブドメインは同じECIDが引き継がれます
結果:サブドメインは、特にクロスドメイン対応は不要です












