Expand my Community achievements bar.

Visitor Stitching Should Not Split a Visit

Avatar

Level 5

9/18/12

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

Avatar

Level 9

10/5/12

Seems silly that this issue occurs. Major dislike. Going to cause all sorts of havoc on a very promising feature. This should be a top priority, otherwise people are not going to use the visitor stitching feature.

 

To add on - it'd be great if past visits could be updated via stitching as well. For example:

 

User comes to site, doesn't log in. Is assigned a unique visitorID from SiteCatalyst.

Next week the user comes to the site and logs in and is assigned a visitorID based on their login.

The initial visit data should be stitched to this new visitorID.

Avatar

Level 2

10/9/12

I agree. Visitor stitching still has a long way to go before I would implement it. I doubt there will ever be one single approach that will work for every company, so some level of customization will have to exist at some point. 

 

It seems a website that immediately requires a login would be the strongest candidate for this feature (and even then it's not perfect, because the login screen would have a different s.visitorID value then the rest of the visit).

 

Out of curiousity, how would either of you suggest handling a scenario where multiple users login on the same browser?

Avatar

Level 5

12/12/12

That's where I'm not sure what would happen with visitor stitching.  I'll have to do some testing to see if setting s.visitorID to multiple values treats them as separate visitors.  I still think that the pros outweigh the cons with visitor stitching, but it will result in some inflated visit counts.

Avatar

Level 5

1/31/13

One other HUGE point on this is the Traffic Sources reports.  If I come into the site without ever having logged in, and then I login, the visit gets split, and anything that happens after login will not give credit to the Traffic Sources reports.  The visitor is still considered as the same, so any variable (eVar) that persists longer than a visit will still give credit.  However, I want to expire many of these variables after the visit, and this bug with using visitor stitching causes a pretty big problem.  How can I get more people to upvote this?!

Avatar

Level 5

1/31/13

Ben, you are awesome.  I was just talking you up with some of my colleages, letting them know how great this site is and that you are the person to thank for it.  Awesome!

Avatar

Level 1

1/31/13

Thought it would be a great idea to use the visitorID variable to correlate activity across our website and mobile apps. That is what Omniture recommended, too bad now all my referrer data for any traffic sources is not working correctly because the visit is split. Thought Omniture was ahead of the game when it came to mobile app tracking, but this is a huge flaw and looks like we will have to find another solution.

Avatar

Employee

1/31/13

Out of curiosity, would it be an acceptable solution for SiteCatalyst to "reprocess" your data (for example, at the end of each day) to combine visitor profiles so that these duplicate visits would be resolved? (Note: This means that your visit/visitor counts, and some attribution, would change retroactively, but once complete, the final numbers would be accurate.)