新媒体在线

发布投稿

关注微信

客服热线

广告位招商
qq:1219071365
备注:新媒体在线,广告位投放
广告
广告

B端用户画像:ID Mapping

2021-10-02 10:03:00

来源:cnwebe   作者:一个数据人的自留地

阅读:495

评论:0

[摘要] 一、引言在《一篇文章让你掌握企业画像》一文中,提到企业画像对于“达到一定用户规模的面向中小型客户的SaaS产品公司”是很有必要的。不过,建立企业画像的基础,首先是用户ID mapping的问题。今天我们就来讲讲这个话题。二、为什么要做ID mapping假设这样一个场景:第一天,客户张三在公司电脑上看了一下产品详情页

B端用户画像:ID Mapping


一、引言


在《一篇文章让你掌握企业画像》一文中,提到企业画像对于“达到一定用户规模的面向中小型客户的SaaS产品公司”是很有必要的。不过,建立企业画像的基础,首先是用户ID mapping的问题。今天我们就来讲讲这个话题。


二、为什么要做ID mapping


假设这样一个场景:



    第一天,客户张三在公司电脑上看了一下产品详情页;
    第二天,他在手机上关注了公司的一个微信公众号;
    第三天,张三在手机上看了三篇微信公众号文章;
    第四天,张三在手机上下载了一个产品说明文档,下载的时候他输入了自己的邮箱;
    第五天,张三在公司电脑上申请了试用,试用的时候他用的账户就是他的邮箱,并且同时输入了手机号;
    第六天,他用手机拨打了客服热线,咨询一个产品问题。

如果没有ID mapping,客服人员就无从知道他已经看过产品、公众号,试用过产品,无法在第一时间准确获得张三的购买意向。并且随着营销渠道越来越多,如果不去识别碎片化的个人,客户的行为就被割裂,从客户角度考虑会影响客户体验。


从公司角度,我们也无法知道评估营销渠道的有效性,即客户买这个产品到底是因为只是看产品详情页,还是看了公众号,还是二者皆有。


三、如何做B端的ID mapping


既然需要解决,我们或可采取两个方案并举。


方案1:在营销阶段尽可能多地捕捉用户信息,比如在下载产品说明文档或者试用时,不仅要求客户填写邮箱,还需要填入手机号。这也是为什么很多B端产品的下载或者申请demo要求用户输入更多信息的原因。当然,这个方案的缺点是客户很可能在这个阶段就放弃继续探索。


方案2:可参照目前C端的用户画像中的解决方案,利用一定的规则把割裂的行为串联起来。仍然以上述用户张三为例,在不同行为中,张三留下了不同的标识,利用不同行为中共同的标识,可以很容易地找到行为间的关联关系,下图红色所示:


B端用户画像:ID Mapping


第一天,获取了一个用户,我们把Cookie ID 和设备ID1 作为用户标识保存起来,创建用户001。


第二天,又获取了一个用户,我们把设备ID2和微信号作为用户标识保存,创建用户002。


第三天,我们发现这个用户的设备ID2和微信号和用户002相同,我们初步判断两个行为背后是一个人。于是把这两个行为关联到一个人上。


第四天,我们发现这个用户的设备ID2和用户002的设备ID2相同,我们初步判断两个行为背后可能是一个人,于是把第四天留下的邮箱作为用户002的标识保存起来。至此,用户001 和用户002 还未建立联系。


第五天,我们发现用户邮箱和用户002相同,设备ID1和cookieID 和用户001相同。判断用户001和用户002可能是一个人。于是将用户001 和用户002 合并。


合并后的用户拥有以下ID:



Cookie:Cookie ID;
设备号:设备ID1,设备ID2;
微信:微信号;
邮箱:邮箱;
手机:手机号。

第六天,我们发现,手机号和合并后的用户一致,于是判断打电话的行为和过去的行为背后是一个人。


细心的读者可能会发现,你这有漏洞呀,比如第三天和第四天的行为,设备ID2很可能是被多人使用的,如果是这样,邮箱和微信号之后无法建立联系,在后面也就无法把用户001 和用户002 关联起来了呀。


