snowplow-javascript-tracker: behavioural events from browsers and Node servers

Three trackers, and the difference between them

The repository publishes three separate trackers, and choosing between them is the first decision a user makes.

The browser tracker is distributed on npm as @snowplow/browser-tracker, and it is the one for web applications. The javascript tracker is described as tag based and is also published under the @snowplow scope, and it is the one you load into a page without installing anything. The node tracker, published as @snowplow/node-tracker, is for Node.js applications, and that is the one that collects from the server tier.

The description of the repository covers both tiers explicitly: the trackers let you add analytics to websites, web apps and Node.js applications when using a Snowplow pipeline, and they collect user event data such as page views and e-commerce transactions from the client-side and server-side tiers.

That last point is the one to hold on to. The value of running the node tracker alongside the browser tracker is that the same business event, an order, can be recorded once by the server where the truth lives and again by the browser where the user interaction happened, and the two can be compared. Snowplow describes itself as a scalable open source platform for rich, high quality, low latency data collection designed to collect complete behavioral data for enterprise business.

So the trackers are not a general purpose analytics snippet. They are the collection tier for one specific platform, and they are only useful if that platform is part of the plan.

A Rush monorepo with a plugins directory

The repository layout shows a large monorepo rather than a single package, and the shape of it tells you how the three trackers relate.

There is a trackers directory holding the tracker packages, a common directory for shared code, a libraries directory, a plugins directory, and an api-docs directory. The build is orchestrated by Rush, with rush.json at the root, which is also where the Node version pin lives in .nvmrc.

The plugins directory is the part worth understanding. Snowplow trackers are extensible with plugins for specific integrations, and shipping them as separate packages in a monorepo means a plugin can depend on a specific tracker version without dragging the whole set into your bundle. The .bundlemonrc.json file at the root is a bundle monitor configuration, which is a hint that the size of what you ship is treated as a tracked property rather than an afterthought.

The rest of the tooling is conventional. There is an ESLint configuration with an ignore file, Prettier with its own ignore file, a browserslist configuration for target browsers, a tsconfig for the TypeScript build, a banner.js file for the licence header applied to the distributed files, and a setupTestGlobals.ts file for the test environment. A CLAUDE.md sits next to the CONTRIBUTING.md, so the project expects automated coding assistants to work on it.

A monorepo of this size has a cost, and it is worth naming before anyone clones it. The build is a package manager operation, not a single npm install, and the publishing story is Rush's rather than npm's.

Building it with Rush, and the gitleaks pre-commit hook

The maintainer quick start in the readme assumes git and Node.js 18 to 20 are installed, and the steps are short.

git clone https://github.com/snowplow/snowplow-javascript-tracker.git

The build itself uses Rush, which has to be installed globally first.

npm install -g @microsoft/rush
rush update
rush build

There is one unusual step in the middle, and it is a good one. The project uses gitleaks, which runs as a pre-commit hook to make sure sensitive data is not committed by accident. The readme links the getting started section of the gitleaks repository for installation, and notes that open source users updating from an earlier version might need to re-run rush install to update the git hooks from source.

The escape hatch is documented too, since a pre-commit hook that blocks a commit is a nuisance if you are in a hurry. The readme explains that the check can be disabled by running the commit command with the SKIP=gitleaks variable set, for example a commit message of Unsafe commit.

For a project that handles analytics identifiers, tokens and endpoint configuration, a secret scanner in the commit path is a reasonable default, and the fact that it is a hook rather than a CI check means it runs before the code leaves your machine.

Running the tests, including the browser end to end ones

Unit tests are run with a single command.

rush test

The end to end browser tests are a different matter, and the readme is specific about what they need. Run locally, they require an entry added to your hosts file.

cd trackers/javascript-tracker/
rushx test:e2e:local

The entry to add is 127.0.0.1 snowplow-js-tracker.local, which points the test domain at the loopback interface so the tracker under test is reached without going out to the network. That is a small detail and a useful one, since it tells you the e2e suite exercises a locally served build.

