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

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.