Comparison

This problem has been solved before, at other sizes. Here is where tracklane sits, and where each alternative is the better answer.

Customer data platforms

Segment, RudderStack, Jitsu, Snowplow.

They collect events, resolve identity, transform and route to dozens of destinations, usually with a data warehouse as the primary target.

Choose them when you need a warehouse as the source of truth, identity resolution across systems, or transformations applied centrally after the fact.

Why tracklane exists next to them: they are infrastructure. Even the open-source ones need a service running, maintained and paid for (a container, a pipeline, a queue). If you have five pixels in a Next.js app, you do not want to operate a data pipeline; you want to stop writing the same call five times. Ad conversion is also a second-class citizen in that world, where the warehouse comes first.

Tag managers

GTM and server-side GTM.

They move the integration into a container edited outside your codebase.

Choose them when marketing needs to ship tracking changes without engineering. That is a real requirement and tag managers serve it well.

Why tracklane exists next to them: the price is that tracking logic leaves the repository, with no types, no code review, no tests or git history, and it becomes editable in production by people who never open the repo. Server-side GTM adds hosting on top. tracklane is for teams who want tracking to be code, reviewed in a pull request, typed, and shipped with the release that needs it.

Client-side abstractions

analytics and similar plugin-based wrappers.

The closest in shape: a plugin per provider, with track and identify on top.

Choose them when the browser is the whole problem.

Why tracklane exists next to them: they stop at the browser. There is no path to the conversion APIs, which is half the problem now (without a server-side path, tracker blocking and third-party cookie loss quietly sink your measurement). tracklane treats browser and server as two entry points of one interface.

One library per provider

react-ga4, react-facebook-pixel, @next/third-parties and friends.

Each wraps one provider, usually well.

Choose them when you have exactly one provider and expect to keep it that way.

Why tracklane exists next to them: N of them is the original problem (N APIs, N vocabularies, and N places to change when the next one arrives).

In short

tracklane is a library, not infrastructure. It has no service to run, keeps tracking in your codebase and under review, speaks both the browser and the conversion APIs, and translates one vocabulary into many. It has no opinion about anything else, which is the point.