Seeka user privacy SDK

Seeka has User Privacy embedded into its core data pipeline. Consent state set through the SDK is respected by browser destinations (Meta, Pinterest, TikTok, Snapchat, etc.) and server-side destinations alike.

This page is the overview: the data control model, how gating works, and lifecycle. For the actual integration code, follow your integration path.

Data control modes

Every Seeka session runs at an effective data control mode, which decides whether destinations are gated on consent:

• Disabled (default) - the privacy SDK is a no-op. Destinations always load and setPrivacyState is recorded but gates nothing.
• Implicit - destinations load by default and stop once the user explicitly denies a relevant IAB purpose. Opt-out jurisdictions only.
• Explicit - destinations are blocked by default and only load once the user grants the relevant IAB purpose. Recommended for GDPR / UK / EU / AU opt-in law.

The effective mode is the stricter of two inputs:

1. The brand default - set by the brand in the Seeka admin app (Settings > Consent > Data Control > enable and pick a mode). This is the floor for every session on that brand, and most first-party integrations rely on it alone.
2. A session override - an embedding vendor or SDK integrator can tighten a single browser session, even when the brand default is disabled. The override only ever tightens (disabled > implicit > explicit), never weakens, and persists nothing against the brand. This is how, for example, a ticketing or events platform can enforce explicit for one EU event without changing the organiser's brand settings. See Browser > session-scoped override.

A session is gated whenever either input puts the effective mode at implicit or explicit. If both are disabled, nothing is gated - setPrivacyState is recorded but every destination still loads.

An explicit effective mode needs a consent mechanism. It blocks everything - including Seeka's own first-party collection - until you capture consent via setPrivacyState. Flipping a session to explicit and never granting consent silences it entirely, by design. See the browser guide.

How gating works

When the effective mode is implicit or explicit, every Seeka browser destination declares which IAB consent purposes it requires. At SDK init the privacy SDK reads the current consent state and decides whether each destination is allowed to load. When you later call setPrivacyState, the SDK re-evaluates every destination and enables or disables it accordingly.

Today the SDK uses a single canonical purpose for ad-tech destinations:

• IAB purpose ID 7 - Measure advertising performance. Required by Meta Pixel, Pinterest Tag, TikTok Pixel, Snapchat Pixel.

Server-side destinations are gated through the profile's consent.privacy.tcfConsentString, which the SDK keeps in sync with the browser state.

Consent input formats

The SDK accepts consent in two shapes. You can supply either or both:

• Explicit purpose lists - grantedIabPurposeIds: number[] and/or deniedIabPurposeIds: number[].
• TCF v2 consent string - tcfConsentString: string. The SDK decodes it to derive the granted purpose list when you have not supplied one. See the TCF v2 specification.

When you supply both, the explicit purpose lists win. An empty grantedIabPurposeIds: [] is treated as an explicit opt-out, never as "fall back to the TCF string".

Lifecycle and timing

• Load the Seeka SDK on page load. Do not wait for cookie banner acceptance to inject the Seeka init script - that's the wrong pattern. The SDK gates destinations on consent itself, so it should always load up front.
• Call setPrivacyState as soon as you have a decision from the user (banner click, restored preference, geolocation default). Once the SDK object exists it is safe to call before initialisation has finished - the state is recorded and applied as plugins load. From SDK v1.12.0 the install loader also queues setPrivacyState / setConsentManager calls made before the Seeka script itself has loaded and applies them during initialisation.
  • Ordering note: tracking calls queued before the script loads are replayed before queued consent, so on an implicit-mode session, events queued ahead of the consent call fire before it lands - resolve consent as early as you can. An explicit mode is unaffected: its deny-floor holds until consent arrives.
• setPrivacyState is idempotent. Repeated calls with the same state are a no-op.

For the browser code - including the safe pattern for calling consent before the SDK has loaded - see the browser guide.

Choose your integration path

• Browser - call the consent API from your CMP or cookie banner, or set a session override as an embedding vendor.
• Server - push consent updates from your CMP server-side via the HTTP API.

Troubleshooting

See Privacy SDK troubleshooting for a checklist when destinations are firing despite the consent API being called.