What’s New?
This small release adds support for custom endpoint paths in POST requests.
What does that mean?
As Snowplow grows in popularity, it gets used more and more for different use-cases. Some of those use-cases involve using Snowplow as a third-party analytics solution, tracking user behaviour across multiple sites, rather than as just a first-party analytics tracking tool companies use to keep their data internal. As a reaction to this, and part of the general trend towards protecting users’ privacy in the face of pervasive cross-site tracking, people are taking notice of Snowplow and building defensive measures to disable using it for this purpose. Primarily, these measure come from privacy tools like uBlock Origin, and other content-blocking extensions. Unfortunately, these measures also tend to hinder the more benign Snowplow usage of internally tracking behaviour to improve content and applications and power data-intensive features like personalization within the first-party platform.
The blocking typically targets 3 components of the tracking pipeline:
- The tracking library itself, usually blocking the resources
/sp.jsor/snowplow.jsfrom being downloaded - The shared domain used to host assets and infrastructure for Snowplow Managed Service customers
snplow.net - The tracking endpoints themselves:
/ifor GET requests, and/com.snowplowanalytics.snowplow/tp2
Since Snowplow is typically self-hosted and run on the first-party infrastructure, Snowplow users are able to try and circumvent these blocks. You might use workarounds like:
- Simply rename the library file from
sp.jsto something random and unique to your site, or bundle the library into your codebase as a module - Setup CNAME DNS records and corresponding TLS certificates to have your normal first-party domain pointing to the infrastructure at
snplow.net - …? You would need to be able to receive events on a path other than
/ior/com.snowplowanalytics.snowplow/tp2
#3 is hard for a few reasons. First, the Snowplow Collector needs the event to be sent to /com.snowplowanalytics.snowplow/tp2 so it can distinguish it correctly from the other endpoints used for built-in webhooks and other Iglu Adaptors. So to even receive events on another endpoint would require additional infrastructure to reverse-proxy the request to listen on a new endpoint, or to run a custom version of the Collector that can listen on your custom path. Second, even if you had that set up, the Snowplow JavaScript Tracker SDK was hardwired to send to an endpoint ending with /com.snowplowanalytics.snowplow/tp2 anyway, so the content-blocker would still be able to detect and block the request anyway.
Essentially, you would be running a home-brew, custom version of both the Collector and Tracker, that your own organization would have to maintain going forward. This is not ideal.
So, back in December 2018, work began on solving the second problem above, and change the JavaScript tracker specifically to address this problem. With these changes, from tracker version 2.9.3 onwards (released January 2019), it was now possible to change the endpoint Snowplow sends data to when using POST requests. We were halfway there! But unfortunately, the Collector was still unable to actually collect the events if they were sent to a custom endpoint. Fast forward to Snowplow release R116 Madara Rider and you can now complete the loop: the Scala collector can now be configured to map custom paths to paths used for identifying Iglu Adaptors.
What does this have to do with the Snowplow Inspector?
The same tricks used to avoid content blockers were also avoiding the extension’s ability to recognize Snowplow events and debug them! With this release, they’ll be picked up correctly again, and you’re free to use custom endpoint paths to your heart’s content.
Where do I get it?
As usual, you can install the extension via the Chrome Web Store. Existing users should have their version upgraded automatically. Firefox users, can grab and side-load the extension over on the Github releases page.
