Snowplow's technical contribution is a specific and correct idea that most of the analytics industry ignores, and its documentation is the best place to learn it. The idea is that event data should be validated against a schema at the moment of collection, and events that fail validation should be rejected and quarantined rather than silently accepted. Compare this with the prevailing model, where a tracking call fires with whatever properties the developer happened to send, the collection endpoint accepts it because accepting everything is easier, and the data quality problem surfaces months later as an analyst trying to work out why a revenue field is a string in eleven percent of rows. Schema-on-write, applied to behavioural data, converts a silent downstream data quality problem into a loud upstream engineering problem, which is precisely where you want it.
The documentation explains this with real rigour, covering schema definition, versioning, evolution, and what happens to events that fail, and the treatment of schema evolution in particular is better than anything else I have read on the subject. Versioning event schemas is genuinely difficult, because an event definition is a contract between code that ships on its own schedule, mobile apps that users may never update, and analysis that has to span the boundary. The material takes that seriously. The data modelling packs are the other practical strength.
Rather than telling you conceptually how to model sessions and users, Snowplow ships dbt packages that do it, which means you inherit a considerable amount of accumulated judgement about edge cases in sessionisation instead of rediscovering it. Anyone who has written their own sessionisation logic knows how many decisions it contains and how many of them you get wrong the first time. Now the thing that has to dominate any current assessment. On 8 January 2024 Snowplow moved its core pipeline components, including the collector, enrichment, the loaders and Iglu Server, to the Snowplow Limited Use License Agreement.
Snowplow is not open source any more. The trackers, analytics SDKs and Iglu SDKs remain Apache 2.0, so the client-side pieces are unaffected, but the pipeline itself is not. The terms matter and are more restrictive than most engineers assume when they hear about a licence change: version 1.1 of the agreement, rolled out in December 2024, permits use in test environments and for academic or research purposes, and does not permit running in production or commercial environments without a commercial licence from Snowplow, with highly available production deployment specifically outside the free terms. If your mental model is that Snowplow is the open source pipeline you can run yourself, that model is several years out of date and acting on it would be a mistake.
I want to be measured about this rather than indignant. A company has every right to change its licensing, particularly when the alternative is a cloud provider reselling its work, and the honest reading is that relicensing is what let Snowplow keep investing in the engineering that makes the documentation as good as it is. But the practical consequence for a learner is concrete. The skills transfer, and the architecture is worth understanding wherever you go.
The specific deployment you may be imagining while reading may not be one you are permitted to build. The licence change also produced the predictable fragmentation, with an Apache 2.0 community fork continuing from the pre-change codebase. Forks in this situation tend to start with the same code and diverge, and the documentation for one increasingly does not describe the other. For a learner that means you need to be clear about which thing you are reading about, and for an organisation it means the ecosystem you are joining is smaller than the project's reputation implies.
The practical criticisms beyond licensing are straightforward. There is no teaching layer at all: no course, no path, no certification, just excellent reference material for people who already know what a data pipeline is. And Snowplow is substantially more engineering work to operate than any hosted competitor, which is the trade you make for control and for the schema rigour. The documentation describes how to run it competently but does not confront the reader with the honest comparison, which is that a team choosing this is signing up to own infrastructure that a competitor would operate for them, in exchange for data quality guarantees that most organisations, if they are candid, are not currently equipped to exploit.
Three point four. Outstanding technical writing on an idea the rest of the industry should adopt, marked down substantially because the licensing reality is very different from the open source reputation, the ecosystem is fragmented as a result, and there is no teaching layer on top of the reference.