The Pixel Fires Before Anyone Clicks Your Banner

Paste TikTok's standard pixel snippet onto a page and the last two lines call ttq.load() and ttq.page() on load. That writes a first-party _ttp cookie (13-month lifespan) and reads TikTok's own cookies before the visitor has seen your consent banner, let alone accepted it. Under Article 5(3) of the ePrivacy Directive, storing or reading anything on a device that isn't strictly necessary needs prior consent. An advertising pixel is the textbook example of a cookie that isn't necessary, so firing it on load is a straightforward violation, and it's one a regulator or a cookie scanner spots in seconds.

TikTok gives you the tools to do this properly. The catch is that the default install doesn't use them, so you have to wire consent in yourself. This guide covers both transports (the browser pixel and the server-side Events API) because they carry the same legal obligation.

Two Transports, One Consent Rule

TikTok gives you two ways to send events, and teams often confuse their compliance status:

The browser pixel (ttq) runs in the visitor's browser, sets cookies like _ttp, ttcsid, and ttclid, and sends events client-side.
The Events API is a server-to-server endpoint. Your backend posts events (with hashed email, phone, IP, or the ttclid click ID) directly to TikTok, no browser script required.

Moving to the server doesn't remove the consent requirement. If the data you send can identify a person, and hashed email plus IP address can, then a visitor who declined advertising has to be excluded from the Events API call too. Server-to-server changes the plumbing, not the lawful basis. Most sites run both in parallel and treat the API as a backstop for events the browser pixel loses to ad blockers, so your consent gate has to cover both paths or it doesn't cover anything.

TikTok's Cookie Consent Mode

TikTok's pixel base code defines a set of methods you can call on the ttq object. Alongside page and track, the snippet registers consent methods: enableCookie, disableCookie, and the newer Consent Mode trio holdConsent, grantConsent, and revokeConsent. When you turn on Cookie Consent Mode for the pixel in TikTok Events Manager, the pixel holds off writing cookies until you explicitly signal that consent was granted.

The flow is: hold by default, grant when the visitor accepts your marketing category, revoke if they decline or later withdraw.

// TikTok base code registers these consent methods on ttq:
//   enableCookie, disableCookie, holdConsent, grantConsent, revokeConsent

// With Cookie Consent Mode enabled in Events Manager,
// hold cookies until the visitor decides:
ttq.holdConsent();
ttq.load('YOUR_PIXEL_ID');
ttq.page();

// Visitor accepts the marketing category -> release the pixel:
ttq.grantConsent();

// Visitor declines, or withdraws later -> stop and clear:
ttq.revokeConsent();

The Events API Has No Modeled Mode

Google's Advanced Consent Mode can send cookieless pings for users who declined and model the conversions it can't observe. TikTok has no equivalent. If you correctly withhold an Events API call because the visitor refused advertising, that conversion is simply not sent, and nothing fills the gap. So don't try to be clever at the app layer by sending a stripped-down event anyway. Gate the whole thing: if consent is absent, the browser pixel stays cookieless and the server never posts the event. Accept the measurement loss as the price of a lawful basis you can actually defend.

The Load-on-Consent Pattern That Actually Holds

Calling grantConsent() is the signal, but belt-and-suspenders means keeping the snippet out of the page until consent resolves. A consent management platform does this by holding the pixel script in a blocked state and only injecting it when the visitor accepts marketing. That way, even if a code change accidentally removes the holdConsent() call, the script that would set cookies was never on the page to begin with.

Verify it the way an auditor would. Clear all cookies, load the page, and don't touch the banner. Open your browser's Application tab and check for _ttp, ttcsid, or _tt_enable_cookie. If any of them appear before you click Accept, your gate is broken. A cookie scanner automates exactly this check across every page.

TikTok Consent Gate: Verify Before You Trust It

No _ttp, ttcsid, or ttclid cookie is set before the visitor accepts marketing
Test with cookies cleared and the banner untouched. This is the check regulators run.
Cookie Consent Mode is enabled for the pixel in TikTok Events Manager
Without it, grantConsent and revokeConsent have nothing to gate.
The Events API call is skipped when advertising consent is absent
Server-to-server carries the same lawful-basis requirement as the browser pixel.
Withdrawal fires revokeConsent and stops server events on the next request
Consent is not permanent. A visitor who changes their mind must be honored.
US state opt-outs (and Global Privacy Control) suppress the identifiers you send
An opt-out visitor should not have hashed email or IP forwarded to TikTok.

Doing It With CookieBeam

CookieBeam blocks the TikTok pixel script until the visitor accepts your marketing category, so the snippet that writes _ttp never runs early. When consent is granted, the banner releases the pixel and can drive TikTok's Consent Mode signal, and when consent is withdrawn it stops the tag. For the server side, CookieBeam's scanner captures outbound network connections, so a rogue call to TikTok's Events API endpoint shows up in your inventory instead of hiding in your backend. If you run server-side tagging, pair this with server-side consent enforcement so the Events API reads the same consent decision the banner recorded, rather than guessing.

Related Guides and Sources

Continue with Server-Side Conversions API With Consent, LinkedIn Insight Tag and Consent, and Meta Pixel and Conversions API Consent Gating. Primary sources: TikTok's Using cookies with TikTok Pixel, the Pixel Cookie Consent Mode developer docs, and the Events API reference.