Consent and cookieless mode

If your site asks visitors for consent, tell askbowtie what they chose. Granted runs the tracker as normal. Denied switches to cookieless mode. Opt-out sends nothing at all.

Nothing changes unless you pass a signal. A site that never mentions consent keeps exactly the behaviour it has today.

The three states

State	What askbowtie does
`granted`, or no signal	Normal tracking. Sessions, return visits, ad attribution, all as before.
`denied`	Cookieless mode, described below.
opted out	Sends nothing, on this visit and every later one, until the visitor opts back in.

Pass the signal from your page

On the tag. The simplest way, and the only one that holds from the very first byte. Render it from your consent state on the server:

<script src="https://askbowtie.com/bowtie.js" data-token="your-claim-token"
        data-consent="denied" async></script>

From your consent banner. Call it whenever the visitor decides:

bowtie('consent', 'granted');   // or 'denied'

Switching to granted mid-visit starts full tracking from that moment. Nothing recorded earlier is upgraded: there is no backfill. Switching to denied clears what the tracker had stored and stamps everything after it.

Before the tracker has loaded. If your banner can answer before bowtie.js arrives, add this one line above the tag. Calls made through it are queued and applied before the tracker writes anything:

<script>window.bowtie=window.bowtie||function(c){(window.bowtie._q=window.bowtie._q||[]).push([c,[].slice.call(arguments,1)])};</script>

Opt-out. For a "do not measure me" link:

bowtie('optout');   // sends nothing from now on
bowtie('optin');    // withdraws it

Opt-out stores exactly one item, bowtie_optout, in the visitor's browser. It is the only way an objection can still be honoured on their next visit.

What cookieless mode does

Cookieless mode stores nothing on the visitor's device and never retains raw IP addresses. It is designed to fit the CNIL audience-measurement exemption and the UK PECR statistics exemption when configured as described; your obligations to inform visitors and offer an opt-out remain yours.

No storage. The tracker reads and writes no cookies, localStorage or sessionStorage. The opt-out flag above is the single exception, and only once a visitor opts out.
No session id from the browser. We group a visitor's page views into one session per day, using a keyed hash whose key is replaced every day and deleted after two. Once the key is gone, the hash cannot be linked back to an IP address, even by us.
No visitor identity. bowtie.identify() and ?ab_uid= links are ignored.
No ad attribution. Click ids and UTM parameters are never collected, and are stripped on our side too. Ad pixels do not fire, and these visits are never uploaded to an ad platform.
Still measured. Page views, engagement, errors, performance and conversions, per page.

What you give up

One session per visitor per day. Two separate visits on the same day count as one session.
No return visitors. Tomorrow's visit cannot be linked to today's.
No source-level ad reporting for these visits. Search Console data is unaffected: it is per page, not per visitor.

Make denied the default for your site

If your visitors must opt in, email [email protected] and we will set your site's default to denied. Visits without a signal are then stored in cookieless form. An explicit granted from your banner still wins.

The tracker learns the default a moment after it starts. To be cookieless from the first byte, put data-consent="denied" on the tag as well.

Server-side senders

If your backend posts events (see server-side sessions), add the visitor's choice to each event:

{ "domain": "example.com",
  "events": [{ "event_type": "page_load", "page": "/pricing",
               "source": "server", "consent": "denied" }] }

When every event in a batch is denied, leave session_id out: we derive it, exactly as for the browser. Keep forwarding X-Forwarded-For and X-Bowtie-Visitor-UA, so your server events and the browser's land in the same daily session. No consent field means granted, which is today's behaviour.

Not in this version

The tracker does not read Google Consent Mode or IAB TCF signals by itself. Pass the result to bowtie('consent', ...) from your banner's callback.

For AI agents

Wiring this with a coding agent? Hand it this:

Pass the site's consent state to askbowtie. On the tag: data-consent="granted"
or "denied" on the bowtie.js script element. At runtime: bowtie('consent','granted')
or bowtie('consent','denied') from the consent banner callback; add the one-line
queue stub above the tag if the banner can answer before bowtie.js loads.
For an opt-out link: bowtie('optout'); undo with bowtie('optin').
Server senders: add "consent":"denied" to each event; omit session_id when every
event in the batch is denied. Absent consent means granted.

New here? Install the tracker first.