Consent management
Gate first-party identifiers behind the visitor's consent decision, and wire the SDK to your cookie banner.
In full attribution mode the SDK stores a first-party identifier in the visitor's browser. In most jurisdictions that requires consent. The SDK has a built-in consent gate so you can honour that decision without removing tracking altogether.
The consent gate
One flag controls everything that touches browser storage. When consent is withheld, the SDK:
- Does not create or read a stored session identifier
- Does not store the landing page or visitor marker
- Treats
clakta.identify()as a no-op - Still records page views and events, using server-estimated sessions
So revoking consent degrades a full-attribution project to privacy-friendly behaviour rather than turning tracking off. You keep traffic and same-day attribution; you lose cross-session identity.
Consent only has an effect in full attribution projects. In privacy-friendly projects no identifiers are ever used, so there is nothing for the flag to gate.
Set the initial value
Pass consent to init() with whatever your banner already decided:
clakta.init({
id: "YOUR_SCRIPT_ID",
consent: false,
})It defaults to true. If your audience requires opt-in, set it to false
explicitly and grant it later — do not rely on the default.
Update it at runtime
Call this from your banner's accept and reject handlers:
clakta.consent.update(true) // granted
clakta.consent.update(false) // revokedRevoking immediately clears every stored identifier — the session key, the
landing page and the visitor marker, in both localStorage and sessionStorage
(older SDK versions used the latter). Subsequent events fall back to
server-estimated sessions.
Read the current state at any time:
if (clakta.consent.get()) {
// identifiers are in use
}A complete opt-in flow
import clakta from "@clakta/javascript"
const stored = localStorage.getItem("cookie-consent")
clakta.init({
id: "YOUR_SCRIPT_ID",
consent: stored === "granted",
})
function onAccept() {
localStorage.setItem("cookie-consent", "granted")
clakta.consent.update(true)
}
function onReject() {
localStorage.setItem("cookie-consent", "rejected")
clakta.consent.update(false)
}Note that tracking starts immediately either way — anonymous while consent is withheld, identified once it is granted. You do not lose the visitors who never interact with the banner.
If you must block tracking entirely
Some legal advice requires that nothing at all is sent before consent. In that
case drop data-auto-init from the script tag (or do not call init yet) and
initialize only after the visitor accepts:
<script src="https://cdn.clakta.com/script.js" defer></script>function onAccept() {
clakta.init({ id: "YOUR_SCRIPT_ID", consent: true })
}This costs you the entire pre-consent session, including the ad click that
brought the visitor in. The clkt parameter is read from the landing URL — if
the SDK is not running when they land, and they navigate away from the landing
page before accepting, that attribution is gone. Use the consent gate instead
unless you are specifically required not to.
Choosing an approach
| Consent gate | Delayed init | |
|---|---|---|
| Traffic data before consent | Collected anonymously | None |
| Ad click captured | Yes | Only if they accept on the landing page |
| Stored identifiers before consent | None | None |
| Complexity | Low | Low |
Both leave the browser untouched until consent is granted. The gate simply keeps measuring in the meantime.
Related
Related articles
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.
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.