Skip to main content
adamhaining
Level 3
September 18, 2012
Investigating

Visitor Stitching Should Not Split a Visit

  • September 18, 2012
  • 15 replies
  • 14132 views

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 replies

adamhaining
Level 3
January 31, 2013

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?!

adamhaining
Level 3
December 12, 2012

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.

Level 2
October 9, 2012

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?

adamhaining
Level 3
October 5, 2012

Eric hit it on the head.

ericmatisoff1
Level 5
October 5, 2012

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.