Consent and Cookies

Tapper runs from a single script on your website. This page covers what that script does with and without consent, how to tell it about a visitor's choice, and what you need to register in your consent management platform (CMP).

Your Integration Does Not Change

Consent handling lives inside the script, not in your integration:

• The same Monitoring Script and Conversion Script tags stay exactly where they are.
• The snippet still calls tapper.init(pk) with your public key.
• You still report conversions with window.tapper.push(...), unchanged.

One script, one integration — what it is allowed to do underneath changes with consent.

What the Script Does, With and Without Consent

The script runs in one of two modes per visitor, chosen automatically, based on the policy you set on the protection-script page (Website monitoring tab).

Cookieless mode costs storage, not the conversion itself. Tapper does not remove order value, currency, or the click id from a cookieless conversion — those still ride along, the same as in cookie mode. What's missing is durability: with nothing written to the device, the click id only survives for as long as it is present on the page — in practice the landing page view, or a later page you carry it forward on yourself during that same visit. A visitor who leaves and returns with no click id in the URL is not recognised, and the next conversion has nothing to attribute to.

What the Script Stores on a Visitor's Device (Cookie Mode Only)

None of these are written in cookieless mode. If a visitor grants consent mid-visit, the script starts writing them and carries the same visitor identity forward, so the click that brought them in is not lost.

Attributes of the tsid Cookie

Register these in your CMP alongside the entry above:

Cookies Tapper Reads but Does Not Set

If they are already present, the script reads Google's own _gcl_aw and _gcl_dc cookies to recover the click id. These are set by your Google tags, not by Tapper, and you declare them under Google in your CMP as you already do.

Two Ways to Tell Tapper About Consent

Tapper reads consent from two places. Door 1 — your direct call — is the more deliberate signal. Once given, it decides the mode regardless of what Google Consent Mode reported before it, and a grant reported through Door 2 afterward can never override a decision Door 1 already made. There is one exception to that, covered in the warning below.

window.tapper.consent("GRANTED");
window.tapper.consent("DENIED");

The Google Ads Upload Stamp

Separately from which door decided our mode, Tapper reads ad_user_data and ad_personalization from Google Consent Mode and stamps them on the conversions we upload to Google Ads — this is the consent status Google requires on every upload for EEA and UK visitors. If we hold no consent signal for a visitor, that field is uploaded as unspecified — unless we have confirmed the visitor is outside the EEA and UK, in which case it is uploaded as granted. That confirmed-non-EEA/UK case is a statement about jurisdiction, not about a choice the visitor made.

Your Script's Consent Policy

The ladder is choice, then policy, then region: an explicit choice through either door always wins; below that, your script's policy decides what a visitor with no choice yet gets; region only matters inside the Region-based policy. A DENIED always applies regardless of policy — no policy can override a real denial.

You set the policy yourself, on the protection-script page, on the Website monitoring tab (at the top) — workspace owners and admins can change it. There are three:

Your script's current policy is shown on the protection-script page, on the Website monitoring tab (at the top). This page does not state which policy applies to you — it's a setting you control, not a fixed default.

EEA/UK and Elsewhere Under the Region-Based Policy

• A denial from either door applies everywhere in the world, not only in the EEA and UK.
• With the Region-based policy active and no consent signal at all:
  • Visitors outside the EEA and UK get cookie mode — full attribution.
  • Visitors inside the EEA and UK get cookieless mode — fraud protection only — until they grant consent.
  • An unresolved location is treated the same as EEA/UK for this decision, because that is the only direction that cannot produce a claim we do not hold.
• The Consent first and Cookie first policies don't vary by region — see "Your Script's Consent Policy" above.

Example: Firing the Hook from Google Tag Manager

If your CMP does not publish Google Consent Mode and you want to wire Door 1 through GTM instead of your CMP's own script:

<!-- Custom HTML tag, triggered on your CMP's own "consent updated" event -->
<script>
  (function () {
    if (typeof window.tapper === "undefined") return;
    // Replace this with however your CMP exposes the visitor's choice
    var granted = yourCmp.getConsentState("advertising") === true;
    window.tapper.consent(granted ? "GRANTED" : "DENIED");
  })();
</script>

Fire this tag on your CMP's consent-update event, not on page load — the same rule that applies to Google Consent Mode applies here: only an actual choice should reach tapper.consent(), not a configured default.

If you already run Google Consent Mode correctly, Door 2 needs no code at all — the script reads it directly off gtag.

Verifying It's Working

Use this checklist to confirm cookieless mode is doing what you expect for your site.

1. Open your browser's DevTools Network tab and reload the page.
2. Find the request the monitoring script makes to users.ping (or users.registerTab on a returning visit) and inspect its response JSON for three fields: is_eea_or_uk (whether the visitor resolved as EEA/UK), consent_regime (your script's policy — one of GEO, CONSENT_FIRST, COOKIE_FIRST), and consent_gate (reads "GATE_ON" — the gate is live).
3. With consent granted, the response carries the visitor's identifiers and the browser sets the tsid cookie plus _tapper_lksd (local storage) and tbsid (session storage) — check the Application → Cookies/Local Storage/Session Storage panels for them.
4. With consent denied or unresolved in the EEA/UK, none of tsid, _tapper_lksd, or tbsid appear after the request — this is the confirmation that cookieless mode is active.
5. If you call tapper.consent("GRANTED") from the console after a denial, reload the network trace and confirm the cookie and storage entries now appear.

Declaring Tapper in Your CMP

Add the entries above to your cookie inventory so your banner reflects what actually runs on your site.

Fraud and security signals are commonly classified as necessary or security in CMP inventories, because they exist to protect the site and the advertiser rather than to profile the visitor. Attribution and measurement storage is commonly classified as marketing or statistics.

Withdrawing Consent

When a visitor withdraws consent — through either door — the script:

• Deletes the tsid cookie and the local/session storage entries above.
• Stops attribution for that visitor going forward.
• Keeps fraud protection running.
• Applies the withdrawal immediately. Door 2 withdrawals are also recorded on our consent wire today; Door 1 withdrawals are queued to be recorded the same way once that reporting path ships on our side — either way, the mode change itself is not delayed by that.