Core concepts for Fullstory's User Anonymization API. Platform-agnostic guide covering session management, privacy compliance, and best practices for logout handling and user switching. See SKILL-WEB...
Implementation Files: This document covers core concepts. For code examples, see:
- SKILL-WEB.md — JavaScript/TypeScript (Browser)
- SKILL-MOBILE.md — iOS, Android, Flutter, React Native
Fullstory's Anonymize Users API allows developers to release the identity of the current user and create a new anonymous session. This is essential for:
When you anonymize a user, the current session ends and a fresh anonymous session begins. The previously identified user remains in Fullstory's records, but subsequent activity is no longer linked to them.
Cookie/Device Behavior: Normally, the device identifier links all sessions from the same device together. When
anonymizeis called, Fullstory generates a new identifier, effectively creating a "new device" from Fullstory's perspective. Any future identify calls will only merge sessions from the new identifier, not the old one.
┌─────────────┐ Login ┌─────────────┐ Logout ┌─────────────┐
│ Anonymous │ ───────► │ Identified │ ───────► │ New Anon │
│ Session A │ │ Session B │ │ Session C │
└─────────────┘ └─────────────┘ └─────────────┘
│
identify │ anonymize
(uid: 'xxx') │
| Scenario | Should Anonymize? | Reason |
|---|---|---|
| User logs out | ✅ Yes | Prevents session attribution to wrong user |
| User switches accounts | ✅ Yes | Clean slate before new identification |
| User requests data deletion | ❓ Consider | Part of broader privacy implementation |
| User clears app data | ❌ No | Fullstory handles this automatically |
| Screen/page navigation | ❌ No | Identity persists across screens |
| Session timeout | ❓ Depends | Based on your security requirements |
| Platform | Anonymize Method |
|---|---|
| Web | FS('setIdentity', { anonymous: true }) |
| iOS | FS.anonymize() |
| Android | FS.anonymize() |
| Flutter | FS.anonymize() |
| React Native | FullStory.anonymize() |
| Type | Limit |
|---|---|
| Sustained | 30 calls per page/screen per minute |
| Burst | 10 calls per second |
Note: A single call per logout is sufficient. Multiple calls provide no benefit and waste quota.
Always track important events (like logout) before calling anonymize, so they're attributed to the identified user:
1. Track "User Logged Out" event (attributed to user)
2. Call anonymize
3. Redirect to login screen
Always anonymize before navigating away from the current screen, otherwise the call may not complete:
✅ Good: anonymize → navigate
❌ Bad: navigate → anonymize (may not execute)
One anonymize call is sufficient. Multiple calls:
Audit your application for all ways a user can sign out:
For apps that support multiple accounts:
1. Track "Account Switch" event (current user)
2. Anonymize current session
3. Set up new account context
4. Identify as new user
Create a centralized logout service that:
For apps with workspace or tenant switching:
For shared devices:
For privacy-conscious users who want to browse without tracking:
Symptom: New user activity appears under old user
| Cause | Solution |
|---|---|
| Anonymize called after navigation starts | Use async version and await completion |
| Anonymize never called | Audit all logout paths |
| Wrong syntax (web) | Use { anonymous: true } not { uid: null } |
Symptom: User has many short, fragmented sessions
| Cause | Solution |
|---|---|
| Calling anonymize on every screen load | Only anonymize on actual logout |
| Calling anonymize on errors | Only anonymize for identity changes |
| Multiple anonymize calls in single flow | Use single call per logout |
Symptom: User properties persist after anonymize
| Cause | Solution |
|---|---|
| Re-identifying immediately after anonymize | Wait for new identify call |
| Cached user data in app | Clear app-level user state |
When helping developers implement User Anonymization:
Always emphasize:
Common mistakes to watch for:
Questions to ask developers:
Platform routing:
