Device & Contact Registration

Before you can send messages to your users, you must properly register devices and contacts with Marketing Cloud Engagement servers. Registration is the most important step in your entire implementation. It’s critical that you thoroughly read and understand all of the information in this section.

Device and contact registration is a critical process managed by the SDK, which plays a pivotal role in establishing a robust framework for communication within the application. By managing this registration, the SDK ensures your application integrates smoothly with all MobilePush features -- from targeted messaging to analytics, all designed to enhance user engagement and provide valuable insights into user interactions.

The SDK simplifies the registration process, allowing developers to concentrate on creating impactful user experiences. By relying on the SDK to maintain a robust communication framework, they can ensure effectiveness without getting bogged down in complexity.

Registering devices and contacts with Engagement servers is shown in steps 3 and 4 of the following diagram. Although this diagram is specific to push notifications, these two registration steps are the same for all message types. For more information, see How MobilePush SDK Works.

Registration Flow Diagram

First, the SDK is initialized. For push notifications, the SDK negotiates with the Push Notification Service (PNS) for a device token. Then, regardless of the message type, the SDK asynchronously attempts to register and update important information, such as the device token, device ID, contact key, attributes, and push opt-in status, with Engagement servers.

By default, when a user installs and launches an app for the first time, the SDK immediately submits a registration after a successful SDK initialization. All subsequent registration updates are triggered only after there’s a change to the contact record that is stored locally on the SDK (by updating an Attribute). These subsequent registrations are sent to Engagement servers within one minute after the first change to the locally stored contact record.

Registrations are throttled so that they can’t occur more than one time per minute. Registrations are triggered by changes to any SDK contact record dataset by your application. These changes encompass changes to contact keys, custom attributes or tags, and system-related attributes, including time zone, device locale, and application version.

The SDK is considered the source of truth for the contact’s device registration. Registration data is sent asynchronously in one direction from the SDK to the Engagement servers. After the SDK’s REST call is successfully received, it can take up to five minutes for Engagement servers to fully process the updated registration data.

Registrations are asynchronous. While the SDK can receive a successful 201 response from the server indicating that it received the registration, it can’t ascertain whether it successfully processed it (for example, due to invalid data).

If a registration fails because Engagement servers are unavailable, the SDK uses a back-off algorithm with increasing retry intervals up to a maximum delay of one day. At that point, the SDK retries daily until registration is successful.