Clarification on _id/visitorid cookie storage and unique visitor reconciliation


#1

Thanks to everyone in advance!

I have dug into these links and various others already just as an FYI
http://piwik.org/faq/how-to/faq_190/
http://forum.piwik.org/read.php?9,112280,112358#msg-112358

We are using the JS tracker and are noticing a massive amount of new visitor ids with the same ip address - which implies that the visitor id cookie is getting reset way before the expiration date (2 years). That said, I have a few questions:

I am trying to understand if this is a standard issue where browsers are deleting tracking cookies or this is a bug?

Should the expectation be that visitor id is fairly ephemeral and you need to rely on additional fingerprinting in order to draw out unique visitors?

In regards to reconciling visitor ids under as a unique visitor, we are looking at ip address+user agent+browser features as a finger print, this seems like the most reasonable way per my results found in this forum?

Thanks again!

Sam


(Matthieu Aubry) #2

Hi Sam, by default PIwik uses the fingerprint as you mention, and it also looks at visitors with the same visitor id.

it may be a bug that you’re seeing lots of same IPs with different visitor ids… is the ID changing rapidly at each pageview? or is the ID changing after few pageviews and some time? not sure how to help, but it would be good to get to the bottom of it :slight_smile:


#3

Hey Matt

So I dug a little deeper and found a few issues:

Case #1 - when you are using google tag manager and there are 2 instantiations of the async tracker, this will create a new sessions. Steps:

  1. goto page with single instantiation
  2. goto page with two instantiations, you will get a new id,ses and ref cookie, on top existing id and ses cookie from first page

Case #2 - if you have multiple domains, for instance www.domain.com and a separate domain for search result pages, like search.domain.com. Steps:

  1. goto page with single instantiation
  2. search for something that posts to search.domain.com which has a single instantiation; you will get a new id,ses and ref cookie, on top existing id and ses cookie from instantiation

Solutions:

Case #1 - So this is obviously a misuse of the tracker, but I would imagine that with the nature of the async tracker install, this would just send down dupe requests, rather than generate a whole new cookie. I am not sure I would call this a bug, but its definitely sucks to deal with. Any thoughts about this?

Case #2 - I should be setting the cookie domain to *.domain.com it looks like via “setCookieDomain( domain )”, is this correct?

Below is a session from a visitor which has same ip/browserfeatures/UA, but different visitor id - you can see the interleaving of the visitor id in the requests. (i anonymized the ipaddresses and urls)


            ip_address            |          user_agent           |    visitor_id    |      timestamp      |               url                
----------------------------------+-------------------------------+------------------+---------------------+----------------------------------
 2b50b93d50985146db80955cced4cc3a | Mozilla/5.0 (Windows NT 6.3;  | 2c52efd38b2b532d | 2014-10-01 17:41:12 | 935eb33b6ae35739d8c567e3dbc50c03
 2b50b93d50985146db80955cced4cc3a | Mozilla/5.0 (Windows NT 6.3;  | b1e29153878919ef | 2014-10-01 17:41:07 | edcd3df61693f88802c8baafa29c5fb1
 2b50b93d50985146db80955cced4cc3a | Mozilla/5.0 (Windows NT 6.3;  | 2c52efd38b2b532d | 2014-10-01 17:40:10 | 935eb33b6ae35739d8c567e3dbc50c03
 2b50b93d50985146db80955cced4cc3a | Mozilla/5.0 (Windows NT 6.3;  | b1e29153878919ef | 2014-10-01 17:39:33 | 87cf6dea8353e6daca8ff7c74da4f4c1
 2b50b93d50985146db80955cced4cc3a | Mozilla/5.0 (Windows NT 6.3;  | b1e29153878919ef | 2014-10-01 17:37:56 | b263b51745b7c9ba52c0a8d2754f853f
 2b50b93d50985146db80955cced4cc3a | Mozilla/5.0 (Windows NT 6.3;  | 2c52efd38b2b532d | 2014-10-01 17:36:14 | 4967a4286cc6507a358b5fd55ca66026
 2b50b93d50985146db80955cced4cc3a | Mozilla/5.0 (Windows NT 6.3;  | b1e29153878919ef | 2014-10-01 17:35:26 | b263b51745b7c9ba52c0a8d2754f853f
 2b50b93d50985146db80955cced4cc3a | Mozilla/5.0 (Windows NT 6.3;  | 2c52efd38b2b532d | 2014-10-01 17:35:11 | 4967a4286cc6507a358b5fd55ca66026
 2b50b93d50985146db80955cced4cc3a | Mozilla/5.0 (Windows NT 6.3;  | b1e29153878919ef | 2014-10-01 17:33:11 | 87cf6dea8353e6daca8ff7c74da4f4c1
 2b50b93d50985146db80955cced4cc3a | Mozilla/5.0 (Windows NT 6.3;  | b1e29153878919ef | 2014-10-01 17:32:25 | 4ccfb44a02811c369ee21af9092a35a4


(Matthieu Aubry) #4

Case #1 - So this is obviously a misuse of the tracker, but I would imagine that with the nature of the async tracker install, this would just send down dupe requests, rather than generate a whole new cookie. I am not sure I would call this a bug, but its definitely sucks to deal with. Any thoughts about this?

Would you mind creating a bug report in Github for this case? Issues · matomo-org/piwik · GitHub
if you can paste the code used to reproduce the issue and also the result you got VS what you expected.
We’ll investigate!

Case #2 - I should be setting the cookie domain to *.domain.com it looks like via “setCookieDomain( domain )”, is this correct?

Yes this should help!