Consent & Privacy Handling

Overview

Tracking behaviour can be gated by user consent.

This determines:

• when tracking begins
• whether a visitor identity is created
• whether attribution data is stored

If consent is not granted, tracking will not start.
This is a common reason why no signals appear during setup.

Consent Modes

Tracking behaviour is controlled using the require_consent option in Mark.init().

Mark.init({
  require_consent: 'auto'
})

Available options

• false → tracking starts immediately
• true → tracking starts only after explicit consent
• 'auto' → requires stored granted consent and treats missing consent as denied

Default: false

Recommended for production: 'auto'

How Consent Affects Tracking

Before consent is granted

When consent is not available:

• tracking is paused
• no visitor ID is created
• attribution parameters are not stored
• events are not sent

This may appear as “tracking not working”, but is expected behaviour.

After consent is granted

Once consent is granted:

• tracking starts immediately
• visitor identity is created
• attribution data is captured
• events begin to appear in OneLence

Compliance-Oriented SDK Controls

For enterprise or compliance-sensitive implementations, the Mark SDK provides additional controls that help align tracking behaviour with your consent model, CMP setup, and internal privacy requirements.

• Consent-first tracking: events and identify calls respect your consent configuration through require_consent and 'auto', so data is not sent before your consent model and legal basis allow it.
• TCF v2 alignment: optional consent_source: 'tcf' integration can read consent from a compatible CMP through the standard API and listen for updates, so tracking follows current purpose consent rather than a one-time snapshot.
• Strong privacy signals: optional honor_dnt treats Do Not Track and Global Privacy Control (Sec-GPC) as a hard block, supporting privacy-forward regulatory expectations and enterprise RFP requirements.
• Clean withdrawal of consent: when Mark.setConsent('denied') is called, stored attribution is cleared and the visitor cookie path is reset, reducing sticky identifiers after opt-out.
• Configurable identity hygiene: optional rotate_visitor_on_consent_change helps separate pre-consent and post-consent visitor state when your policy requires a stricter interpretation of fresh consent.
• Data minimization hooks: before_send lets you strip, hash, or drop fields per event before anything leaves the browser, while on_error supports observability without logging raw payloads.
• Resilient, bounded browser retention: failed deliveries can use a persistent outbox with a 48-hour TTL, improving reliability without creating indefinite local queues of behavioural data.
• Unload-safe delivery: pending consent-granted work can be flushed with sendBeacon on tab close or page hide, improving delivery completeness without changing which events are allowed to send.

Updating Consent State

If your site uses a cookie banner or consent manager, update the tracking state when the user makes a choice.

<script>
Mark.setConsent('granted')
</script>

or

<script>
Mark.setConsent('denied')
</script>

This should be triggered when the user accepts or rejects tracking in your consent banner.

Typical Integration Flow

A standard production setup:

1. SDK initializes with require_consent: 'auto'
2. visitor opens the site → tracking is paused
3. visitor accepts cookies → setConsent('granted') is triggered
4. tracking starts from that moment

Common Mistakes

Consent not granted during testing

Symptoms:

• no page views appear
• visitor ID is undefined
• attribution data missing

Fix:

• accept the consent banner during testing
• or temporarily set require_consent: false for testing

Consent signal not connected

Symptoms:

• consent banner appears, but tracking never starts

Fix:

• ensure your consent tool triggers Mark.setConsent('granted')
• check for JavaScript errors blocking execution

Using incorrect consent mode

Common issues:

• using true without calling setConsent()
• using 'auto' without stored consent state

Fix:

• use 'auto' in production
• ensure consent state is stored and accessible

When to Use Each Mode

• use false → local testing or internal environments
• use 'auto' → production websites with consent banners
• use true → strict setups requiring full manual control

Debugging Consent Behaviour

If tracking does not start:

• check browser console for errors
• confirm consent state is updated correctly
• test in a private browser session
• disable ad blockers during testing

Summary

Consent determines when tracking becomes active.

If consent is not granted, tracking will not start.

Most missing data issues during setup are caused by consent blocking rather than integration errors.