# Ad tracking & attribution

You own your buyer-facing product, so **browser-side tracking is yours to
do** — drop your Meta Pixel or GTM snippet into your own pages exactly like
on any site you run; nothing platform-side gets in your way. What you *can't*
build alone is the platform side of the picture, and that's what the **Ad
tracking** card in your panel adds.

## What the Ad tracking card does today

Open your panel → white-label portal → **Ad tracking** and save your **Meta
Pixel ID** and a **Conversions API access token** (Events Manager → your
pixel → Settings → Conversions API → *Generate access token*).

* **Server-side purchase events to your pixel.** When tickets for your
  attributed organizers' events sell through the TicketConnect storefront,
  the platform delivers each `Purchase` (value, currency) from its servers
  straight to your pixel via the Meta Conversions API — immune to ad
  blockers and iOS pixel loss, and only for buyers who accepted marketing
  cookies (the storefront's consent banner is handled for you). If a browser
  pixel event with the same event id exists, Meta deduplicates the pair
  automatically.
* **First-party attribution on every sale.** UTM parameters that brought a
  buyer to the TicketConnect storefront are stored with the ticket and power
  the **Sales sources** report — tickets and revenue per
  source / medium / campaign, independent of any ad platform.

The CAPI token is **write-only**: stored encrypted, never shown again,
replace or remove it any time.

## Honest scope

| You sell via | Browser-side tracking | Server-side conversions |
| --- | --- | --- |
| Your own frontend on the /v1 API | Yours — your pages, your pixel, your consent flow | ✔ — pass an `attribution` object (UTM fields, `fbp`/`fbc`, your browser `eventId`, `marketingConsent: true`) on [`POST /v1/events/{id}/tickets`](#api-tickets) or checkout [`POST /v1/checkout/{event_id}/complete`](#api-payments); we fire the CAPI `Purchase` to **your** pixel and dedupe it against your browser event by that id. `marketingConsent` is your declaration that the buyer consented on your pages — we take it at face value. |
| TicketConnect-hosted checkout (`GET /v1/checkout/{event_id}`) | ✔ end-to-end — your pixel runs on the page behind a built-in consent bar; nothing loads until the buyer accepts | ✔ — the page's browser `Purchase` and our server `Purchase` share one event id, so Meta deduplicates the pair automatically |
| TicketConnect storefront (your attributed organizers) | Platform-managed, consent-gated | ✔ delivered to your pixel |

Both `attribution` on the /v1 API and the hosted checkout's pixel dispatch to
**your** Meta Pixel ID / CAPI access token from this same Ad tracking card —
the platform pixel never sees your buyers.

The **GTM container ID** field is stored for upcoming TicketConnect-hosted
pages and has no effect yet — you don't need to fill it today; v1.1 lights
up the Meta pixel on the hosted checkout, not GTM.

> **Verify in minutes.** Open Meta Events Manager → *Test Events* and make a
> test purchase of one of your organizers' events on the TicketConnect
> storefront (accept the consent banner) — the server `Purchase` should
> appear within seconds. Selling on /v1 instead? Complete a test-mode ticket
> with `attribution.marketingConsent: true` (or a hosted checkout purchase
> with the consent bar accepted) and check your pixel's recent activity in
> Events Manager → *Overview*, where the dedup status is shown per event.
> Note the *Test Events* tab lists server events only when a test event code
> rides along — that's a platform-side setting, so ask us to coordinate one
> if you want your verification to show up there.