Features
Click ids and attribution done right
Your campaigns get the click ids they need to attribute a conversion — and no platform ever receives an id that belongs to another.
Click-id matrix
Example data: Static example state — not live traffic, no real customer data.| Click id | Captured | Forwarded only to | Kept |
|---|---|---|---|
gclid | landing page, after marketing consent | Google Ads, GA4, Google Marketing Platform | 90 days |
fbclid | landing page, after marketing consent | Meta | 90 days |
ttclid | landing page, after marketing consent | TikTok | 90 days |
msclkid | landing page, after marketing consent | Microsoft Advertising | 90 days |
li_fat_id | landing page, after marketing consent | 90 days |
Retention is documented per id and configurable; 90 days is the default.
Captured after marketing consent, stored first-party, forwarded only to the owning platform.
Example matrix: which click id is captured, where it is forwarded and for how long it is kept.
Each id travels to exactly one platform
The tracker captures gclid, fbclid, ttclid, msclkid, li_fat_id and the other platform click ids on landing pages after marketing consent, stores them first-party for the vendor's window and forwards each id only to the platform it belongs to.
A landing page with a gclid and a fbclid produces two stored ids after marketing consent. When the purchase arrives, Track attaches the gclid to the Google Ads delivery and the fbclid to the Meta delivery — the matrix is machine-checked, so a cross-vendor leak is not a configuration mistake you can make.
How it is built
The technical decisions behind the capability — the proof after the benefit.
01
Destination-scoped forwarding
Meta never sees your gclid and Google never sees your fbclid. The policy matrix is machine-checked.
02
Order-level deduplication
Purchases carry the order id to every vendor that supports it, so browser and server conversions merge correctly.
03
Offline and CRM
Server events with an offline flag reach Google Ads, CM360, Microsoft, Meta, TikTok, Pinterest, Snapchat, Amazon, Yahoo and LinkedIn as offline conversions.
URL parameters in the dataLayer versus a scoped click-id store
The difference between collecting everything and forwarding what belongs where.
| URL parameters in the dataLayer versus a scoped click-id store | Click ids in the dataLayer | Click-id store in Track |
|---|---|---|
| Capture | Every parameter, on every page, regardless of consent | Only known ids, on landing pages, after marketing consent |
| Forwarding | Whatever a tag template reads | Per destination from a machine-checked matrix |
| Retention | Cookie lifetime set by each tag | Documented window per id, 90 days by default |
| Offline conversions | Manual uploads | Server events with an offline flag |
What you can verify
Product facts you will find in the dashboard, the docs and the audit log.
- Documented retention per click id (90 days by default)
- Enhanced Conversions with normalized hashing
- Affiliate networks with per-network click ids
Questions
- Do you build cross-site profiles?
- No. There is no fingerprinting and no cross-site identity; identifiers stay within the site and the consented purposes.
More capabilities
Built on the same signed configuration and event schema.
- AI-guided setup
Describe your site, confirm each step, publish a signed configuration.
- Server-side event router
One event, every platform: browser and server delivery with shared deduplication.
- Event debugger and lineage
See every event with its consent snapshot, routing decision and vendor response.
- Data quality and health score
A single score with explainable components and issues that link to their fix.
- Consent-aware by construction
Strict opt-in defaults, Consent Mode v2, purpose-based destinations, no replay after consent.
Try it on your domain
Create a site, install one snippet and let the assistant configure the first destination in minutes.