Common Terminology

The Mobile App Messaging SDK uses terminology that aligns with industry standards.

Anonymous Contact

A contact that doesn’t have an explicitly set contact key. When an app user’s identity is unknown and the SDK doesn’t set a contact key, Marketing Cloud automatically assigns a randomly generated GUID (Globally Unique Identifier) as the contact key.

Anonymous contacts are common when users first install an app, before they sign in or provide identifying information. When the app later identifies the user and sets a contact key, Marketing Cloud migrates the device registration to the new contact key. The original anonymous contact becomes an orphaned contact with no associated devices.

Asynchronous

A type of request where the SDK waits only to see if the server received the API call, but doesn’t validate the request or return its status. To check the status of an asynchronous request later, issue a subsequent request.

Because the Engagement SDK is installed in apps on billions of devices, we minimize contact between the SDK and Salesforce servers. As a result, the SDK primarily uses asynchronous, REST API calls for registration and analytics processes.

The asynchronous nature of the SDK can lead to confusion around registration. If you use the SDK to register a contact attribute that isn’t formatted correctly, you can still receive a success response from the server. However, this response confirms only that the server successfully received the API call, not that it successfully processed it. In this scenario, the server attempts to process the registration and then rejects it. This rejection can result in the loss of critical information, such as contact key, device token, and other attributes contained in the registration.

Contact Attributes

Key-value pairs that you can use to segment your audience and personalize your messages. Contact attributes serve as the common standard for segmentation and personalization across all channels. Examples of contact attributes include first name, last name, loyalty level, channel preference, signup date, birthday, postal code, or a unique identifier.

Marketing Cloud Engagement stores these values in the MobilePush Demographics table within Contact Builder. Define these contact attributes in Contact Builder before the SDK assigns a value and registers the data with the Engagement server.

Marketing Cloud Next stores contact attributes in the Individual data model object (DMO).

Device Token

A unique token that identifies a user’s device. When a user opts into receiving push notifications from an app, their phone’s operating system generates the token and registers it with the SDK. The device token is similar to both an address and an access code. Apple and Google use the device token to route push notifications to the correct device and to track its validity, including the recipient’s opt status.

Initialization

The process where the SDK begins to load its settings as the app starts up. For the Engagement SDK to function properly, it must complete the initialization process. The SDK’s initialization can start from the main thread, because its underlying implementation does its own processing on a separate initialization thread.

Local Contact Model

A copy of the contact model stored by the SDK. The SDK uses this model to update the attributes in Marketing Cloud. The SDK sends registration requests asynchronously, so there isn’t a synchronization mechanism between the SDK and Marketing Cloud.

Registration

The process where the SDK issues a REST API call to send critical information to Marketing Cloud Next or Marketing Cloud Engagement. The registration process facilitates the transfer of devices, contacts, device tokens, attributes, and similar information. This information determines whether Marketing Cloud can send a message to a contact.