Visitor Stitching Should Not Split a Visit

[#1]

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.

[#2]

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. 

[#3]

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. 

[#4]

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.

[#5]

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. 

[#6]

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.