In addition, we have rolled out support for Enhanced Ecommerce tracking, improved domain management and better handling of time! Read on to find out more…
- Optimizely integration
- Augur.io integration
- Enhanced Ecommerce tracking
- Better automatic domain management (for cookies) and other new functionality
- Improved handling of time
- Updates and Bug fixes
- Documentation and help
1. Optimizely integration
The Optimizely integration delivers your Optimizely testing data with each event tracked in Snowplow, making it easy to identify:
- Whether an experiment was running when the event was recorded
- If so, which variation the user is exposed to
- All the relevant metadata associated with the experiment (and any others that are running)
It is very common for Snowplow users to track A/B testing data in Snowplow. This means you can assess the effectiveness of different experiments directly by analyzing your Snowplow data. This is enormously valuable, as it means you can not only measure the impact of individaul experiments, but slice results by any of the myriad dimensions that Snowplow makes available to you. (Including any that you build yourself on the event-level data, e.g. behavioural segments.) In addition, you can build a picture, for individual users, of the different experiments that they have been exposed to over their lifetimes, enabling you to model the impact of individual and collective testing on user behaviour over a long time horizon.
The integration works by auto-populating the different contexts listed above (Experiments, States, Variations, Visitor, Audiences and Dimensions. You can view the different Redshift table definitions that are populated using the Optimizely context below:
|Tracker Argument||Corresponding Redshift table definition|
Some notes on using these contexts:
- All but the
optimizelyVisitorcontext return an array of contexts to be sent with the event. This can cause the size of the event payload to sky-rocket. As a result, we recommend setting the tracker to
POSTevents to Snowplow rather than use
GET, as there are limitations the size of the request that can be sent using
GET. Documentation on setting the tracker to use
POSTcan be found here.
- All of the contexts are dynamically rebuilt with each event sent so as to represent any changes that might have occurred with either source.
- The activated contexts will be sent with every event.
2. Augur.io integration
Augur.io is a device and user recognition service, that amongst other things has robust device fingerprinting technology that does not rely on cookies.
The Augur.io integration means that Augur device recognition data is automatically captured and passed into Snowplow with each event recorded, which includes the following data points:
- A consumer UUID (that can be used instead of existing user identifiers like cookie IDs, or in combination with existing IDs)
- A device ID
- A flag that indicates if the device is a bot
- A flag that indicates if the user is ‘in cognito’
- A flag that indicates if the user is browsing via a proxy
The full SQL table definition can be found here.
3. Enhanced Ecommerce tracking
It has always been possible for Snowplow users to track enhanced ecommerce-like events, including product views (impressions), add to baskets and remove from baskets events.
A number of our users come to Snowplow from Google Analytics, having already implemented Enhanced Ecommerce. With this release, they can now mirror their GA enhanced ecommerce integrations in Snowplow directly, cutting down implementation time.
There are two ways to setup enhanced ecommerce tracking in Snowplow:
- Assuming you setup Enhanced Ecommerce via GTM and the GTM dataLayer, we recommend integrating Snowplow tracking tags as documented here.
- If you have not integrated Enhanced Ecommerce via GTM, you can mirror the integration in Snowplow using the new Enhanced Ecommerce methods listed below.
|Corresponding Redshift table definition|
4. Better automatic domain management (for cookies) and other new functionality
www.mysite.com, they will be set to
www.mysite.com. If the user moves to a new top level domain e.g.
blog.mysite.com, a new cookie will be set on the new top level domain
blog.mysite.com. That means the
domain_userid value recorded for the user on
www.mysite.com will be different to the
domain_userid value set on
That is not ideal: in general we would like each user (or failing that device) to have a consistent first party cookie ID across different top level domains. Previously, this was achieved by setting the cookie domain to
.mysite.com when initializing the tracking:
That was fine for users rolling out Snowplow tracking on one domain, but for users who wanted to roll out Snowplow across hundreds of domains, it created friction because a different tag (with a different
cookieDomain value) needed to be set for each root domain.
Now that is no longer necessary, you can simply set
true, and the cookie domain will automatically be set to the root domain rather than the top level domain:
We have also added a feature that enables you to force sending data from the tracker via
HTTP rather than
HTTPS. Note that this should only be used in test environments. To force sending events via HTTP, set
forceUnsecureTracker to `true in the tracker initialization:
5. Improved handling of time
Previously, the tracker recorded the timestamp on the client device when an event was recorded. This is the value that you see when querying the
dvce_created_tstamp in Redshift.
Now the tracker records the timestamp when the event was recorded and the timestamp when the event was sent to Snowplow. Note that there can often been a delay between an event happening and the data being sent, because:
- The tracker fires events asyncronously (so as not to interfere with page load times). As a result events are cached in
localStorageand only sent through to Snowplow when there is an opportunity
Snowplow uses the combination of the
collector_tstamp to figure out the actual time (in UTC) when the event occurred and report that in the
derived_tstamp field for easy use in time-based analysis. For more information on the algorithm used, please see our earlier blog post improving Snowplow’s understanding of time. As far as we are aware we are the only analytics provider with a robust approach to handling late arrival of data.
6. Updates and Bug fixes
Other updates include:
- Attempting to create a new Tracker using an existing namespace does nothing (#411)
domainUserIdis now a UUID (#274)
- Fixed issue with grunt-cloudfront library (#426)
doNotTrackin IE 11 and Safari 7.1.3+, thanks Grzegorz Ewald! (#440)
- Fixed bug where properties from
Object.prototypewere incorrectly added to
The upgraded minified tracker is available here:
8. Documentation and help
- The setup guide
- The full API documentation
The v2.6.0 release page on GitHub has the full list of changes made in this version.
Finally, if you run into any issues or have any questions, please raise an issue or get in touch with us via the usual channels.