Viewer ID
The viewer ID identifies the logged-in account behind the activity your app sends to the Experiences SDK. It is what ties a viewer's engagement together, so personalization, cross-device activity sync, and unique-viewer counts all depend on it being right.
Your app creates the viewer ID, not WSC Sports. Supply one for each logged-in viewer, typically a UUID from your own account system, and pass it to the SDK as externalUserId. Only you hold the mapping from that ID to the person.
WSC Sports receives the ID and related interaction events, not names, emails, or other direct identifiers, and can't resolve the ID back to an individual. It uses this data for recommendations, personalization, analytics, and backend operations.
The SDK accepts any text you send as a viewer ID. A wrong value never shows up as an error. Instead, viewers get weaker personalization and recommendations, broken cross-device sync, and analytics that count the wrong number of people.
- The SDK needs a viewer ID from you to identify a logged-in viewer.
- It mustn't contain any PII. See Must not be.
- You can store viewer IDs long term, either on the device or in your own systems.
- The SDK always creates its own generated user ID for the app installation, whether or not you send a viewer ID, and keeps it across app launches. It ties that installation's analytics together, including before a viewer logs in, but it isn't a viewer ID and can't connect a viewer's activity across devices. Only the viewer ID does that.
- A separate analytics session ID is new each time the app starts and lasts only until it closes.
For tracking modes and consent, see Viewer privacy considerations and privacy compliance. For how login, logout, and account switches affect stored activity, see Cross-device activity sync.
The sections below are the Viewer ID specifications.
Must be
- One value for each viewer account. One viewer account has one viewer ID, and one ID belongs to one account. Never give two accounts the same value.
- Only for logged-in viewers. Send no viewer ID for anonymous, guest, or logged-out sessions.
- The same every time. Send the same ID for an account after the viewer restarts the app, reinstalls it, updates their OS, or you upgrade the SDK. If the ID changes, that history is no longer connected to them and they start again as a new viewer.
- The same on every platform and device. Send the same ID for an account on iOS, Android, and web. This is what lets cross-device activity sync show a viewer the same likes and watch progress on their phone and their tablet.
- A value that doesn't directly identify anyone. Use a UUID generated for the account, or an internal account key that means nothing outside your systems.
- Text with no surrounding spaces. Remove leading and trailing whitespace before you send the value.
Must not be
Don't send any of these values:
| Don't send | What happens if you do |
|---|---|
| An empty or whitespace-only string | Send no viewer ID at all if a viewer isn't logged in. To end an identified viewer's activity, clear the ID instead of setting it to an empty string. On iOS an empty string is stored as a viewer ID in its own right, which pools every viewer who sends one into a single viewer. |
A placeholder, such as null, undefined, none, anonymous, guest, 0, or -1 | Every viewer who gets the same placeholder is treated as the same person. Their viewing history is pooled together, so personalization and recommendations reflect the crowd instead of the individual. |
The login method or auth provider, such as google.com, facebook.com, apple.com, email, or sso | These values say how someone signed in, not who they are. Everyone who signs in with Google is treated as one viewer. Send the account identifier your auth provider issues, not the provider name or the sign-in method. |
| A device or installation identifier, such as an advertising ID, an install UUID (a UUID generated per app installation rather than per account), or a push token | These belong to a device, not a person. The same viewer looks like two different people on their phone and tablet, and looks like a new person after reinstalling the app. |
| A session-scoped value, such as a session ID, access token, or JWT | These change on their own. Every time the value rotates, the viewer looks like someone new and their history starts over. |
| Personal data, such as an email address, phone number, username, or display name | This breaks the PII rule above. Email addresses and usernames also change, which resets the viewer's history. |
| A group attribute, such as subscription tier, region, language, cohort, or A/B bucket | These describe many viewers at once, so everyone in the group is treated as one person. |
Check these before you launch
Run through each case and confirm what your app sends:
- Log in, force-quit the app, then reopen it. The ID is the same as before.
- Log in to the same account on a second device. The ID matches the first device.
- Log in to the same account on the app and on the web. The ID matches.
- Browse as a guest. Your app sends no viewer ID.
- Switch to a different account. Your app sends the new account's ID, with nothing left over from the previous one.
- Log out. Your app clears the ID instead of sending an empty string.
- Look at the value once in a debug build. It's your own account key, not a provider name, an email address, or a token.
API reference: iOS | Android | Web | React Native
Updated 16 days ago