为什么以及如何重新考虑配置文件合并

当营销人员过于追逐客户数据平台 (CDP) 中的“黄金记录”时，他们可能会允许“身份”扰乱他们的用例。 因此，让我们看看为什么在您的 CDP 中创建单一客户资料并不总是理想的，以及您如何开发正确的合并记录程序。

创建“黄金唱片”会破坏客户体验

有时，将客户的所有信息拼接成一个个人资料可能会意外地干扰您的用例。 让我举例说明。

在计划家庭旅行时，我通过女儿安妮的个人电子邮件地址将她添加为预订客人。 但她在工作邮件中收到旅游公司的旅行提醒，这让她很紧张。 他们为什么将提醒发送到她的工作邮箱？ 谁告诉他们她的工作电子邮件？

据我所知，这就是发生的事情。 安妮使用她的工作电子邮件在旅游公司创建了一个帐户，用于与工作相关的活动。 在此过程中，旅游公司将她的个人电子邮件添加到该个人资料中。 当我将她的个人电子邮件添加到客人列表时，旅游公司将该操作附加到她的个人资料中，因此在发送提醒时，它使用该个人资料中的默认电子邮件，即她的工作地址。 换句话说，在为 Anne 创建“黄金记录”的过分热心尝试中，他们忘记了用例的目的：向为活动输入的来宾电子邮件发送提醒。

再举一个例子。 乔是个好顾客。 他是一名办公室经理，他为他的公司从您的商店购买东西。 但他有副业，会购买许多相同的东西供个人使用。 他使用不同的电子邮件地址将这些帐户分开。 合并这些记录无助于您与 Joe 的关系。 这惹恼了他，让他在会计方面遇到麻烦。

深入挖掘：单一客户记录的神话

然后是我的经验。 我在许多不同的公司担任顾问。 有时我需要为不同电子邮件地址的不同客户使用同一服务的帐户。 某些服务不允许客户拥有多个具有相同电话号码的帐户以进行双因素身份验证。 所以我必须找到一个对服务提供商或我都没有帮助的解决方法。

这些都是合并个人记录会破坏客户体验的例子。 另一方面，有些情况下您最好合并记录。 例如，如果您是一家送餐的餐厅并且知道 Sam 过敏，您必须确保信息在 Sam 的所有帐户之间迁移。

合并客户记录：何时进行以及如何进行

底线很明确：用例比身份更重要。 但是你怎么知道什么时候合并什么？ 我创建了两个框架来解决这些问题：设备框架和人员框架。 通过考虑两个框架的每个用例，您可以开发合并记录的正确过程。

设备框架

设备框架是大多数人解决客户数据问题的方式。

设备配置文件：设备向您的站点发出请求。 您的 CDP 为该设备创建配置文件并收集有关它的信息。 在此级别，您可以根据操作系统、地理位置、屏幕尺寸等进行细分。

活动：如果该设备发出多个请求，您可以使用其他信息丰富配置文件，例如访问的内容类型。 使用此活动信息，您可以根据“喜欢视频”或“访问税务内容”等内容进行细分。

标识符：设备的某些活动有助于缩小该设备背后的人员范围。 例如，设备可能会在点击您的一封电子邮件后向您的站点发出请求。 这有助于创建更窄的细分，在某些情况下，还可以帮助您识别此人。 标识符可用于创建强大的细分，例如“注册我们的电子通讯的每个人”。

Person ：一些标识符与一个人有很强的联系，而其他标识符只暗示这个人的身份。 当您收集标识符时，您有时可以或多或少确定地将个人资料解析为特定的人，具体取决于您收集的标识符的性质。 一旦您确定了某个人的个人资料，您就可以开发用例，例如在即将到期时提供续订优惠。

人们

person 框架可以帮助您避免上述问题，例如 Anne 担心滥用她的工作电子邮件或我的双因素身份验证问题。 这个框架要求我们走出一个以数据为中心的世界，去思考真实的人的真实生活。

人：我们不是从设备配置文件开始并试图将其分解为一个人，而是从一个人开始，想象这个人在现实世界中的行为。 让我们回到 Joe，他是您的好客户，他为工作和家庭业务购买办公设备。

设备：Joe 有两部电话：一部来自办公室，一部供个人使用。 他小心翼翼地用一个做办公室工作，用另一个做家庭/个人工作。 Joe 也有一台办公室 PC，但家里有一台 Mac。 同样，他将一个用于办公室工作，另一个用于他自己的事业。

标识符：Joe 对将事物分开持谨慎态度。 他的办公室电子邮件用于办公室工作，他的个人电子邮件用于朋友和家人，他还有另一个电子邮件地址用于他的副业。 乔不希望这些合并或混淆。

角色：与其将乔视为一个人，不如将乔视为三个不同的角色：办公室乔、个人乔和副业乔。

深入挖掘：可能会惹恼或吸引客户的 19 个 CDP 用例

将这些框架用于您的用例

现在我们已经掌握了基础知识，让我们以一个用例为例，并通过两个框架来处理它。 用例是：“将相关的职位列表发送给所有选择加入我们职位发布电子邮件的机械工程师。”

设备框架

设备漏斗的顶部对此用例没有多大帮助，因为我们无法通过他们使用的设备类型来识别机械工程师。 达到活动级别后，我们可以找到与机械工程师相关的频繁内容的配置文件。

我们可以使用现场测验或简单问卷来收集标识符。 在这种情况下，职务。 一旦我们有了职位名称，我们就可以创建一个机械工程师细分市场，并推广“注册机械工程师职位列表”电子邮件列表。

这对于这个用例来说已经足够了。 我们不需要将身份分解为人，尽管名字可能适合个性化电子邮件。 正如我们将看到的那样，将事情解决到人身上可能会产生问题。

人物框架

我们的机械工程师 Julia 所在的公司对四处寻找新工作的人并不友善。 IT 部门监控所有到达办公室地址的电子邮件。 正因为如此，朱莉娅小心翼翼地将她的工作和个人生活分开。

虽然她只有一台笔记本电脑，但她在 Chrome 中完成所有办公室工作，并在 Firefox 中进行所有个人浏览（在家中）。 她在她的个人账户上注册了职位发布电子邮件，但没有在她的工作账户上注册。

如果一位过分热心的数据科学家将这两个帐户合并为 Julia 的一个个人资料，并开始将职位发布电子邮件发送到 Julia 的工作地址，Julia 会不高兴的。

重新考虑与这些框架合并的配置文件

人们比您的数据结构所识别的要复杂得多，因此从两个角度查看您的用例至关重要：

• 从数据端（设备框架）。
• 通过想象经常通过不同角色在网上行动的真人的生活经历和关注点。

确保构建数据、合并规则和用例，以允许人们在适合他们的任何角色中行动。 不要太过努力地在每种情况下为每个人创建一个个人资料。

获取营销技术！ 日常的。 自由的。 在您的收件箱中。

企业电子邮件地址

订阅 加工...

见条款。