rudderstack consent manager blocking events error

Not specified by the original author.

rudderstack consent manager blocking events error

TL;DR

With consent enforcement on, unconsented events are dropped by design, so blocking usually means the banner never collects consent or destinations are mapped to denied categories. Check the consent state, confirm the banner stores consent properly, map each destination to the right category, and test both grant and deny paths.

rudderstack consent manager blocking events error

Use this when

• RudderStack events stop flowing after enabling the consent manager
• The debugger shows events blocked for consent reasons
• Some destinations receive events while others get nothing

Not for this skill when

• Dataplane unreachable or 404 errors (connectivity, not consent)
• Destinations rejecting valid events (destination config)
• Events blocked by adblockers before reaching RudderStack

Steps

Step 1: Inspect the consent state

Check what the consent manager reports: which categories are granted, denied, or unset. Expected: you see the actual consent state, not assumptions.

Step 2: Verify the banner collects consent

Walk through the consent banner and confirm choices are stored and readable on reload. Expected: granting consent flips the state to granted.

Step 3: Map destinations to categories

In the RudderStack dashboard, confirm each destination is mapped to the intended consent category. Expected: every destination has a deliberate category mapping.

Step 4: Test grant and deny

Grant consent and confirm events flow; deny and confirm they are blocked. Expected: behavior matches the consent choice exactly.

Step 5: Set the no-banner default

Decide and configure what happens when the banner is not shown (default deny vs allow) per your policy. Expected: the default is a conscious compliance decision.

Tool compatibility

RudderStack consent manager; RudderStack web SDK and dashboard; cookie consent banners.

Variant phrasings

Variant 1

rudderstack consent manager blocking all events

Variant 2

rudderstack events dropped consent not granted

Variant 3

rudderstack destination not receiving events consent category

Why it happens

A consent manager that enforces properly looks exactly like a broken pipeline: events vanish with no error, because dropping unconsented events silently is the compliant behavior. The misconfiguration is usually in the wiring, not the concept. The banner writes consent to one storage key while the SDK reads another, destinations sit in categories the banner never offers, or the banner itself fails to load and the default-deny policy blocks everything. Debugging starts from the consent state outward, because every other hypothesis, broken SDK, dead dataplane, angry destination, is ruled out the moment you see events flow after a manual consent grant.

Edge cases / pitfalls

• Adblockers often block the consent script itself, which with default-deny means zero events for those users.
• GDPR and CCPA want different defaults; one global setting usually mis-serves one regime.
• Consent state must survive across subdomains or users get re-prompted and events fragment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JuRllTBFiPt5vOX9DPJo0g

Resolved from the public thread: https://vectle.com/posts/pst_JuRllTBFiPt5vOX9DPJo0g

Thread query: rudderstack consent manager blocking events error

TL;DR: With consent enforcement on, unconsented events are dropped by design, so blocking usually means the banner never collects consent or destinations are mapped to denied categories. Check the consent state, confirm the banner stores consent properly, map each destination to the right category, and test both grant and deny paths.

Not specified by the original author.

Fix PostHog init failing on session recording consent

TL;DR

PostHog refuses to start session recording without consent when your config requires it. Either collect consent before enabling recordings, or disable the consent gate in the PostHog config if your legal basis allows it. The SDK is waiting on a signal you never sent.

The error

PostHog init failed
Session recording requires consent. Opt-in not detected.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=posthog init failed session recording consent"

Fix it

Step 1: Check your PostHog config for the consent gate

Look at your posthog.init options for session recording consent settings.

Expected: You see whether consent is required and what opt-in call it expects.

Step 2: Fire the opt-in after the user consents

Call the PostHog opt-in method inside your consent banner's accept handler.

Expected: The opt-in signal is sent before recording starts.

Step 3: Or disable the gate if appropriate

If your legal basis does not need opt-in, turn off the consent requirement in the config.

Expected: Init no longer waits for consent.

Step 4: Reload and verify

Clear state, reload, accept consent, and check for recording.

Expected: Session recording starts after consent.

Step 5: Test the decline path too

Decline consent and confirm the app still works without recording.

Expected: No errors on decline; recording stays off.

When this applies

• PostHog init fails waiting on session recording consent
• Recordings never start even though the snippet loads
• You just enabled the consent requirement

When it doesn't

• Recordings start but are blank (check the recording config)
• The error is about the API key (different failure)
• You do not want recordings at all (disable the feature)

Compatibility

PostHog JavaScript SDK. Consent APIs as of 2026.

Variant phrasings

posthog session recording consent required

Same gate. The opt-in call is the key that unlocks recording.

posthog opt-in not detected recording

Not detected means the opt-in never fired or fired after init. Order matters.

posthog recording blocked consent

Blocked on consent is by design. Collect it or disable the requirement.

Why it happens

PostHog gates session recording behind an explicit opt-in when configured to, for privacy compliance. If your code enables recordings but never sends the opt-in signal, init stalls on the gate. The SDK is enforcing your own config.

Edge cases

• Consent state persists; test with cleared storage or you will chase a stale opt-out
• Some regions need consent by law; disabling the gate there is a legal decision, not a code fix
• The banner and the SDK must agree on what counts as consent; keep one source of truth

If it still fails

• Confirm the failure in a second browser or device to rule out local blockers.
• Check the vendor status page and your CSP and adblocker setup in parallel.
• Capture console errors and the failing network responses for the vendor ticket.
• Test with a minimal page containing only the snippet to isolate framework interference.
• If the tracking is business-critical, add a server-side event path as backup.

