Features
Every conversion delivered once, with consent, to the platform it belongs to
Track replaces the tag container with a guided setup, a consent-aware server-side router and a debugger that explains every event. This page shows the product as it works — the states below are example data, not live traffic.
What happens to one purchase
Switch the scenario to see how the same event is routed when consent is granted, withdrawn, or a vendor is down. The decision and its reason are what you later read in the debugger.
Analytics and marketing granted
The purchase arrives from the browser and from the server with the same event id. The gate finds the required purposes and forwards it to all four destinations; Meta and TikTok deduplicate on the event id, Google Ads on the order id.
- Decision: delivered to Meta, Google Ads, GA4, TikTok
- Deduplication: event id (Meta, TikTok), order id (Google Ads)
- Click ids attached per destination: gclid → Google, fbclid → Meta
Analytics granted, marketing denied
The visitor withdrew marketing consent before the purchase. The gate lets the event through to Google Analytics 4 and blocks the advertising destinations with the reason purpose_not_granted. Nothing is stored for later; when consent is granted again, earlier events are not replayed.
- Decision: delivered to GA4; blocked for Meta, Google Ads, TikTok
- Reason shown in the debugger: purpose_not_granted (marketing)
- Consent Mode v2: analytics_storage granted, ad_storage denied
Consent granted, one vendor unavailable
TikTok answers with a server error. Track retries with jittered backoff, opens the circuit breaker after repeated failures and parks the event in the dead-letter queue. The other three destinations are unaffected. Once TikTok recovers, the dead-letter queue is replayed.
- Decision: delivered to Meta, Google Ads, GA4; TikTok retrying
- Circuit breaker open for TikTok; events in the dead-letter queue
- Replay after recovery keeps the original event id, so nothing counts twice
Six capabilities, one event layer
Each capability is built on the same signed configuration and the same event schema. Open a capability to see its product view, data flow and a before/after comparison.
AI-guided setup
Your first destination goes live in one guided session — without writing a tag, and without giving up control over what gets published.
- Business type and platform detection with a confidence level
- Event plan templates for shops, lead generation, SaaS and publishers
Guided setup
Example data: Static example state — not live traffic, no real customer data.Track AI
example-shop.test runs on Shopify with Cookiebot as consent tool (high confidence). For a shop I suggest view_item, add_to_cart, begin_checkout and purchase. Shall I draft the plan for Meta and Google Ads?
You
Yes, Meta first.
Track AI
Pixel id validated. The Conversions API needs an access token — please enter it in the vault card below; it never appears in this chat.
Vault card · Meta access token
Stored encrypted; visible to no one, including the model.
storedTest event · purchase
Sent through the real pipeline with the vendor's test event code.
accepted by MetaPublish version 13
Bound to exactly this diff and to you as the approver.
- + destination meta: browser + server
- + mapping purchase → Purchase (event id, order id)
- ~ consent: marketing required for meta
The assistant proposes, tools validate, you approve.
Server-side event router
Send each conversion once and let every platform receive it in the way it counts best — browser, server or both — without double counting.
- Browser SDK kept under 30 KB gzip by a CI budget, with consent-gated storage
- Server API with source keys for CRM and offline conversions
Destination health
Example data: Static example state — not live traffic, no real customer data.| Destination | Mode | Health | Last delivery | Queue |
|---|---|---|---|---|
| Meta | browser + server | healthy | 12 s ago | 0 retries |
| Google Ads | server | healthy | 40 s ago | 0 retries |
| TikTok | browser + server | degraded, circuit breaker open | 6 min ago | 3 in dead-letter queue |
| server | paused by kill switch | 2 h ago | held |
Health, mode and queue per destination; failures are handled, not hidden.
Event debugger and lineage
When a number in an ad platform looks wrong, you find out why in one place — not by guessing between browser console, vendor UI and a colleague's memory.
- Filter by event name, state and source
- Per-destination attempt history with HTTP status and error class
Live events
Example data: Static example state — not live traffic, no real customer data.| Event | Origin | Consent | Decision | Destinations |
|---|---|---|---|---|
page_view | browser | analytics | delivered | GA4 |
add_to_cart | browser | marketing | delivered | Meta, TikTok |
purchase | browser + server | marketing | delivered, deduplicated (order id) | Meta CAPI, Google Ads |
purchase | server | marketing missing | blocked: consent_missing | Meta CAPI |
generate_lead | browser | marketing | delivered |
Every row is one event with its origin, the consent at that moment, the routing decision and the destinations.
Data quality and health score
Know when tracking breaks, see which part broke and jump straight to the fix — before a campaign runs on bad data.
- Score per site with its components
- Resolve or ignore issues with an audit trail
Tracking health
Example data: Static example state — not live traffic, no real customer data.Score
86 / 100
Components
- Consent coverage91 · 20% weight
91% of events carry an explicit consent signal
- Critical events78 · 25% weight
7 of 9 planned critical events observed
- Schema quality74 · 15% weight
74% of events pass schema and PII checks
- Duplicates96 · 10% weight
1.0% duplicates
- Delivery88 · 20% weight
94% delivered, 1 integration with credential problems
- Freshness100 · 10% weight
Last browser event 4 min ago
Open issues
- purchase without currencyFix: update the event mapping
12 events in the last 24 h are missing the required parameter
- Consent signal missingFix: connect the CMP adapter
9% of events arrived without an explicit consent state
Weighted components; a lower score always points at its cause.
Consent-aware by construction
Every destination receives exactly what the visitor agreed to — evaluated for each event, in the browser and again on the server — so compliance is not a banner setting you hope is right.
- Inferred consent is never exported to advertising platforms
- Withdrawal stops sends immediately
Consent state and derived signals
Example data: Static example state — not live traffic, no real customer data.Purposes
- Strictly necessarygranted
- Analyticsgranted
- Marketingdenied
- Personalizationdenied
Consent Mode v2
analytics_storagegrantedad_storagedeniedad_user_datadeniedad_personalizationdenied
Block reasons the policy engine reports
consent_missing- no consent signal for the event yet
consent_denied- the visitor declined
purpose_not_granted- destination needs a purpose that was not granted
gpc_opt_out- Global Privacy Control set
destination_paused- kill switch or circuit breaker
inferred_data_not_exportable- inferred consent never reaches ad platforms
Purposes come from your CMP; everything else is derived, never guessed.
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.
- Documented retention per click id (90 days by default)
- Enhanced Conversions with normalized hashing
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.
Tag container versus event layer
Where a classic container leaves the work to you and where Track does it by construction.
| Tag container versus event layer | Classic tag container | Track |
|---|---|---|
| What runs on your site | Custom HTML and JavaScript tags from anyone with container access | One snippet and a signed, versioned configuration — no custom code execution |
| Consent | Trigger conditions per tag, maintained by hand | Policy engine that evaluates every event for every destination, browser and server |
| Server-side delivery | A second container, a second set of tags, manual deduplication | Built in: shared event id, retries, circuit breakers, replay |
| Finding errors | Preview mode and vendor UIs | Event lineage with consent snapshot, routing decision and vendor response |
| Changes | Publish and hope | Diff, approval, signed version, one-click rollback |
Facts you can verify
- EU data region
- Events are processed in the EU; vendor APIs receive only the fields you mapped, under the transfer basis documented per destination.
- Signed configurations
- Every published bundle is immutable, versioned and Ed25519-signed; the SDK verifies the signature before applying it.
- No custom code
- There is no custom HTML or JavaScript tag type. Transformations are declarative and validated on the server.
- Strict opt-in by default
- EU/EEA/UK/CH start with strict opt-in; inferred consent is never exported to advertising platforms.
See these views with your own events
Create your site, paste the snippet and let the assistant configure the first destination — the debugger and the health score fill up from the first event.