Introduction
One interface between your application and every tool that receives events
Every analytics and advertising tool arrives with its own SDK, its own event names and its own payload format. Add a second one and the tracking call at each conversion point stops being a line and becomes a block. Add a third and every one of those blocks has to change.
tracklane gives your application one interface. You declare your destinations once, you name
what happened once, and the library translates and distributes.
import { createTracking, ga4 } from 'tracklane/browser';
const { track } = createTracking({
providers: [ga4('G-XXXXXXX')],
});
track('purchase', {
transaction_id: 'T-1024',
value: 49.9,
currency: 'BRL',
items: [{ item_id: 'SKU-1', item_name: 'Notebook', price: 49.9, quantity: 1 }],
});Adding a provider is a line in the configuration. Nothing at the call sites changes.
How it works
You name events using GA4's vocabulary. That is the one opinion the library takes: a single language is required for a single interface to exist, and borrowing the most widespread one beats inventing a dictionary you would have to learn.
Each provider receives the translation into its own terms: purchase stays purchase for GA4,
becomes Purchase for Meta, and becomes whatever you mapped it to for the platforms that work by
conversion ID. Those translations ship with the library.
Import from tracklane/browser or tracklane/server, never from tracklane itself. The
root exports types only, for writing your own provider. The two are separate because the tools
work differently on each side: browser tags keep session state on their own, while conversion
APIs expect user data with every request. The library mirrors that instead of pretending it away.
What it is not
tracklane standardises and organises. It never changes
behaviour. The test applied to every decision is: if you did not have the library, how would
you write this by hand? The library replicates exactly that.
So it is not:
- A consent platform. It does not collect, store or display consent, and it does not decide whether an event may be sent. It forwards the consent call you make, when you make it, to the command each provider exposes, and nothing more. Providers with no consent mechanism receive nothing, because there is nothing to send them.
- A compliance layer. It does not know what GDPR or LGPD are. Legal basis is your decision.
- A validator. What may be sent is the sender's decision.
- A delivery guarantee. There is no queue, no retry and no buffer. Delivery is the provider's job, exactly as it is when you integrate directly. Emission is fire-and-forget and silent, and one provider failing does not affect the others.
- An analytics SDK. It collects nothing on its own and has no opinion on what you measure.
Providers
GA4 ships today, on both surfaces. Meta, LinkedIn, PostHog and X are next. They are designed for, but not yet implemented.
A provider is any tool that needs to receive events about what the user does in your system,
not just ad pixels. If it has a notion of track(), it can be a destination, and writing your
own uses the same public contract the official ones use. Nothing is reserved.