How Clakta tracking works
The path a visitor takes from an ad click to an attributed order, and which part of the system is responsible for each step.
Understanding the flow makes every troubleshooting question easier to answer. There are four moving parts, and each one can fail independently.
The flow
- A visitor clicks an ad. The destination URL carries a
clktparameter that the ad platform filled in with its own macros — platform, placement, campaign id, ad set id and ad id. - The script records the landing. It reads the URL, captures the
clktvalue and the UTM parameters, and sends a page view tied to a session. - The visitor browses and buys. Further page views and ecommerce events — product views, add to cart, checkout started — extend the session.
- Your server reports the order. When the purchase actually completes, your backend posts it to the Orders API with the tracking context that came from the browser.
Clakta then walks backwards from the order through the visitor's touchpoints, keeps the ones inside the attribution window, and assigns credit using the project's attribution model.
The public script can report that payment was submitted, but it can never create a completed order. Orders exist only through the authenticated Orders API, so a hostile browser cannot invent revenue in your account.
The clkt parameter
This is what makes ad matching work. It is a single URL parameter with five colon-separated segments:
clkt={platform}:{source}:{campaignId}:{adSetId}:{adId}A real Meta click resolves to something like:
clkt=fb:facebook:120210000000:120211111111:120212222222Each platform writes it with its own dynamic macros, so you set the template
once per platform and the platform fills in the values on every click. Google
has no ad set concept, so that segment arrives as null and is stored as empty
rather than as the literal string.
Clakta normalizes the platform token, so fb, facebook, instagram and ig
all resolve to meta; google, google_ads and youtube all resolve to
google.
Setting this up is covered in Tag your ad URLs.
Sessions
A session groups everything one visitor did in one sitting. How it is established depends on your project's tracking mode:
- Full attribution — the script creates a session id in the browser and sends it with every event, so the same visitor is recognised across page loads and, over time, across visits.
- Privacy-friendly — no identifier is stored in the browser. The server derives an anonymous daily session hash from the request's IP, User-Agent and site domain. It links events within a day but not across days.
See Tracking modes for the full comparison.
Linking the order back to the session
When your backend posts an order, it passes a tracking object. This is what
connects a server-side purchase to the browser session that produced it:
| Field | Purpose |
|---|---|
clkt | The ad click that brought the visitor in. |
utm_source, utm_medium, utm_campaign, utm_content | Standard campaign parameters, kept for reporting. |
sessionId | The browser session the order belongs to. Ignored in privacy-friendly projects. |
domain | The hostname the purchase originated on. Required for privacy-friendly projects with more than one tracking domain. |
For privacy-friendly projects you also pass the shopper's ip and userAgent
so the server can recompute the same anonymous session hash the page views got.
Pass the shopper's values as your storefront saw them — not your server's.
Sending your own server's IP and User-Agent is the most common reason privacy-friendly orders never match a session. Every order then looks like direct traffic.
What can go wrong, and where
| Symptom | Where the problem is |
|---|---|
| No events at all | The script is not loading, or the domain is not in the allowlist. |
| Events but no orders | Your backend is not posting to the Orders API. |
| Orders with no campaign data | Your ad URLs are missing the clkt parameter. |
Orders with clkt but no session | The sessionId (or the IP/User-Agent pair) is not being forwarded from the browser to your backend. |
| Spend but no conversions | Ad accounts are connected, but tracking is not — check the two rows above. |
Related
Related articles
Tracking modes
Privacy-friendly or full attribution — what each mode collects, how sessions are built in each, and what changes in your data when you switch.
Track ecommerce events
Record product views, add to cart, checkout start and payment submitted from the browser — and understand why completed purchases are not in this list.
Identify customers
Attach a known person to the current session with clakta.identify(), so journeys follow the customer instead of the browser.