Guide: setting up identity resolution in mParticle vs Tealium in under an hour

While comprehensive platform evaluations are essential, the initial setup for a core function like identity resolution can be a significant time sink. This guide provides a procedural comparison for establishing a baseline deterministic identity graph in both mParticle and Tealium, focusing on the developer workflow to achieve a functional state within an hour. The assumption is a web environment with authenticated users.

The primary architectural difference lies in the initial identity stitching strategy. mParticle employs a `logical` user model where you explicitly set the `MPID` via the SDK after a user is identified, whereas Tealium uses a `Visitor Stitch` which is triggered by passing a common key (like `customer_id`) within the data layer.

### mParticle: SDK-Centric Identity Merge
The process hinges on calling `setUserIdentity` and subsequently `identity.login` with the same identifier. The SDK handles merging server-side.

1. **Initialization & Configuration**
First, load the Web SDK with your workspace key.
```javascript
// mParticle Web SDK Snippet
window.mParticle = {
config: {
identityCallback: function(result) {
console.log("Identity callbacks:", result);
},
// ... other config
}
};
(function(){/* snippet code */})();
```

2. **Identifying the User**
Upon user authentication, call `setUserIdentity` and then `identity.login`. This is the critical step for merging anonymous and known user activity.
```javascript
// Executed post-login
mParticle.setUserIdentity("user@domain.com", mParticle.IdentityType.Email);
mParticle.identity.login({
userIdentities: {
email: "user@domain.com",
customerid: "12345"
}
});
```
The previous anonymous profile (and its associated events) will merge into the identified user profile based on the provided `Email` identity.

### Tealium: Data Layer-Driven Visitor Stitch
Tealium's identity resolution is configured primarily in the TIQ (Tealium iQ) interface, but it is activated by the data you send.

1. **Create a Visitor Stitch Key**
* In your Tealium data layer object (`utag_data`), ensure you have a consistent key for the authenticated user ID (e.g., `customer_id`).
* Within the TIQ interface, navigate to the Visitor Stitch tool and create a new stitch key. Select the `customer_id` variable (or equivalent).

2. **Triggering the Stitch**
The stitch occurs automatically when events are fired containing the stitch key. The crucial point is to update the data layer *before* the tag fires.
```javascript
// Update the data layer with the authenticated ID
utag_data["customer_id"] = "12345";
utag_data["email"] = "user@domain.com";
utag_data["event_name"] = "user_login"; // or a similar event

// Then fire the view/event tag
utag.view();
```
Upon processing, Tealium will associate all data with the new, stitched visitor ID, linking past and future activity.

### Key Comparison Points
* **Control Flow:** mParticle requires explicit SDK method calls (`identity.login()`), offering a programmatic, event-driven control. Tealium's method is declarative, relying on the presence of a key in the data stream, which can be simpler but less explicit.
* **Profile Merge Timing:** In mParticle, the merge is triggered immediately by the `login` call. In Tealium, the stitch is processed asynchronously on data receipt; there may be a slight latency before the unified profile is available for audience activation.
* **Initial Setup Overhead:** Both require initial UI-based configuration (mParticle: creating inputs/setting identity types; Tealium: defining the stitch key). The actual code implementation for a basic case is similarly minimal.

For a proof-of-concept implementation, both platforms can indeed be configured within the stated timeframe. The choice often reduces to whether your team prefers an SDK-driven or a data-layer-driven paradigm for identity management. For more complex, multi-key or probabilistic stitching, the configuration UI in both tools becomes the dominant time investment.

— hannah