Why and how you should rethink profile merging

When marketers get too caught up in chasing the “golden record” in a customer data platform (CDP), they can allow “identity” to foul up their use cases. So let’s look at why creating a single customer profile in your CDP isn’t always ideal and how you can develop the correct procedures for merging records.

When creating a ‘golden record’ ruins the customer experience 

Sometimes, stitching together all of a customer’s information into a single profile can accidentally interfere with your use cases. Let me illustrate.

While planning a family trip, I added my daughter Anne as a guest on the reservation through her personal email address. But she received a reminder about the trip from the travel company in her work email, which made her nervous. Why did they send the reminder to her work email? Who told them about her work email?  

Near as I can tell, this is what happened. Anne had created an account with the travel company using her work email for a work-related event. Somewhere along the way, the travel company added her personal email to that profile. When I added her personal email to the guest list, the travel company attached that action to her profile, so when it came time to send out a reminder, it used the default email in that profile, which was her work address. In other words, in an over-zealous attempt to create a “golden record” for Anne, they forgot the purpose of the use case: to send a reminder to the guest email that’s entered for the event. 

Take another example. Joe is a good customer. He’s an office manager, and he buys things from your store for his company. But he has a side hustle and buys many of the same things for personal use. He keeps those accounts separate, using separate email addresses. Merging those records doesn’t help your relationship with Joe. It annoys the heck out of him and gets him in trouble with accounting. 

Dig deeper: The myth of the single customer record

And then there’s my experience. I work as a consultant for many different companies. Sometimes I need accounts on the same service for different clients on different email addresses. Some services won’t allow a customer to have multiple accounts with the same phone number for two-factor authentication. So I must find a workaround that doesn’t help the service provider or me. 

These are all examples where merging records around a person can ruin a customer experience. On the other hand, there are instances where you better merge the records. For instance, if you’re a restaurant delivering food and know that Sam has an allergy, you must ensure that information migrates across all Sam’s accounts. 

Merging customer records: When to do it and how

The bottom line is clear: use cases are more important than identity. But how do you know when and what to merge? I’ve created two frameworks to work through these issues: the device framework and the person framework. By thinking through each use case with both frameworks, you can develop the correct procedures for merging records. 

Device framework 

The device framework is how most people work through customer data issues. 

Device profile: A device makes a request to your site. Your CDP creates a profile for that device and collects information about it. At this level, you can segment on things like operating system, geography, screen size, etc. 

Activity: If that device makes multiple requests, you can enrich the profile with other information, such as the kind of content accessed. With this activity information, you can segment on things like “likes videos” or “accesses tax content.” 

Identifiers: Some of the device’s activities help to narrow down who is behind that device. For example, a device might make a request to your site after clicking on one of your emails. That helps to create narrower segments and, in some cases, helps you to identify the person. Identifiers can be used to create powerful segments, like “everyone who is registered for our e-newsletter.” 

Person: Some identifiers make a strong connection to a person, while others only hint at the person’s identity. As you collect identifiers, you can sometimes resolve the profile down to a particular person with more or less certainty, depending on the nature of the identifiers you have collected. Once you have a profile identified with a person, you can develop use cases such as presenting renewal offers near expiration. 

People

The person framework helps you avoid the abovementioned problems, like Anne’s concern about misusing her work email or my troubles with two-factor authentication. This framework requires us to step out of a data-centered world and think about the real lives of actual people. 

Person: Rather than starting with a device profile and trying to resolve it down to a person, we start with a person and imagine how that person behaves in the real world. Let’s return to Joe, your good customer who purchases office equipment for work and his home business. 

Devices: Joe has two phones: one from the office and one for personal use. He’s careful to do office work on one and home/personal work on the other. Joe also has an office PC but a Mac at home. Again, he uses one for office work and the other for his own ventures. 

Identifiers: Joe is cautious about keeping things separate. His office email is for office work, his personal email is for friends and family and he has another email address for his side hustle. Joe does not want these merged or confused. 

Personas: Rather than thinking of Joe as a single person, you have to think of Joe’s three distinct personas: Office Joe, Personal Joe and Side Hustle Joe. 

Dig deeper: 19 CDP use cases that can annoy or engage your customers

Using these frameworks for your use cases 

Now that we have the basics let’s take one use case and work it through both frameworks. The use case is: “Send relevant job listings to all mechanical engineers who opt into our job postings email.” 

Device framework 

The top of the device funnel doesn’t help much with this use case because we can’t identify mechanical engineers by what kind of device they use. Once we get to the activity level, we can find profiles that frequent content relevant to mechanical engineers.

We can use on-site quizzes or simple questionnaires to gather identifiers. In this case, job title. Once we have the job title, we can create a segment of mechanical engineers and promote the “sign up for job listings for mechanical engineers” email list. 

That’s good enough for this use case. We don’t need to resolve identity down to the person, although a name might be suitable for personalizing the emails. Resolving things down to the person might create a problem, as we’ll see. 

Person framework 

Julia, our mechanical engineer, works for a company that doesn’t take kindly to people looking around for new gigs. The IT department monitors all the emails that come to office addresses. Because of this, Julia is careful to keep her work and personal lives separate. 

While she only has one laptop, she does all her office work in Chrome and all her personal browsing (from home) in Firefox. She signs up for the job posts email on her personal account, but not on her work account. 

If an overzealous data scientist merged these two accounts into one profile for Julia and started sending the job-post emails to Julia’s work address, Julia would not be happy. 

Rethink profile merging with these frameworks

People are more complicated than your data structure recognizes, so it’s essential to view your use cases from two perspectives: 

• From the data side (the device framework).
• By imagining the life experiences and concerns of real people who often act online through different personas. 

Make sure you structure your data, merge rules and use cases to allow people to act within whatever personas suit them. Don’t try too hard to create a single profile for each person in every case.