Adobe Analytics through Web SDK: Phase wise migration across Sub-domains

Question

Hello Experts,

Hope everyone is doing well!

We are inching forward to finalize a plan for Web SDK migration for data collection into Adobe Analytics. I would like seek help in evaluating the below scenario and its technical implications with Web SDK:

Scenario:

Assume that our site has several sub-domains (for various business segments/units) like below:

user.business.com
customer.business.com
success.business.com
investors.business.com

Currently, Adobe Analytics has been deployed on these sub-domains, either through Launch or AppMeasurement JS was embedded directly via custom code. Our data collection and reporting is running at business-as-usual fashion.

In case we start migrating to AEP Web SDK with one sub-domain (say, user.business.com) and go one-by-one to migrate all sub-domains:

Will the functionality of identifying a Visitor (could be our existing Customer or a Prospect) be same? While they hop on and off over multiple sub-domains in a single site Visit.
The reason I ask above question is, at this moment AppMeasurement JS is setting or maintaining ECID for all sub-domains. If we migrate user.business.com to Web SDK, the ECID would likely be set through Alloy.js and other sub-domains would be setting ECID through AppMeasurement JS. In this scenario, both the JS libraries should work in tandem, to make sure Visit identification and Web analytics metrics work consistently.
In case both the JS libraries work differently in terms of Visitor identification, what would be the impact on analytics data collection on a few sub-domains with AppMeasurement JS and a few with Alloy.js?

Please feel free to share your thoughts, this would likely be a case for most of the businesses. So, it's essential to deep-dive into this scenario.

Thank you,

Kishore

evidana · Accepted Answer

We had this same concern. Started with AEP at the bottom of the page so we could make sure that events started flowing into AEP and that a unique visitor spike wasn't to be experienced. It seems like alloy will not try and generate a a new ecid if it sees that the cookies are already on the page. This works in vice versa as well. If you load alloy before visitor api, it should abort the network call and use the session generated from alloy. I thought these resources were good for walking me through the transition:

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-platform-blogs/ecid-migration-with-aep-web-sdk/ba-p/423234

https://experienceleague.adobe.com/docs/experience-platform/edge/identity/overview.html?lang=en

Would pay close attention to the idmigrationenabled flag. Good luck!

gchung · Answer

Make sure to enable “Migrate ECID from VisitorAPI to Alloy to prevent visitor cliffing” as part of your Web SDK (alloy.js) configuration. This will check the AMCV cookies from ECID service before requesting new ECIDs.

That being said, please do you own testing.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded