Contact Dissociation
Sometimes, a contact can become dissociated from any known device in Marketing Cloud Engagement. As a result, this contact is no longer targetable by marketers. Contacts dissociated from all known devices are also known as orphaned contacts.
By default, upon installation and launch of the app for the first time, the SDK immediately submits a registration request to Engagement after a successful SDK initialization. At this time, the user is anonymous in Engagement because the app hasn’t set the contact key for them yet. However, the servers assign a random GUID as the contact key for such anonymous users. This process allows developers to capture information about anonymous users, and enables marketers to send messages to users who aren’t logged in or identified.
Later, the app identifies the user and sets the contact key for them, creating a contact associated with the device in Engagement. As part of this process, Engagement automatically migrates the existing device from the anonymous contact represented by the random GUID and assigns the device to the newly created contact. This process leaves the anonymous contact with no devices associated with it.
Additionally, for apps supporting multiple users, distinct users can log into the same app on the same device, with each user being assigned a unique contact key. However, within Engagement, a device can only be linked to one contact at any given time. Consequently, when a new user logs in and a new contact key is assigned, the contact key of the previously logged-in user is dissociated from the device.
Marketers have the option to maintain or delete these dissociated anonymous contacts for billing purposes.
Depending on your app's design or usage, it can be difficult to avoid having dissociated contacts. For example, if your goal is to target anonymous users, you could choose to not set a contact key. In such cases, if these anonymous users eventually create an account, their previous anonymous GUID becomes dissociated from any devices. However, you can minimize the likelihood of dissociated contacts by implementing a strategy such as delaying registrations in SDK configuration.
By delaying registrations, you can mitigate the possibility of contacts being disassociated from devices, also known as orphaned contacts, and ensure that only known users are registered with Engagement. Your application is responsible for configuring the SDK to delay registration until the contact key is set.
Use this configuration mode only for implementations where devices must be tied to a specific contact key that represents an individual user. Avoid using this configuration if you intend to set a generic contact key for your devices and users, or if you plan to send messages to unknown or anonymous users.
To delay registration on Android apps, use the setDelayRegistrationUntilContactKeyIsSet method, as shown in the following examples.
To delay registration on iOS apps, use the setDelayRegistrationUntilContactKeyIsSet or sfmc_setDelayRegistrationUntilContactKeyIsSet methods, depending on the version of the MobilePush SDK you've implemented.
In Objective-C MobilePush iOS SDK 8.x, use the configuration builder with setDelayRegistrationUntilContactKeyIsSet:@(YES)
In Objective-C MobilePush iOS SDK 7.x, use the configuration builder with sfmc_setDelayRegistrationUntilContactKeyIsSet:@(YES)
.