Meet mParticle IDSync: The flexible identity framework you didn’t know you needed
When it comes to resolving cross-channel user events to a single profile, there is no one-size-fits-all approach. mParticle’s identity framework prioritizes flexibility, and empowers data stakeholders to take control over how profiles are created.
Today’s consumers expect their brand interactions to be personalized and consistent across all channels. In the digital ecosystem, however, delivering these experiences is no easy task. A typical customer journey today includes multiple touchpoints, like websites, mobile apps, and in-store interactions, and often spans multiple sessions. This creates challenges for product managers and marketers who are trying to understand customer engagement. To deliver the cohesive experiences that customers expect, it’s imperative to have access to a single, accurate view of customer behavior across all channels. This can be achieved through the process of unifying events performed on separate platforms to a single customer profile using unique customer identifiers, or identity resolution.
When it comes to achieving identity resolution, companies can pursue one of two main approaches––building, or buying. In the former approach, in-house data engineers build this functionality themselves, which is a labor-intensive process that requires ongoing development work to keep up with evolving business needs around customer engagement and analytics. In the latter approach, a company adopts a data platform that handles identity resolution. While this option has the immediate benefit of avoiding engineering overhead, buyers need to be discerning when determining which platform to adopt. There is no shortage of solutions on the market that promise a ‘single view of the customer,’ but most of those solutions fall short in two critical areas––transparency of merging rules, and control over establishing and changing merging rules.
In the rest of their article, we’ll explore how mParticle’s identity resolution offering supports visibility and flexibility, and highlight the value that data teams realize from this approach.
How IDSync works: Identity resolution tailored to your business
Identity resolution is a core feature that mParticle delivers to all customers out-of-the–box. As soon as you implement data collection with mParticle across your digital platforms, IDSync (the mParticle identity framework) will begin building unified customer profiles out of cross-channel events based on an established identity strategy.
Let’s explore the main components of IDSync.
The Identity API: The workhorse of IDSync
The backbone of IDSync is the Identity API. This API is what all of mParticle’s various SDKs use to determine a user’s login status, as well as search for and modify a current user’s identities. Each user in mParticle is defined by their mParticle ID (mPID), and this identifier is how the Identity API ties incoming data points to a unique profile.
The diagram below illustrates how a call to the Identity API works:
Requests to the Identity API contain all known identifiers for the current user. Once the request is received, the Identity API will map these identifiers against all user profiles in the system based on an established identity priority (which we will discuss shortly). If all identifiers match exist on a profile, Identity API will return that user’s full profile. If some but not all identifiers are found on a profile, IDSync will update this profile to include the new identifiers. If no matches are found, a new user profile with a new mPID and the identifiers will be created. This functionality of the Identity API is what enables mParticle users to employ different identity strategies and define priorities for identity types.
Identity strategies: Choose your identity resolution method
The optimal strategy for matching user identities across sessions and channels depends on many factors, like a company’s business goals and legal obligations. mParticle lets teams make their own decisions about how to accomplish user continuity tailored to their specific needs. This approach both enhances control over data, and ensures complete visibility into how user profiles are created and updated.
The identity strategy that a customer selects will guide the Identity API in two key behaviors:
- Determining which user profile to add incoming data points to when an identity match is found
- Handling scenarios in which an incoming user identity is unknown
mParticle has designed five separate identity strategies tailored to various business and privacy requirements.
- Profile conversion: This strategy prioritizes forming a complete picture of a user throughout an entire sales funnel. Using profile conversion, when a new login ID is received, a new MPID (and thereby a new user profile) will not be created, and the new login will be added to the profile that was established to capture data on this user when they were anonymous. This strategy optimizes for gaining visibility into journeys that span anonymous and logged-in states.
- Default IDSync configuration: This is a slight variation on the profile conversion strategy in which the unique ID and login ID must be set to customer_id. This cannot be changed. This reduces the likelihood that multiple login IDs will produce unwanted duplicates of user profiles.
- Profile link: Aimed at tracking what drives users to create accounts and make purchases, this strategy helps illuminate transition events from anonymous to known users by attributing anonymous app activity to the next logged-in user.
- Profile isolation: Handy for situations in which privacy regulations prohibit anonymous data from being attributed to known users, this strategy optimizes for preserving the accuracy and reliability of each user profile.
- Best match: This strategy suits business models in which profiles should be organized around device IDs rather than unique users. Use cases for best match include brands that do not support any login behavior, or apps that require users to create an account before usage.
Identity priorities offer another layer of control over profile building
Defining an identity strategy is not the only way in which mParticle customers can tailor identity resolution to their business. The ability to specify identity priorities offers mParticle users another mechanism for fine tuning how incoming data will be handled at the level of customer profiles.
Identity priorities are an order of precedence in which different identifiers will be used to match incoming data to a user profile. When an identity request is received, mParticle will look for matching profiles for each identifier in the request based on their priority order. If no matches are found, a new profile will be created.
Let’s look at an example of how this works in practice. Say we currently have the following two user profiles in our system:
Now let’s consider what would happen in two separate identity priority/API request pairings:
In the top scenario, the highest priority identity (email) would return both profiles in the system. Then the Identity API would look to “Other” as the next highest priority identifier, and profile 1 would be returned. Since the only other identifier in the request “IDFV” is already present on profile 1, there would be no need to add this identifier to the profile.
In the bottom scenario, the highest priority lookup (email) would again return both profiles. The Identity API would then look to IDFV as the next highest priority. Finding that IDFV is not in the request, it would look for GAID, which would then return profile 2.
How IDSync benefits teams across the organization
Now that we’ve taken a look under the hood of IDSync, let’s explore some of the specific benefits that this open and transparent identity solution delivers to teams across an organization.
Marketing teams deliver better personalization
Armed with unified customer profiles living in mParticle, marketers can forward a holistic view of each user to downstream engagement tools. There, they can deliver messaging and power customer experiences that are based on a complete understanding of a customer’s behavior, not a limited view of interaction on one channel. Furthermore, since these growth teams have complete visibility into how profiles are built, they can be confident that they are basing their engagement campaigns on accurate and up-to-date information.
Product teams acquire deeper insights into user journeys
User interactions with digital products are typically fragmented and take place across various devices and login states. For instance, it’s not uncommon for a user to download an app, browse around without registering for an account, create an account at a later date, continue to browse while logged in, then finally make a purchase. By being able to unify pre- and post-login data, product managers can develop a much clearer picture of the full user journey, identify pain points and blockers, and optimize user flows to maximize the likelihood of conversion.
Privacy teams manage compliance more easily
With the ability to determine how user profiles are created and updated, privacy teams can tailor identity strategies to align with legal requirements before they are implemented. Additionally, having all of a user’s attributes and behavioral events within a single profile makes it much easier for privacy teams to respond to Data Subject Requests (DSRs) in a timely and cost-efficient manner. Without a seamless automated process for handling DSRs, this process costs organizations an average of $1,524 per request, according to Gartner.
Engineers no longer have to build and maintain identity resolution themselves
For data engineers, building the data pipelines that power identity resolution is no small feat. Depending on the scale of an organization’s customer data, unifying data points across channels in real time can require sizable teams of developers wholly dedicated to this task. Offloading the process of identity resolution to mParticle will alleviate data engineers of this ongoing burden, and free these teams up to focus on core features and business initiatives. This is exactly the path that engineers at Reverb decided to pursue when they realized that their homegrown data pipelines were becoming unmanageable.