We have migrated from client side adobe solutions (App Measurement, Experience Cloud ID ) to Adobe WebSDK setup. In old appmeasurment extension, we have enabled the option to store the AAM cookie to a first party cookie with UUID returned from AAM.
Since the VisitorAPI.js service (Experience Cloud ID extension) is disabled in launch now, we do not have the demdex third party cookie or the first party UUID cookie present in current WebSDK pages.
We need help to know, how to retrieve the UUID first party cookie with WebSDK setup, so we can pass it to an adobe analytics eVar.
Appreciate if anyone can assist.
Thanks
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hello @Santhosh_M ,
With the move to Adobe WebSDK, you’ll primarily use ECID (Experience Cloud ID) instead of the previously stored UUID in the VisitorAPI.js setup. WebSDK uses ECID as the default unique identifier across Adobe products, providing consistent cross-solution tracking.
I saw the Challenges with Historical Data during this transformation. If your previous data collected with UUID and new with ECID. WebSDK does not automatically sync historical UUID data with ECID. Therefore, existing segments or data relying on the UUID will not directly align with new ECID-based data.
If possible, pass both the UUID (if still available) and the new ECID during a transition period. This allows time to collect both identifiers, making it easier to map or link historical data to new sessions.
If historical continuity is critical, consider mapping UUIDs to ECIDs in your data warehouse, allowing you to link past data to the new identifiers. This can be complex and may require support from Adobe Consulting Services to develop a custom solution.
Kr,
Parvesh
@Parvesh_Parmar @arpan-garg would you please take a moment to review this question? We would be grateful for any wisdom you could share on this question.
Views
Replies
Total Likes
Hello @Santhosh_M ,
With the move to Adobe WebSDK, you’ll primarily use ECID (Experience Cloud ID) instead of the previously stored UUID in the VisitorAPI.js setup. WebSDK uses ECID as the default unique identifier across Adobe products, providing consistent cross-solution tracking.
I saw the Challenges with Historical Data during this transformation. If your previous data collected with UUID and new with ECID. WebSDK does not automatically sync historical UUID data with ECID. Therefore, existing segments or data relying on the UUID will not directly align with new ECID-based data.
If possible, pass both the UUID (if still available) and the new ECID during a transition period. This allows time to collect both identifiers, making it easier to map or link historical data to new sessions.
If historical continuity is critical, consider mapping UUIDs to ECIDs in your data warehouse, allowing you to link past data to the new identifiers. This can be complex and may require support from Adobe Consulting Services to develop a custom solution.
Kr,
Parvesh