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.

Every project runs in one of two tracking modes. The choice decides whether Clakta stores anything in the visitor's browser, and it has real consequences for both attribution accuracy and your compliance obligations.

Set it when you create a project, or change it later in Project settings → General.

Privacy-friendly

The default. No cookies, no localStorage, nothing written to the visitor's device.

Instead, the server derives an anonymous daily session hash from three things it already receives with each request: the visitor's IP address, their User-Agent string, and the site domain. The same visitor produces the same hash for the rest of that day, which is enough to group their page views into a session.

The IP is anonymized before storage — it is used to compute the hash, not kept.

What this costs you:

  • No cross-day identity. A visitor who clicks an ad on Monday and buys on Thursday appears as two unrelated people. Long consideration cycles lose their first touch.
  • No cross-device identity. Phone and laptop are always separate visitors.
  • Shared networks blur together. Visitors behind the same office or carrier NAT with similar browsers can collapse into one session.
  • No personal data on orders. The API rejects any order whose customer object carries a name, email, phone, gender, date of birth, address or customer id. Only ip and userAgent are accepted.

Full attribution

The script creates a first-party session identifier and stores it in the browser. Every event carries it, so the same visitor is recognised across page loads, across sessions and over time.

What this gives you:

  • Real customer journeys. First click and last click can be days apart and still belong to the same person.
  • Multi-touch models actually work. Linear, Clicks & Deterministic Views and Triple Attribution all need a journey longer than one day to be meaningful.
  • Customer records. You can send name, email, phone and address with orders, and identify visitors from your own system with clakta.identify().
  • The Users section is populated. Without full attribution there are no persistent people to list.

The cost is compliance: storing an identifier on a visitor's device usually requires consent under GDPR and similar regimes. See Consent management — the SDK has built-in support for gating identifiers behind a consent decision.

Side by side

Privacy-friendlyFull attribution
Cookies / browser storageNoneFirst-party identifier
Session lifetimeOne day, server-derivedPersists across visits
Cross-deviceNoYes
Personal data on ordersRejectedAccepted
clakta.identify()IgnoredSupported
Users sectionEmptyPopulated
Multi-touch attributionSame-day onlyFull journeys
Typically needs a consent bannerNoYes

Which one to pick

Choose privacy-friendly when your legal position is the priority, when your purchase cycle is short enough that same-day attribution captures most of it, or when you simply want to start collecting data today without a consent implementation.

Choose full attribution when you need to know what actually drives sales over a multi-day consideration window, when you run retargeting you want credited properly, or when customer-level reporting matters to you — and you are prepared to handle consent.

Many teams start privacy-friendly to get numbers flowing, then move to full attribution once their consent banner is wired up. That order works well.

Switching modes

You can switch at any time, but the switch is not retroactive:

  • Historical data keeps the shape it was collected in. Privacy-friendly sessions do not gain cross-day identity retroactively.
  • Sessions do not stitch across the switch. A visitor active before and after is two separate identities.
  • Reports spanning the change contain a mix, so a step change in metrics around the switch date is expected, not a bug.

Related articles