We have enabled A4T and our target activities are appearing in Analytics but we see sometimes the Analytics data does not get attributed to Target Activity. After investigation, we found that the SDID should always be same on Target Delivery call and Analytics call but we can observe it is not matching sometimes and may be that is the reasons behind missing data.
We have made sure the ORG IDs are same in both Target and Analytics, also using appropriate versions of Appeasement and AT.JS. We also explored whether this could be a sequencing issue but the Sequence of execution is always Visitor ID --> AT.JS --> App Measurement.
Is there anything I can do to investigate why SDIDs are not matching sometimes? Also I would like to understand how exactly SDIDs are set and then passed to Analytics calls and its correct behavior.
One more observation as I am not sure if this is correct behavior or not. In scenarios where SDIDs are matching, I can see it is matching for only first analytics pageload call where target activity is appearing, any subsequent Analytics calls including non-pageload have different SDID and it is different for each analytics call even though the click is not redirecting to different page. Is it expected?
Solved! Go to Solution.
Views
Replies
Total Likes
hi @SanketDe
You use adobe experience platform debugger to check sdid stitching. open network requests then target and network requests to analytics and verify that the target call contains a supplemental data id and the analytics call contains the same sdid.
https://experienceleague.adobe.com/en/docs/target/using/integrate/a4t/troubleshoot-a4t/a4t-troublesh...
pls visit n/w tab to see the experience cloud visitor id service (visitorapi.js) loads first and before at.js and before analytics (appmeasurement.js).. this order is required for sdid generation.
https://experienceleague.adobe.com/en/docs/target/using/integrate/a4t/before-implement
as mentioned in at.js 1.x, target sends mboxMCSDID and analytics sends sdid.
in at.js 2.x, target returns experiencecloud.analytics.supplementaldataid in the response header and analytics still includes sdid.
https://experienceleague.adobe.com/en/docs/target/using/integrate/a4t/a4timplementation
if sdids do not match (or are missing), A4T stitching fails and analytics will not attribute the hit to the target activity. this is the main cause of missing A4T data. Pls refer to this-
https://experienceleague.adobe.com/en/docs/target/using/integrate/a4t/troubleshoot-a4t/a4t-troublesh...
Views
Replies
Total Likes
hi @SanketDe
You use adobe experience platform debugger to check sdid stitching. open network requests then target and network requests to analytics and verify that the target call contains a supplemental data id and the analytics call contains the same sdid.
https://experienceleague.adobe.com/en/docs/target/using/integrate/a4t/troubleshoot-a4t/a4t-troublesh...
pls visit n/w tab to see the experience cloud visitor id service (visitorapi.js) loads first and before at.js and before analytics (appmeasurement.js).. this order is required for sdid generation.
https://experienceleague.adobe.com/en/docs/target/using/integrate/a4t/before-implement
as mentioned in at.js 1.x, target sends mboxMCSDID and analytics sends sdid.
in at.js 2.x, target returns experiencecloud.analytics.supplementaldataid in the response header and analytics still includes sdid.
https://experienceleague.adobe.com/en/docs/target/using/integrate/a4t/a4timplementation
if sdids do not match (or are missing), A4T stitching fails and analytics will not attribute the hit to the target activity. this is the main cause of missing A4T data. Pls refer to this-
https://experienceleague.adobe.com/en/docs/target/using/integrate/a4t/troubleshoot-a4t/a4t-troublesh...
Views
Replies
Total Likes