Expand my Community achievements bar.

Attention: Experience League Community will undergo scheduled maintenance on Tuesday, August 20th between 10-11 PM PDT. During this time, the Community and its content will not be accessible. We apologize for any inconvenience this may cause.
SOLVED

Cross-Domain, MCID VS VID

Avatar

Level 1

I have some cross-domain issues..

We have website A and website B.
We tried the "Visitor.appendVisitorIDsTo" to give the informations to website B but it's not working. Website B create is own MCID even if the adobe_mc param is in the url. 


So now we're trying to force MCID from website A into VID of website B. (we have the info in the url from the appendVisitor.. function).

So at the end, when looking at the AAID priority they both should have the same value no?
https://experienceleague.adobe.com/en/docs/id-service/using/reference/analytics-reference/analytics-...

Website A : MCID = 123, VID = null/blank -> AAID should be 123?
Website B : MCID = 456, VID = 123 -> AAID should be 123?

In workspace they count as 2 visitors, and in the datafeed, they have different visid high/low values. 
visid_type is 5 for both when it should be 0 for Website B since VID as a value (post_cust_visid is not blank in the datafeed)

visid_typeNot for external use; internally used by Adobe for processing optimizations. A numeric ID that represents the method used to identify the visitor.
0: Custom visitor ID or Unknown/not applicable
1: IP and user agent fallback
2: HTTP Mobile Subscriber Header
3: Legacy cookie value (s_vi)
4: Fallback cookie value (s_fid)
5: Identity Service
cust_visidThe custom visitor ID, if set using visitorID.

https://experienceleague.adobe.com/en/docs/analytics/export/analytics-data-feed/data-feed-contents/d...

Anyone can tell me what im missing here? How did you guys managed to make your cross-domain work?

Thanks


 

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

First off, I don't think this is correct:

 

Website A : MCID = 123, VID = null/blank -> AAID should be 123?

 

The AAID is the the back-end identifier, this used to match the old s_vi cookie, back when there was no cross domain considerations. This is represented in the Raw Data as post_visid_high / post_visid_low, and I have never seen those match an ECID... but I don't use the Raw Data much (that's more our data engineering team).

 

I am also not sure that vid takes precedence over s_vi any more.. that's such an old concept, where the cookie is unique to the domain, I feel that would have more tendency to break cross domain implementations now.... as for VID versus ECID, I would still think that ECID would be used... again, I could be wrong, I've never passed both a VID and an ECID.. the only place I use VID is on our AMP pages (and I pass the AMP Id generated by Google.... that information gets mapped to a proper post_visid_high / post_visid_low designation in the Adobe backend, it doesn't use it directly as far as I am aware....

 

 

Now, to the cross domain issue... I don't actually use the Visitor.appendVisitorIDsTo function, since we have so little "direct between sites" traffic. When I open an incognito window and load "site a" in one tab, and 'site b" in another tab, and 'site c" in yet another tab, and check the ECIDs, they all match for me (granted this is in a single session), and I can see much cross over traffic between sites in our real data, maybe not everything... I assume Safari ITP isn't playing nicely...

 

 

Have you considered just trying to check the s_ecid cookie? Before tracking happens, look at the ECID cookie set and look at the value passed in the URL.. if they don't match, update the cookie with the passed value... then let your tracking fire?

 

 

View solution in original post

3 Replies

Avatar

Correct answer by
Community Advisor

First off, I don't think this is correct:

 

Website A : MCID = 123, VID = null/blank -> AAID should be 123?

 

The AAID is the the back-end identifier, this used to match the old s_vi cookie, back when there was no cross domain considerations. This is represented in the Raw Data as post_visid_high / post_visid_low, and I have never seen those match an ECID... but I don't use the Raw Data much (that's more our data engineering team).

 

I am also not sure that vid takes precedence over s_vi any more.. that's such an old concept, where the cookie is unique to the domain, I feel that would have more tendency to break cross domain implementations now.... as for VID versus ECID, I would still think that ECID would be used... again, I could be wrong, I've never passed both a VID and an ECID.. the only place I use VID is on our AMP pages (and I pass the AMP Id generated by Google.... that information gets mapped to a proper post_visid_high / post_visid_low designation in the Adobe backend, it doesn't use it directly as far as I am aware....

 

 

Now, to the cross domain issue... I don't actually use the Visitor.appendVisitorIDsTo function, since we have so little "direct between sites" traffic. When I open an incognito window and load "site a" in one tab, and 'site b" in another tab, and 'site c" in yet another tab, and check the ECIDs, they all match for me (granted this is in a single session), and I can see much cross over traffic between sites in our real data, maybe not everything... I assume Safari ITP isn't playing nicely...

 

 

Have you considered just trying to check the s_ecid cookie? Before tracking happens, look at the ECID cookie set and look at the value passed in the URL.. if they don't match, update the cookie with the passed value... then let your tracking fire?

 

 

Avatar

Level 1

I tried to manually update the AMCV cookie and fire a hit, it seems to work! 

Thanks for you help, it seems i was making this hard for no reason  

Avatar

Community Advisor

Lol, you're welcome... I figured trying to manipulate the cookie might be easier

 

Update: Yeah, sometimes it just takes a second pair of eyes... it can be so easy to start down one line of thinking (like trying to send a custom VID) to miss potential alternates (we've all been there)