Under what circumstances would a browser not accept 1st party cookie IDs, but accept third party cookie IDs?

[Yali]

When analysing Snowplow data, it is straigthforward to spot users / browsers that accept 1st party cookie IDs but not third party cookie IDs - we see multiple different values for network_userid for a single value of domain_userid. (In reality it's a new network_userid for every page view.)

On a project for a client recently, however, we spotted the reverse pattern i.e. browsers where for a single network_userid, there were multiple domain_userids. Looking at the data, it was clear that these really were a single user (each page view followed from the next and could be traced back via the referer string, the network_userid, user_fingerprint and user_ipaddress were the same across all the events) but the domain_userid was reset with each page view.

When we looked at our own data from our own website, we saw the same pattern for a small subset of users. So this doesn't appear to be a specific feature of the client website.

Does anyone have any idea what behaviour would drive that pattern? As far as I'm aware, it isn't possible to exclude 1st party cookie IDs but allow 3rd party cookie IDs in the browser. We also noted that this pattern was visible across a number of different browsers. So I'm totally stumped what's driving it...

Any ideas would be much appreciated!

[Simon Rumble]

Hi Yali.

At first I was a bit perplexed but then I realised that your Clojure collector doesn't test to see if the third party cookie has stuck! Lemme guess, lots of mobile and desktop Safari User-Agents doing this?

You can see how I handle this in my private fork of SnowCannon which uses Cloudfront for actual data collection (edited curl output for clarity):

curl -vL 'https://d.aww.com.au/i?foo=bar' 2>&1 >/dev/null |less

> GET /i?foo=bar HTTP/1.1

< Location: /i?redir=1&foo=bar

< P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID PSA OUR IND COM NAV STA"

< Set-Cookie: sc=9a6253b1-1e84-4ff7-b78f-a1c83e7e8e35; expires=Fri, 18 Sep 2015 05:45:56 GMT;

> GET /i?redir=1&foo=bar HTTP/1.1

< Location: https://d1a13ixaual31f.cloudfront.net/i?foo=bar

< P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID PSA OUR IND COM NAV STA"

< Set-Cookie: sc=be804cca-c56e-4eef-95f4-06e0f007c95a; expires=Fri, 18 Sep 2015 05:47:32 GMT;

This commit is where I implement it in the public SnowCannon:
https://github.com/shermozle/SnowCannon/commit/15020bf68bb02d49d34c495926df6e8bfd4f83e9

So the logic is:

• IF (third party cookie received), we're good, record the data with an nuid
• ELSE
• IF (redir=1 in querystring), record the data without an nuid
• ELSE
• Set cookie and redirect back to self  with redir=1 in the querystring

So when there's no third party cookie, we test to see if it sticks.

--
You received this message because you are subscribed to the Google Groups "Snowplow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to snowplow-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Simon Rumble <si...@simonrumble.com>

www.simonrumble.com

[Simon Rumble]

Doh I think I got your query the wrong way around.

My guess would be the domain_userids were set on different domains. is setCookieDomain set with .mydomain.com or similar? Leading dot?

But then again, there are some strange user agents out there. What's the magnitude of this?

[Jethro Nederhof]

We're seeing this on occasion as well. Some notes from looking into it:

• IE's Advanced settings DO let you reject first party cookies while allowing third party ones, though I couldn't get it to work, and most UA's I'm seeing with this behaviour appear to be IE related.
  
• A lot of the referrers I'm seeing are services that host copies of pages under different domains (iframe or fetch pages themselves), eg. Google Images, Google Translate, similarsites.com, so perhaps there's some weird case where setting the cookie to the hardcoded domain makes it unreadable
  
• Quite often it's some kind of bot/crawler; identified clearly in the UA or not. (We have one related to Cloudflare?)
• Then we also have the normal people clearing first party cookies for some reason (we have events that fire when another unrelated cookie is not present, and it fires again when the ID changes)

We're working with this query (probably could be done much better):

SELECT *
FROM events
WHERE collector_tstamp::DATE|| page_urlhost || network_userid IN (SELECT collector_tstamp::DATE|| page_urlhost || network_userid
                                                                  FROM events
                                                                  WHERE network_userid IS NOT NULL
                                                                  AND   collector_tstamp::DATE> '2014-08-01'
                                                                  GROUP BY collector_tstamp::DATE,
                                                                           page_urlhost,
                                                                           network_userid
                                                                  HAVING COUNT(DISTINCT domain_userid) > 1 LIMIT 200)
ORDER BY network_userid,
         page_urlhost,
         collector_tstamp::DATE

Very strange, also interested to hear if anyone else has insight on this.

[Alex Dean]

Thanks for the insights both!

Could this be part of the problem/solution: https://github.com/snowplow/snowplow-javascript-tracker/issues/250

Cheers,

Alex

--

You received this message because you are subscribed to the Google Groups "Snowplow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to snowplow-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Co-founder
Snowplow Analytics
The Roma Building, 32-38 Scrutton Street, London EC2A 4RQ, United Kingdom
+44 (0)203 589 6116
+44 7881 622 925
@alexcrdean

[Fred Blundun]

Hello all,

An update on this: It is indeed being caused by the issue (https://github.com/snowplow/snowplow-javascript-tracker/issues/250) to which Alex linked. This has been fixed in version 2.1.0 which should be released shortly.

If you don't want to wait for 2.1.0, you can manually use the setCookiePath (https://github.com/snowplow/snowplow-javascript-tracker/blob/master/src/js/tracker.js#L1145-L1148) method with the argument "/".

Regards,

Fred