Snowplow JavaScript Trackers v3.9.0 released

Snowplow JavaScript Trackers v3.9.0 released

We are pleased to announce version 3.9.0 of the Snowplow JavaScript Trackers!

Version 3.9.0

Fixes and new features in this release!

In this release we added a new built-in context you can track, the browser_context, which includes helpful browser information such as the visitor’s device memory, if the user-agent is controlled by automation, a unique browser tab identifier and more.

Additionally we added the capability to track ecommerce promotional content to our snowplow-ecommerce plugin. You can see more instructions and how we approach ecommerce tracking as a whole by going through the ecommerce accelerator.

Finally our page ping trigger algorithm now includes touch-type events, which make the calculation much more realistic, especially for mobile devices.

You can see the whole list of features and fixes below:


New features

  • Add touch screen events on page pings calculation #479.
  • Add capability to attach already existing Youtube iframes on video tracking #1141.
  • Add a new browser context. Available with the contexts: { browser: true } option #1142. (Take a look at the new schema!)
  • Add a tab identifying attribute #815.
  • Ability to track ecommerce promotions #1157.
  • Add client_session context entity if anonymous tracking with session tracking is enabled #1124.

Bug fixes

  • Add missing files attribute on JS tracker #1146.
  • Fix generating domain user ID when clearing user data with anonymous tracking #1164.
  • Make sure arrays retrieved from browser APIs are serialized as arrays in context entities #1082.


  • NPM README descriptions for snowplow-ecommerce and enhanced-consent plugins #1148.
  • Fix top level domain grouping initial cookie set attempt #1162.


Version 3.9.0 is available as @snowplow/browser-tracker on npm, or as the tag based javascript tracker - available on GitHub Releases, jsDelivr or unpkg.


Hi Peter,

some (longer) awaited fixes and features in this release - thanks! Questions regarding the new browser_context:

Is it correct that viewport, documentSize and colorDepth are already covered via atomic columns? If so, activating the context would result in redundant columns?

  • Is „viewport“: atomic properties dvce_screenheight / dvce_screenwidth?
  • Is „documentSize“: atomic properties doc_width / doc_height ?
  • colorDepth: atomic property: br_colordepth?

Hey @davidher_mann , good question!

You are correct, some of the values on the browser_context are already covered in the atomic columns and for those columns, the values will be the same as the ones in the browser_context.
The browser_context is currently opt-in and does not replace the atomic values, so yes there would be some duplicate information.

The discussion we are having internally is whether we could deprecate atomic values at some point which would be better fitting in a context (such as the browser_context).

Hi Peter,

thanks for the explanation. I understand that it’s hard to deprecate atomic columns and I like the idea of less atomic columns. But from my point of view, adding redundancy doesn’t feels like a good approach.

The recently introduced web contexts (client_session and browser_context) both adding plenty of redundant columns. I would really appreciate and opt-in / opt-out mechanism per property for these contexts. Would that be possible?

Kind regards.

Thanks for the feedback David, really helpful!
I will make sure we discuss that internally and if we have any proposed actions, we will get back to you!