Contact Dissociation
Sometimes, a contact can become dissociated from any known device. As a result, this contact is no longer targetable by marketers. Contacts who are dissociated from all known devices are sometimes called orphaned contacts.
When a user launches an app for the first time, the SDK initialization process begins. After a successful initialization, the SDK submits a registration request to Marketing Cloud. At this stage, the user is anonymous in Marketing Cloud because the app hasn’t set the contact key for them yet. Marketing Cloud assigns a random GUID as the contact key for these 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.
After the app identifies the user and sets their contact key, Marketing Cloud creates a contact associated with the device. As part of this process, Marketing Cloud automatically migrates the existing device from the anonymous contact represented by the random GUID and assigns the device to the new contact. The anonymous contact still exists, but has no devices associated with it.
Some apps support multiple users. In these apps, different users can log into the same app on the same device, and each user is assigned a unique contact key. However, in Marketing Cloud, a device can only be linked to one contact at a 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.
Delaying registrations helps mitigate the possibility of contacts being disassociated from devices. This configuration only registers users when they're identified. Your application is responsible for configuring the SDK to delay registration until the contact key is set.
Use this configuration mode only in situations where devices must be tied to a specific contact key that represents an individual user. Don't use 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.
This code example shows how to delay registration on Android apps that use SDK version 10.
This code example shows how to delay registration on Android apps that use SDK version 8.
This code example shows how to delay registration on Android apps that use SDK version 7.
To delay registration on iOS apps, use the setDelayRegistrationUntilContactKeyIsSet or sfmc_setDelayRegistrationUntilContactKeyIsSet methods, depending on the version of the MobilePush SDK you use.
This code example shows how to delay registration on iOS apps that use SDK version 10 and later.
This code example shows how to delay registration on iOS apps that use SDK version 8.
In the Objective-C SDK 8.x for iOS, use the configuration builder with setDelayRegistrationUntilContactKeyIsSet:@(YES)
This code example shows how to delay registration on iOS apps that use SDK version 7.
In the Objective-C SDK version 7.x for iOS, use the configuration builder with sfmc_setDelayRegistrationUntilContactKeyIsSet:@(YES).