The Optimizely integration delivers your Optimizely testing data with each event tracked in Snowplow, making it easy to identify:
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:
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.
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:
The full SQL table definition can be found here.
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:
|Corresponding Redshift table definition|
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:
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:
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.
Other updates include:
domainUserIdis now a UUID (#274)
doNotTrackin IE 11 and Safari 7.1.3+, thanks Grzegorz Ewald! (#440)
Object.prototypewere incorrectly added to
The upgraded minified tracker is available here:
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.