The rest of the browser testing runs on Sauce Labs, and the readme carries the Sauce Labs test status badge for the project.

The split between the two is a reasonable design. Unit tests run in the local rush workspace on every change, while the cross browser matrix runs in the cloud, which is the only practical way to know whether a tracker still works in every browser you claim to support. The .browserslistrc file at the root is where the supported browser set is declared, and it is the input to both the matrix and the build output.

If you are contributing, the practical sequence is rush update, rush build, rush test locally, and then push and let the hosted matrix run. If you are only consuming the trackers, none of this applies, because you install a published package rather than building the monorepo.

Where the Snowplow trackers are the wrong tool

Four limits, and the first one dominates the rest.

You need the platform. The trackers are described as usable when using a Snowplow pipeline, and a pipeline is a collector plus storage plus processing, which is infrastructure to run, secure, upgrade and pay for in time. A marketing site that wants a page view counter has no reason to operate that, and the trackers are the wrong shape of answer for it. If you are evaluating the Snowplow platform, the tracker is the cheap part of the decision.

The second is that there are three APIs to learn. The browser tracker, the tag based javascript tracker and the node tracker do not share a surface, and a team that needs both browser and server collection is learning two of them. That is a consequence of the three deployment models rather than a flaw, but it is a real cost, and it is the reason to pick one tracker first rather than all three.

The third is the collection model itself. Snowplow is built around behavioural event data and a data model that the pipeline enriches, which means the events your application sends have to fit that model, and the raw events are not the finished analysis. A team that wants a dashboard this afternoon is looking at the wrong layer of the stack.

The fourth is operational, and it applies if you self host. The e2e suite depends on a local hostname in the hosts file and on a hosted browser matrix, so the testing story is tied to infrastructure that a contributor has to set up. That is normal for a mature project, and it is the reason to budget time for it.

Licence, releases and the maintenance classification

The licence is the BSD 3-Clause, which the readme describes as an OSI approved licence, with the licence text in the LICENSE file. The copyright line reads 2022 Snowplow Analytics Ltd and 2010 Anthon Pang, which reflects a project that began under a different author and is now maintained by the company behind the platform.

A permissive licence like this one is easy to accept: you can use the trackers in a commercial product, modify them and redistribute them, and the only obligation is to keep the notice. This is not legal advice, and the notice has to travel with the distributed files, which is also why the repository has a banner.js file that applies a licence header at build time.

On releases, the line has been steady. Version 4.10.0 was published on 2026-07-27, 4.10.1 on 2026-08-19 and 4.10.2 on 2026-09-09, and the last push to the default branch was on 2026-09-09. The repository is not archived.

One detail in the readme is more interesting than it looks. The badge at the top of the file is an actively maintained marker, and it points at a page describing the tracker maintenance classification, which is how the Snowplow project states which trackers are expected to keep pace with new platform features and which are stable and left alone. Reading that page is the way to find out whether the tracker you depend on is the kind that gets updates when a new browser API ships, or the kind that stays where it is.

The docs links follow the same pattern, with a separate technical reference and quick start guide for each of the three trackers, published on the Snowplow documentation site rather than in the repository.

Editorial conclusion

The Snowplow JavaScript trackers are the right tool for a team that has already committed to a Snowplow pipeline and wants to collect rich behavioural events from both the browser and the server tier of an application, and for teams that need to control their own event collection rather than ship data to a hosted analytics vendor. They are the wrong tool for a project that wants a few page views, and the wrong tool if you have not yet decided whether a self hosted event pipeline is worth operating. Before adopting, confirm that a collector is running and reachable from both tiers, decide which of the three trackers you actually need, and read the tracker maintenance classification the project links, since it governs how quickly a tracker is expected to track new platform features.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. snowplow/snowplow-javascript-tracker on GitHub