First party cookie / Cloudfront CNAME - setup check

For engineers Collectors
1

Hi there,

I know its deprecated however we are using the cloudfront collector with javascript tracker 2.12.0 and hoping someone can help with this question.

I want to make sure our tracking is considered first party server side, so cookies do not expire after 7 days.

To do this, we setup a CNAME record for the collector URL, so that the collector URL has the same domain as the websites that we are tracking.

e.g. If our website is mydomaingoeshere.com.au, then we setup a CNAME record of c.mydomaingoeshere.com.au

The snowplow tag is then updated so the CNAME is the collector URL

<!-- Snowplow starts plowing -->
<script type="text/javascript">
;(function(p,l,o,w,i,n,g){if(!p[i]){p.GlobalSnowplowNamespace=p.GlobalSnowplowNamespace||[];
p.GlobalSnowplowNamespace.push(i);p[i]=function(){(p[i].q=p[i].q||[]).push(arguments)
};p[i].q=p[i].q||[];n=l.createElement(o);g=l.getElementsByTagName(o)[0];n.async=1;
n.src=w;g.parentNode.insertBefore(n,g)}}(window,document,"script","//d1vq1pwo3xhu9o.cloudfront.net/2.12.0/sp.js","snowplow"));

window.snowplow('newTracker', 'cf', 'c.mydomaingoeshere.com.au', { // Initialise a tracker
  appId: '{{Snowplow App ID}}',
  eventMethod:'get',
  contexts: {
  	optimizelyXSummary: true,
    webPage: true
  }

});

Events are successfully being collected and making it through to Snowflake DW

The thing that is confusing me, is when I look in browser developer console > network, I can see records such as this that are showing the domain is the expected CNAME domain

image

But for the network name of “sp.js”, it appears as the cloudfront URL that points to the S3 hosted sp.js file.

image

This makes sense because in the Snowplow Tag that is where we are saying the sp.js file exists.

But does this mean that it still is not considered first party server side? Do we also need to setup CNAME records for the cloudfront url that points to sp.js file? I’m concerned I’ve missed something in the required setup

I’ve trawled the documentation and forums and can’t find anything that helps me clearly understand this, so have obviously missed something. Would appreciate you helping me to understand.

Thanks,
Ryan

2

It shouldn’t matter too much where you load sp.js if you are setting cookies on a first party domain. The larger concern may be that the Cloudfront collector doesn’t set any SameSite cookie attributes which is something you should ideally be setting (depending on your use case) that is supported by the Scala collector.

3

As @mike suggests, that should be fine for now and your tracking is first party. Where sp.js loads from doesn’t impact that, only where the /i and /tp2 requests are sent. However it likely won’t be a reliable solution for long due to browsers clamping down on cookies which don’t have the SameSite attribute.

A couple of things you would likely benefit from:

  1. Upgrade your JS tracker to v2.17.3 so the JS set cookies (domain_userid) have the SameSite attribute
  2. Rename sp.js in your S3 bucket to something random (then the file won’t be blocked by ad blockers)
  3. Look at how you can upgrade to the Stream Collector - You might find this helpful AWS batch pipeline to real-time pipeline upgrade guide
  4. A little more advanced but a good tip once you’ve upgraded, consider switching to POST requests and creating a custom POST Path for your collector (again, helpful for avoid your data collection being swatted by Ad Blockers).
1 Like
4

Thanks for the information @mike and @PaulBoocock.

@PaulBoocock to make sure I am understanding correctly, could you please confirm the following?

  • JS tracker V2.17.3 is compatible with the deprecated Cloudfront collector
  • This will enable us to set cookieSameSite: ‘None; Secure’ , which will work with the Cloudfront collector

Just a bit confused because the info from @mike signals that this won’t work, and the last sentence on this page also signals that it won’t work? -Understanding the SameSite Cookie update | Snowplow

Noted on upgrading to the Stream collector as a better option, just hoping there is something we can implement for the Cloudfront collector in the interim.

5

Sorry for the confusion. Yes, v2.17.3 is compatible. In fact, even v3 is compatible as we haven’t changed the underlying tracker protocol.

A typical Snowplow setup has three cookies, 1 which the collector sets and 2 which the JavaScript tracker sets.

The collector set cookie, _sp, is what is used to populate the network_userid field in each event. This is where you are limited with the Cloudfront Collector → switching to the Stream Collector is the way to utilise this cookie going forward. It’s very reliable and can live for up to 2 years in a correctly configured, first party collection set up.

The two tracker based cookies, _id_ and _ses_, are used to populate the domain_userid and other domain_* session properties on an event.

If you upgrade to JS Tracker v2.17.3 (or make the leap to v3!), then the two tracker cookies will have the SameSite and Secure attributes (and can be configured too). The tracker set cookies are good for at least 7 days (where browsers such as Safari will clear them, but Chrome lets them live longer).

This is an interesting blog post on configuring collectors and trackers. I’m quite a fan of the flow chart for Open Source.

6

Great information thanks.

Just to clarify, even if we have our Cloudfront collector on the same domain, upgrade to JS tracker 2.17.3 and set appropriate same site and secure attributes, Safari would still expire user identification after 7 days because the Cloudfront collector is not capable of setting the cookie that populates network_user_id?

network_user_id appears as blank in our data so this makes sense, but I was hoping that by making these changes, the domain_userid that is currently being set, would also not be reset after 7 days by Safari?

7

The Cloudfront Collector doesn’t support setting the _sp cookie at all, so your network_userid will always be blank unless you upgrade to the stream collector. Sorry for any confusion there.

Your best option is to upgrade to JS 2.17.3 and use the domain_userid which will be limited to 7 days in Safari. There is no relationship between the collector and the cookie which sets the domain_userid field as it is purely set by the tracker. However, you need to upgrade to JS 2.17.3 so even this cookie doesn’t start getting rejected in future browser releases once SameSite becomes enforced.

There is no workaround for Safari to support user identifiers beyond 7 days unless you are using the Stream Collector on a “first-party domain” and are setting the SameSite attribute on it.

1 Like
8

@PaulBoocock this is really useful information and has helped greatly, much thanks.

1 Like