Hi @RJBu
Indeed it’s great question … I was also looking in past about info related to SDID .. here is the past thread.
later I understood how it’s happened
SDID (Supplemental Data ID) is key which enables stitching between the Target request and the Analytics hit in A4T. It essentially links those two calls so they’re treated as part of the same interaction in reporting.
https://experienceleague.adobe.com/en/docs/target/using/integrate/a4t/before-implement#section_2C1F745A2B7D41FE9E30915539226E3A
Does the Visitor API initialization instantiate the SDID?
Not directly - rather it enables it. The SDID parameter is generated in the ID services payload. Reference link https://experienceleague.adobe.com/en/docs/id-service/using/implementation/ecid-a4t-target#section-4b5631a0d75a41febd6f43f8c214c263
https://www.npmjs.com/package/@adobe-mcid/visitor-js-server
SDID is generated per request / per interaction. Each Target + Analytics pair gets its own SDID and it’s for limited time. Read about
appendSupplementalDataIDTo
More Info here - https://experienceleague.adobe.com/en/docs/id-service/using/id-service-api/methods/appendsupplementaldataidto#section-99946715cefa4acc95200b093db5297e
Does it ultimately matter if/when/how the mbox calls are execute on the page in relation to SDID initialization ?
Yes, this is critical.
For stitching to work correctly:
- Target and Analytics calls must share the same SDID
- They need to happen within the same execution flow
In practice:
- Visitor API should load first
- Then Target call
- Then Analytics beacon
If they fire out of sync or too far apart, they can end up with different SDIDs and therefore no stitching.
Are the SDID sets 1:1 or many:many
- SDID is 1:1 per interaction (hit-level)
- A single visitor (ECID) will have many SDIDs over time
So we can say one ECID has many SDIDs and its stitched Target + Analytics together.
Hope this helps.
Thank you,