Skip to content

Personalization implementation for mobile apps with authorization

Albert Yanov edited this page Mar 13, 2025 · 4 revisions

Expected architecture setup of your system

  • mobile app has registration with log-in and log-out functionality
  • (optional) mobile app has user sessions (logged-in user session expires after some time)
  • backend handles authorization process - your platform contains unique IDs of end users
  • you use Infobip's web portal or push API for targeting users over push by their unique IDs or by tags / segments they belong to

Implementation flow

Every installation of the mobile app generates a new push registration ID. This ID should be linked to a unique person ID when an authorize/register/log-in API call is made from the mobile app to your backend.

Recommended Personalization flow implementation

  1. Subscribe to registrationUpdated event and wait for its invocation -> that's the time when library gets connected to Infobip's backend (push registration ID is generated)

  2. When a user successfully performs registration / log in -> you need to implement personalize call with the parameter forceDepersonalize = false over mobile app or backend API. In this case, it is assumed that until the moment of login a device was owned by an anonymous person; there was no authorization session in the application. The personalize call adds unique ID and additional information to the user profile.

    In case your app has a scenario when a user can log in to their account while the app still has a session with another user, you need to link that device to a new person, and, simultaneously, unlink a device from a previous person. So, when a user performs registration / login and user's ID is different from what was connected to the device -> you need implement personalize call with the parameter forceDepersonalize = true over mobile app or backend API.

  3. When user performs an explicit log out -> implement depersonalize call over mobile app or backend API. The depersonalize call detaches user data (IDs and other personal data) from a device and connects it to an anonymous profile.

  4. For applications with user sessions, keep the user's device personalised while a user's session has not expired. That will keep the possibility of sending messages targeted to the user. Also, when an authorised user with active session updates application with Infobip SDK for the first time, you need to personalize that device and link it to the authorised user. For that listen to the registrationUpdated event and, once it comes, perform personalize call with the parameter forceDepersonalize = true over mobile app or backend API. When a user session has expired and another user might use the app -> call depersonalize over mobile app or backend API to avoid sending messages targeted to the previous user.

Person with multiple devices

Our Mobile Messaging SDK, together with the Infobip Customer Data Platform (CDP) connects multiple devices logged in / personalized with the same User ID to the same persona. Once you implement the above-mentioned flow, push notifications sent to a user by default will be targeted to all devices connected to that person. However, you can set a device as Primary to send mobile push notifications to primary devices only. To target a single primary device of a person using a unique ID, set at least one device as Primary over mobile app or backend API. When sending a mobile push over the Send push API, set the parameter targetOnlyPrimaryDevices: true.


In case you would like to restrict updates of personal data or access to it from mobile app, and have enabled limitations on Application profile, use only banked API calls in recommended flow, described above. This approach is recommended for financial organisations and other apps operating with sensitive data. Below is a diagram describing the implementation for user identification and device management over backend.

Integration schema for mobile user identification and device management Updating app version with Infobip SDK(pluging) by authorized user
Clone this wiki locally