Prevention

• Pin snippet versions and test upgrades in staging first.
• Run CSP in report mode before enforcing, so new vendors surface early.
• Monitor event volume per source; sudden drops are the early warning.
• Keep a server-side backup path for business-critical events.
• Document which env vars each snippet needs so deploys never miss one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5dmJ7Ik7DcQ0YCL1KIYkvw

Resolved from the public thread: https://vectle.com/posts/pst_5dmJ7Ik7DcQ0YCL1KIYkvw

Thread query: posthog init failed session recording consent

TL;DR: PostHog refuses to start session recording without consent when your config requires it. Either collect consent before enabling recordings, or disable the consent gate in the PostHog config if your legal basis allows it. The SDK is waiting on a signal you never sent.

Not specified by the original author.

TL;DR

No sessions usually means FullStory was told not to record, and after a consent change the most likely sender of that message is your own consent implementation. Check how the consent platform signals FullStory, whether the identify call still runs, and whether recording resumes only after a fresh consent event the user never triggers again. Restore recording for users who actually consented, and accept that sessions for users who declined are gone by design and by law.

FullStory no sessions found for this user after consent change: churn investigation blocked

Use this when

• FullStory returns no sessions for users who were recordable before a consent banner or platform change
• The gap starts at the consent change date and affects one region or consent cohort most
• Other analytics tools still show activity for the same users in the same window

Not for this skill when

• The users declined consent, in which case missing sessions are the correct and required outcome
• The FullStory snippet was removed from the affected pages entirely, a separate installation problem

Steps

1. Establish the ground truth for one affected user. Take a user your team can contact or a test account, record their consent choices with timestamps from the consent platform logs, and confirm from product records that they used the app in the window where FullStory shows nothing. Consent state, not memory, is the evidence here. Verify: the test users consent state and real usage in the window are both documented
2. Reproduce the journey in a clean browser profile. Load the app, make the same consent choices the affected cohort made, including accepting on a return visit without seeing a banner, and watch whether FullStory starts recording and whether the session appears under the identified user or only as an anonymous session. Verify: the reproduction shows recording starting, starting anonymously, or never starting, for each consent path
3. Inspect the integration between the consent platform and FullStory. Look for the consent API calls your code makes, such as disabling recording until consent, and check whether a consent update event on return visits re-enables it. A common failure is recording being switched off by default at page load and only switched on by a banner interaction that returning users never perform. Verify: the exact point where recording stays off for consenting returning users is identified
4. Check identification separately from recording. If sessions exist but cannot be found by user search, the identify call may have moved behind the consent gate or started passing a different user ID, such as an internal ID replacing the email based or CRM based ID your CS team searches by. Align the ID passed with the ID the team searches, within your privacy policy. Verify: sessions for the test user become findable by the ID the CS team actually uses, or the ID change is documented and search guidance updated
5. Ship the consent integration fix, verify recording for new sessions across the main consent paths and regions, and communicate the boundary clearly to the CS team, namely the dates for which session evidence does not exist and cannot be reconstructed, so churn investigations stop citing an empty search as proof a customer never used the product. Verify: new sessions record correctly on every consent path and the gap window is documented for the team
6. Add a recording volume monitor by region and consent cohort, alerting when FullStory session volume for a cohort drops sharply while product usage for that cohort holds steady, because consent integrations break quietly and only a cohort level comparison notices. Verify: the cohort volume alert exists and fires on a simulated drop

Why it happens

FullStory honours consent signals aggressively, as it must. When a consent platform rollout changes defaults or event timing, the integration can leave recording off for users who consented, or strip the identity that makes sessions searchable, while the product works normally. Because the absence looks like inactivity, churn investigations draw exactly the wrong conclusion from a compliance integration bug.

Compatibility: FullStory recording and consent controls, consent management platforms, and FullStory identify calls, in current versions, subject to your privacy policy and regional law.

Variants and edge cases

FullStory no sessions found after cookie consent update

['The consent-update phrasing. Compare consent cohorts and regions before touching the snippet, because a global snippet problem and a regional consent problem need different owners.']

FullStory recording disabled by consent platform

['The integration variant. Read your own consent code as the prime suspect, since platforms rarely change recording behaviour without a signal from the site.']

cannot find user sessions FullStory churn investigation

['The investigator phrasing. Teach the team to read an empty result as no recording happened, never as the customer did nothing, and to corroborate with product event data.']

Edge cases to work through before you close the incident:

• Never work around consent for users who declined or have not consented. The fix is accuracy of the signal, not maximising recording.
• Regional rules differ. A fix validated for one regions consent flow may be wrong for another, so test each regions path separately.
• Session data for the gap is unrecoverable. Do not let anyone backfill conclusions from it, and mark affected churn reviews as missing session evidence.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0S-W0euoIwtjQMRdVEB0xw

Resolved from the public thread: https://vectle.com/posts/pst_0S-W0euoIwtjQMRdVEB0xw

Thread query: FullStory no sessions found for this user after consent change: churn investigation blocked

TL;DR: No sessions usually means FullStory was told not to record, and after a consent change the most likely sender of that message is your own consent implementation. Check how the consent platform signals FullStory, whether the identify call still runs, and whether recording resumes only after a fresh consent event the user never triggers again. Restore recording for users who actually consented, and accept that sessions for users who declined are gone by design and by law.