Identify a user when you need to connect their activity to an account in your own system. You can collect basic mobile analytics without sending a user ID.
Choose an identifier
Use a stable internal ID, such as account-123. Keep the same identifier for the same account wherever you deliberately want to associate its activity.
Do not use an email address, phone number or full name as the identifier. An internal ID is not automatically anonymous: if your system can connect it to a person, handle it accordingly.
Optional attributes should help answer a real question. For example, a plan or account category may be useful; a customer's address or payment details are not needed for that purpose.
Send the ID through your SDK
Each platform has a different API. Use the recipe that matches your installed integration:
| Platform | Recipe |
|---|---|
| Android 1.2.0 | Identify users |
| iOS 1.1.11 | Identify users |
| React Native 1.0.22 | Identify users |
| Flutter 0.0.27 | Identify users |
Call the method after your app knows which account is active, for example after a successful login. Avoid assigning a user before authentication finishes.
Handle account changes
Test login, logout and switching accounts on the same device. An initialization, stop or reset method is not necessarily an identity-clearing method.
Check the behavior of your installed SDK before relying on it to clear an ID. If your integration does not document identity clearing, confirm the supported approach with CUX before using it on shared devices.
Verify the result
Use a test account with a synthetic ID and one harmless attribute. Run a short journey and check that the expected identifier and attribute appear in CUX. Repeat the test with another account and after logout.
Do not send extra personal data just to make the test easier to recognize. Screenshot masking does not filter identifiers or attributes you send through this API.
Continue with Track mobile custom events or Mobile masking and privacy.