Visitor Stitching Should Not Split a Visit

Avatar

Avatar

adamhaining

Avatar

adamhaining

adamhaining

18-09-2012

SC15 introduced an awesome new feature, visitor stitching.  However, when this is used (setting s.visitorID), it will split the visit when a returning visitor logs in on another device.  If they then return on that same device I think it's working fine, but that initial login is splitting the visit.  This is a big deal and is incorrectly counting visits.  I can try create some calculated metric, but it would be complex and I can almost guarantee the numbers wouldn't be accurate.

 

What should happen is when the visitor first logs in on a new device, and s.visitorID gets set with a new value, it should preserve the visit.  That way pathing and visit numbers would not break mid-visit, and the visitor stitching solution would reach its maximum potential in value.  Until then, it's a nice feature but this one aspect of it is very unattractive.

 

Here was how I found this out.  Another company first reported this to me after I helped implement it.  I created a new report suite, had visitor stitching turned on by Client Care, and then did some testing where I sent data normally without setting s.visitorID.  While that visit was still active, I set a value for s.visitorID.  I waited a day or so, looked at the data, and was able to see that there was a count of 1 visitor and 2 visits.

15 Comments (15 New)
15 Comments

Avatar

Avatar

benjamingaines2

Avatar

benjamingaines2

benjamingaines2

31-01-2013

It is not something that can be done currently, but it is one possible route we are investigating to make this solution work the way you expect it should. There is some reticence due to the concern that business users will lose trust in the data if it changes retroactively (even if it becomes more accurate). But your input helps clarify what we should do. 

Avatar

Avatar

tc75100

Avatar

tc75100

tc75100

31-01-2013

ok, given that it is not yet possible i think that is not an ideal solution because you are right that the data would change. i do not look at my data hourly, but those users who do would probably not like that. 

Avatar

Avatar

adamhaining

Avatar

adamhaining

adamhaining

31-01-2013

I think that's fine, and that can be a caveat to using this.  This feature is awesome in what it does with unique visitor counting and persisting variables that have an expiration greater than a visit across devices, but splitting the visit (and thus visit-based reports) when s.visitorID gets set is a pretty big issue.  Whatever can be done to not split the visit would be great.

Avatar

Avatar

benjamingaines2

Avatar

benjamingaines2

benjamingaines2

31-01-2013

Very helpful feedback, folks. Please share any additional reactions or thoughts. This is one of the top priorities for our platform team, and we want to make absolutely sure to get it right. 

Avatar

Avatar

Matt_Freestone

Employee

Avatar

Matt_Freestone

Employee

Matt_Freestone
Employee

26-10-2018

This idea hasn't been updated in a while, but I thought I'd let you know we are actively working on a cross-device stitching capability that is far more robust than using s.visitorID. It is feature that leverages an integration between Adobe Analytics and the device graph (Co-op or private graph.)

To that end, I wanted to ask a follow up question. Do you store a hashed user id in a prop or eVar? In particular, do you store an ID in a prop or eVar once the user is known (via login or other means.) I'm trying to gauge how common this is.

Thank you.