Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

A4T Mismatched SDID (Target vs Analytics Calls)


Level 1

Hi All, 


First post, hoping someone might be able to clear up my confusion.  Thanks in advance!



I have a client who implemented code outside of Launch to append cross-domain links with MCID/SDID.  However, I found an issue with their code which causes "SDID" to not match between the /delivery POST reqeusts for target, and the b/ss GET calls for analytics.


I see in documentation it says they 'must' match, but I'm quite confused because A4T reporting inside Workspace still appears to work. (


EDIT: To add if it matters, the "ECID" value does match for /delivery and b/ss tracking calls.

My questions:

What exactly does this break if I can see the data in Workspace and also the "reports" tab in Target?


While we already have a fix getting tested now that will solve this mis-match, how can we interpret the data already collected?  Is A4T in Workspace not going to know which experience was served?  Or what side-effect(s) can be explained?

1 Reply


Level 4

Let's clarify some concept (Analytics and Target reports are not same)

  • Target reports gives you the data based experience deliver to destination pages (Not rendered experienced). If multiple campaign qualified for same placement with same priority Target will deliver both campaigns to the page and Page script will render one campaign randomly.
  • SDID (tnta in mobile apps) on the other hand based on campaign rendition. Data collected via the analytics will inform analytics to forward the data to Target. This way Analytics will be added forward to target for reporting

if you implement the SDID/tnta it will make the A4T works better; but there will be always some differences due to delivery approach vs rendering approach