mParticle’s IDSync system supports the concept of “known” and “anonymous” user profiles:
Known user profiles can only be returned in response to an identity request with at least one matching login ID.
As a user begins to engage with your website or app, their initial activity is stored against an anonymous profile. If your organization uses profile link or profile conversion strategies, the first appearance of a new login ID will always cause a new known user profile to be created.
Aliasing gives you control over the transition from an anonymous user profile to a known user profile. You can choose to create a new known user profile that does not include any historical data from the original anonymous user profile. This may be necessary to comply with local privacy legislation.
Alternatively, you can choose to copy event and profile data from the original anonymous profile over to the new known profile to maintain a more complete picture of the user’s journey. This allows you to create audiences of users who may have fulfilled some of the conditions to be included in the audience anonymously before their known user profiles were created.
The mPTravel app wants to capture an audience of users who clicked on an in-app recommendation for a vacation package before continuing to purchase the recommended package.
A user named Clark Griswold downloads the mPTravel app and, while browsing, clicks on a recommendation link for an all-inclusive European Vacation. Since he hasn’t yet created an account, this action is attributed to his anonymous user profile.
Clark eventually completes his purchase. As part of the purchase funnel, he creates an account and provides an email address. Since he is now a known user, the purchase is attributed to his new known user profile.
A user first downloads your app or browses to your website:
1234
is createdThe user creates an account:
login
identity request is sent, including at least one Login ID (e.g. an email address)5678
login
request returns objects containing information on the previous and current users. At this time, any user attributes or products in the cart captured for the anonymous user profile can be copied over to the new known user profile, if desiredAn alias request is sent:
The alias request contains four key pieces of information:
The following information is not copied as a result of an alias request:
However, the mParticle SDKs provide a method for copying user attributes, identities and consent data any time the current user profile changes. For more information see the SDK docs for iOS, Android, and Web.
Aliasing is only available to clients using the Profile Link or Profile Conversion strategies.
For an alias request to be successful:
The most common use cases for aliasing occur immediately after a new Login ID is first seen, triggering the creation of a new profile. However, aliasing is a separate process from IDSync and an anonymous profile may be aliased to a known profile at any time.
Aliasing is not a synchronous real-time process. Errors will be returned in the case of failed authorisation or rate limiting, but otherwise, a 202 accepted
response will be returned. If an alias request fails for any of the reasons listed above, no error is generated.
Once an alias request has succeeded, it cannot be undone.
Was this page helpful?