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
/snowplow.jsfrom being downloaded
- The shared domain used to host assets and infrastructure for Snowplow Managed Service customers
- The tracking endpoints themselves:
/ifor GET requests, and
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
- …? You would need to be able to receive events on a path other than
#3 is hard for a few reasons. First, the Snowplow Collector needs the event to be sent to
/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.
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.