WebSDK migration - Analytics data | Community
Skip to main content
Level 4
January 15, 2024
Solved

WebSDK migration - Analytics data

  • January 15, 2024
  • 3 replies
  • 1398 views

I wanted to know, Based on what parameters , we can really check to know if there there are any discrepancy before Analytics data WebSDK migration.

Since, it differs from image request does the way of  calculation Visits change and are there  any threshold limits for visits and UV while comparing?

Thanks!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by leocwlau

As mentioned by @abhinavbalooni, they are just different approaches to data collection. You may think about the existing AppMeasurement and new WebSDK tracking is taking mass transit or driving to the office.

Most of the analytics data should not be impacted, and calculations happening on the AA side, such as visit definition, should not impacted. However, there may be some minor differences you need to be aware of by referring to Variables, functions, methods, and plug-ins overview | Adobe Analytics which documented AppMeasurement and WebSDK approach of data collection.

Some features may be missing in the WebSDK, such as offline tracking and also Activity Map which was only added into WebSDK on Mar-2023. some features may be implemented differently, such as there is no dynamic in WebSDK but need to implement that in Datatream to map incoming data to different AA dimension

3 replies

abhinavbalooni
Community Advisor
Community Advisor
January 15, 2024

Hey @aepaa 

 

The metrics remain the same if you are looking at Adobe Analytics. The way to identify the user is still based on ECID so your visits and unique visitors and other metrics aren't impacted. One thing that you would have to be mindful of, is ticking the checkbox which says migrate ecids from app measurement in web sdk extension. This will ensure that when an existing user loads your site, web sdk takes into account the already existing ecid and does not generate a new one for the user.

 

The thing that changes is the approach of collecting the data. Earlier, you would have different libraries for different tools, like App Measurement for Analytics, at.js for Target etc which would in turn trigger respective 'image request'. With web sdk, you still get one 'image request' which is your 'interact' network call which uses data streams to send out data to different services like Analytics, Target, AEP and other tools through event forwarding.

 

As you can see above, there is a difference in the way you are collecting the data but the data metrics and ways of identifying the user remains the same.

 

I have assumed when you are referring to Analytics, it is Adobe Analytics and not CJA which is works in a different manner.

 

Cheers,

Abhinav

leocwlau
Community Advisor and Adobe Champion
leocwlauCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
January 16, 2024

As mentioned by @abhinavbalooni, they are just different approaches to data collection. You may think about the existing AppMeasurement and new WebSDK tracking is taking mass transit or driving to the office.

Most of the analytics data should not be impacted, and calculations happening on the AA side, such as visit definition, should not impacted. However, there may be some minor differences you need to be aware of by referring to Variables, functions, methods, and plug-ins overview | Adobe Analytics which documented AppMeasurement and WebSDK approach of data collection.

Some features may be missing in the WebSDK, such as offline tracking and also Activity Map which was only added into WebSDK on Mar-2023. some features may be implemented differently, such as there is no dynamic in WebSDK but need to implement that in Datatream to map incoming data to different AA dimension

Level 3
March 8, 2024

When we migrated we set up a test WebSDK reportsuite and had our AppMeasurement code continue to publish to the production reportsuite and have the WebSDK publish to the test WebSDK reportsuite.  We let it run until we had a full day of data and turned off the WebSDK data send while we validated data between the two reportsuites.  We were able to find some defects and fix them in the WebSDK.  Once we were confident that we had the WebSDK sending data properly we turned off the AppMeasurement code and turned on the WebSDK datastream to production. 

 

Something to keep in mind is that the datastream change is instantaneous and does not require a code release.

New Member
October 24, 2024

How close was your data from the test report suite to production in that 1 day span?