为解决这个问题,就需要我们从业务角度建立一些规则。这里就以笔者曾经使用过的Segment 为例说明(Segment号称是#1 CDP-Customer Data Platform to Manage Customer Data)。


Segment 有一个 three Identity Resolution rules——即三大用户标识识别规则,分别是:


1)Block Values. 管理员可设置某些值为无效值,比如公司内部用的测试账户ID,某些一眼看上去无效的账户ID,比如0000@000.com。


2)Limit:即管理员可以设置某个类型的ID一个用户最多在多长时间内可以拥有几个。比如cookie ID设为一天最多可以有10个,我想除非是测试,否则没有哪个正常的用户会一天清理缓存重新生成cookie 超过10次。比如设备ID, 我们估计一下换手机换电脑的频率,一个用户一年应该不会超过2次,可以设Limit 为2个每年。


这其中当然有误差,所以我们也要看具体业务场景。作为用户画像工具,我们应该允许管理员灵活设置。


3)Priority:即当某类标识ID超出Limit规定的数量时,priority决定由哪个标识留下作为新创建用户的标识。


引用原文例子说明一下,假如系统设立的limit 和 priority 分别如下:


B端用户画像:ID Mapping


假设系统中已有一个用户, user id为abc,拥有邮箱tom@tom.com。此时又来了一个新用户,user id是 def, 同样拥有邮箱tom@tom.com。因为user_id的limit 为1,而user_id的优先级高于email,那么我们对email 进行降级,只利用user id def 来查找是否有已有用户存在,如果没有,就新建一个用户,user_id为def。


我们用这三个规则套路一下张三的例子:


B端用户画像:ID Mapping


第一天,我们把Cookie ID 和设备ID1 作为用户标识保存起来,创建用户001;第二天,我们把设备ID2和微信号作为用户标识保存,创建用户002;第三天,我们发现这个用户的微信号和用户002相同,微信号只能有一个,我们把这两个行为关联到一个人用户002上。


第四天,我们发现这个用户的设备ID2和用户002的设备ID2相同,因为用户002目前还没有邮箱,把第四天留下的邮箱作为用户002的标识保存起来。


第五天,我们发现用户邮箱和用户002相同,而邮箱只能有一个,所以把行为关联到002上,同时增加了手机号。并且发现设备ID1和cookieID 和用户001相同。且cookie ID 和设备ID 的limit可以是多个,于是将用户001 和用户002 合并。


第六天,发现打电话进来的用户手机号和合并后的用户一致,于是判断打电话的行为和过去的行为是一个人。


当然,识别碎片化的人还可能会有更多场景,这里我们只是学习其中一种,我们还经常遇到比如APP弹出一个加密的被识别出来的可能匹配的账户,让用户确认,是否合并两个用户,这也是一种方法,这其中要同时考虑信息安全和客户体验。


四、总结


本文讲述了B端用户画像中ID mapping的必要性,并以Segment为案例,提供了一个相对比较通用的解决方法供大家参考。但实际上ID Mapping的方法还有很多,大家也可以参考《阿里/网易/美团/58用户画像中的ID体系建设》学习。如有纰漏,欢迎指正。


参考文章


Segment帮助中心:


https://segment.com/docs/personas/identity-resolution/identity-resolution-settings/

    广告

关键词: 用户 画像

人已打赏

请关注下方二维码,获得更多信息!

      ×

      打赏支持

      打赏金额
      • 1元
      • 2元
      • 5元
      • 10元
      • 20元
      • 50元

      选择支付方式:

      打赏记录
      ×

      精彩评论文明上网理性发言,请遵守新闻评论服务协议

      共0条评论
      加载更多
      广告
      广告位招商
      qq:1219071365
      备注:新媒体在线,广告位投放
      广告

      猜你喜欢

      更多
      如何提升新用户留存率?

      问题1:什么是新用户?看到这个问题,很多同学可能都会有点懵,新用户不就是NU吗?当天注册的用户不就是新用户了吗?!首先,这个回答没毛病。但是,秉持着可量化可操控的原则,我们来重新审视,具体“落地”一下“新用户”。从流程上来说,“新” 这个状态是从下载App到注册App这一段旅程。我们说的当天注册的用户,是

        广告
        广告