Effective visitor ID (s.visitorID vs mid)

[#1]

How does Adobe Analytics cope with unauthenticated and authenticated server calls within a session and over different sessions?

For this particular case I'd like to know what happens when setting s.visitorID variable (enabling vid parameter) and what Adobe Analytics counts as a unique visitor when s.visitorID cannot be set and Adobe falls back to mid as the identifier.

From this page it is pretty clear the within a session unauthenticated hits and subsequent authenticated hits are counted as two different sessions and unique vistiors:

https://marketing.adobe.com/resources/help/en_US/sc/implement/variable_persistence.html

"When an un-authenticated customer first arrives at your site, that customer is assigned a visitor profile by Adobe Analytics. As shown in Unique Visitor and Visits Counts, on authentication a new profile is created. When the new profile is created, one visit ends and another visit starts."

Example Visit

Following the "example visit" link is a little bit confusing since the authenticated hits from the laptop (last two rows in the table) are added up (9) to the number of visits from the unauthenticated visit hits (8). What happens here?

And how is setting s.visitorID variable different from using the 'unique visitor variable' option in UI where you can set it to an evar? Also when this evar is set to 'never expire' will this tie unauthenticated hits back to the same user ID once the evar is collected in a hit?

Thank already.

[#2 · Accepted solution]

Yes, and that's one of the reasons why I wouldn't recommend using this cross-device visitor identification with Experience Cloud ID service. If you're not already using manual s.visitorID's, it can wreak havoc on your unique visitor count. You'd want to fully invest in using your own identification methods (s.visitorID), which means you're not getting any value out of the ID service, which will have an increasingly vital role as new features are released for both Analytics and the Experience Cloud as a whole.

The bottom line is that on the first hit you are able to match up s.visitorID with one that already exists, it gets matched up with prior visits and you can track actions across devices. The issue is that the hits leading up the authenticated hit are orphaned, meaning that those hits artificially inflate unique visitors/visits (since it was using a completely separate visitor identifier).

[#3]

Whenever a user goes to your site from a new device, a new profile is created. Once they log in and it recognizes them, from that hit onward is matched up with the existing profile. The bad news is that the unauthenticated hits leading up to that are kinda "orphaned". The good news is that even if the user logs out on that new device, they'll still match up to the profile (at least until they clear cookies).

[#4]

I am not sure if I completely follow. So from the example visit page the marketing email click that led to the first server call will also be tied to server call 9 and 10 where CID1 is the effictive visitor ID (and when this is CID1's first hit ever)?

And if server call 11 was generated using Natural Search for instance, server call 12 will not have this information since it is not CID1's first hit ever and therefore continues from known CID1 profile and will be reported as Direct, correct?

I also found a similar thread about this:

How track cross-device

"If someone comes to your site unauthenticated (MCID) and then you switch them to s.visitorID once they log in, they will appear as a new visitor at that point ...

Nuanced:  .... unless it is the first hit for this particular s.visitorID ever, then it will match up with existing profile of that visit.

[#5]

Thanks for the update.

In the mean time I also opened a discussion about this on #measure slack channel. And I am not sure if the Example Visit page represents the real story of what happens when using the s.visitorId variable (authenticated hits). From the discussion on slack I understood that whenever mid-visit the s.visitorID method is introduced it creates a new visitor profile. And so, nothing will be copied from the previous hits (ie. ECID hits) in that same (browser) 'session'. From this I would expect a new visit number and new hits for a new visitor profile of server call 9 and 10 on the Example visit page. The example now implies that for the authenticated hits (server call 9 and 10) evars (long expiry), tracking codes or channels would be copied to the new visitor profile (CID1). If this is the case then I am still confused.

And really really looking forward to improvements on this. I will definitely stay tuned

[#6]

The example visit page was recently updated: Example visit

The current version of cross-device visitor identification leaves a lot to be desired. In 2019 Adobe plans to make significant improvements to how visitors are calculated across devices. Stay tuned!

Does the updated visit example make more sense?