Custom user ID
Batch can automatically tie several push tokens from different OS' to a single user ID. This allows you to use the Custom Data API. This is also useful if you are planning to use the Transactional API and don't want to manage devices' tokens on your side.
This custom user identifier can be:
- The unique ID you are using in your login system.
- A stable ID used in your data store (e.g. Firebase, etc).
- Any stable information that can help you to identify a user (e.g. hashed email address, etc).
Pushing a custom user identifier will send a notifcation to every installation with that identifier set.
If you want to only push a specific installation (and thus a specific device), you should set a installation-specific identifier or use Batch installation ID.
The API is pretty straightforward:
// This method returns a NEW editor instance every call. Make sure you chain calls or store the editor // in a local variable before calling save. Calling save() on an empty editor will do nothing. Batch.User.editor() .setIdentifier("john.doe") // Set to `null` if you want to remove the identifier. .save(); // This is how you retrieve your custom user identifier. Default value is null. String userId = Batch.User.getIdentifier();
This MUST be called when Batch is started.
On Android, it means that any Batch.User.editor() call must happen between
Calling it anywhere else will fail, and an error will be printed to your logcat.
You should remove the identifier anytime the identified user logs out.
User identifiers are case and whitespace sensitive. If you want to avoid potential issues, you may want to call
trim() on the identifier string.
Make sure the identifier is unique, otherwise users might get pushes that are not meant for them. You should never associate a custom ID to more than one user.
If you're wondering how to use the identifier in your app, we've covered a few use cases:
If you have a login system, you probably have a unique user ID associated to the user's account. Simply set this ID as your user identifier, and don't forget to reset it (by setting it to
null) when the user logs out.
While emails are an appropriate identifier, we suggest to hash them before setting them as your identifier, for privacy reasons.
Your datastore probably has a stable ID associated to your installation. You just need to make sure it is unique between installations, and you are easily able to retreive it from your backend code.
Anything that can identify a user uniquely will work. Emails, phone numbers, etc...
We suggest you hash this information before setting it, and use the same hash on your backend.
Otherwise, you will need to create a stable identifier for your app installation and send it to your backend. The most common way to do that is to generate a RFC4122 UUID.