伍拾叁- 基于大数据的会员识别基础 - 泛会员识别体系
一、会员系统演变
1.1) 什么是会员
如何识别客户
,是企业对客户运营
的重点主题之一。
以某咖啡店的会员体系为例:
- 最早是以 会员卡 作为单个会员的识别
- 然后以 电邮 为单个会员的识别
- 最后是以 手机号码 为单个会员的识别
但在电子支付的流行、社交软件的兴起,以及更深入的用户画像分析需求下,如何更主动
的识别会员、更全面的分析会员行为
成为了重点的课题。
1.2) 泛会员
是否曾有一种经验,刚计划去旅游时,飞猪
就马上自动推荐目的地的旅游景点,淘宝
自动推荐目的地的特产,神州租车
告诉你目的机场 / 火车站的自驾取车点,Airbnb
马上告诉你目的地的民宿,大众点评
马上推荐当地的网红打卡点信息给你。
而这一切都不是你自己去主动查找的,你仅仅是被某些搜索平台告诉各公司你的小心思,以及你的某些信息
,而各企业就自动会根据得到的信息迫不及待的告诉你们他们能在你这个小心思之中,怎么去赚你的钱为你提供服务 。
二、分析会员行为的意义
您是否有遇过相似的问题?
- 举行完一场促销活动想知道是否有效果
- 更换了线下实体店铺装修后想知道客户是否乐意接受
- 企划新产品时,是否能直接从品牌的原客户引流
- 通过何种方法对客户进行最有效的接触
- ……..
如果没有办法串起一个客户
所产生的所有记录
,我们连上述一个问题都无法解答。
三、大数据不是大量数据-数据示例
如果数据来源单一
,单纯是数据量级很大,是不构成 大数据
的。所谓的大数据所表示的是数据来源多样
、数据类型不统一
、内容不全。
本文针对的是如何识别同一个客户
以下我们建立起一个数据实例:
No. | 安卓 ID | IDFV | CRM Card No. | Wechat Union ID | Phone No. |
---|---|---|---|---|---|
1 | oWx1024 | ||||
2 | 9382100 | ||||
3 | 9382100 | 13800 | |||
4 | JJKKKJJ | oWx1024 | 13900 | ||
5 | IOIO111 | ||||
6 | IOIO222 | oWX0064 | 13700 | ||
7 | IOIO333 | 13800 | |||
8 | oWx2048 | 15900 | |||
9 | IOIO222 | 9440000 | |||
10 | 13800 | ||||
11 | 13100 | ||||
12 | oWx1024 | 13200 | |||
13 | oWx2048 | ||||
14 | 9440000 | oWx8096 | |||
15 | oWx8096 | 13400 | |||
16 | 9440000 | 15900 | |||
17 | FFFFFJJ | ||||
18 | FFFFFJJ | IOIO111 | |||
19 | IOIO111 | 9382100 | |||
20 | IOIO111 | 13600 | |||
21 | adJJJJ | ||||
22 | oWx8096 | 15800 | |||
23 | oWx0512 | 13900 | |||
24 | oWx0256 | 13200 | |||
25 | JJKKKJJ | 17800 | |||
26 | IOIO888 | oWx0128 | 13400 | ||
27 | SSSSSI | IOIO999 | oWx0128 |
四、搭建流程
4.1)第一阶段 - 接入/整合
4.1.1 - 确定主 ID
在此例子中,我们先设定 Phone No.
设置为 主标识(UUID)
。
4.1.2 - 确定各平台主次顺序
如果我们不先预定各平台标识的主次顺序,我们就会陷入从哪里出发去找主标识(UUID)
,就会得出不同结果,如示例:
No. | 安卓 ID | IDFV | CRM Card No. | Wechat Union ID | Phone No. |
---|---|---|---|---|---|
6 | IOIO222 | oWX0064 | 13700 | ||
9 | IOIO222 | 9440000 | |||
16 | 9440000 | 15900 |
第6
条以及第16
条可以很容易的标识为独立的一个人,但当我们在处理记录9
时,我们是应该先以CRM Card No.
平台标识进行识别还是先以IDFV
进行识别,就会得出不同的结果。
所以在前期我们必须标识不同的优先级
,并在匹配记录对应的主标识时严格按照优先顺序来匹配。
4.1.3 - 给出各标识对应唯一的主ID
当各平台标识可能对应多个 主ID
时,我们必须当最新产生的记录为最准确的(可以理解每次对应记录的不同为变更
)。
如示例:
No. | 安卓 ID | IDFV | CRM Card No. | Wechat Union ID | Phone No. | Last Update Date |
---|---|---|---|---|---|---|
4 | JJKKKJJ | oWx1024 | 13900 | 2021-4-5 | ||
12 | oWx1024 | 13200 | 2021-5-1 | |||
25 | JJKKKJJ | 17800 | 2021-3-8 |
当我们在再次遇到 oWx1024
这个 Union ID 时,我们需要认定这个对应的唯一一个 Phone No.
: 13200
。
Wechat Union ID | Phone No. |
---|---|
oWx1024 | 13200 |
同理对 安卓 ID
进行相同处理
安卓 ID | Phone No. |
---|---|
JJKKKJJ | 13900 |
4.2)第二阶段 - 融合
4.2.1 - 融合流程
抽出实例数据如下:
No. | 安卓 ID | IDFV | CRM Card No. | Wechat Union ID | Phone No. | Last Update Date |
---|---|---|---|---|---|---|
6 | IOIO222 | oWX0064 | 13700 | 2021-5-4 | ||
9 | IOIO222 | 9440000 | 2021-4-3 | |||
14 | 9440000 | oWx8096 | 2021-4-1 | |||
15 | oWx8096 | 13400 | 2021-3-14 | |||
16 | 9440000 | 15900 | 2021-2-28 | |||
22 | oWx8096 | 15800 | 2021-2-3 | |||
26 | IOIO888 | oWx0128 | 13400 | 2021-2-2 | ||
27 | SSSSSI | IOIO999 | oWx0128 | 2021-1-3 |
以上记录,会根据时间的排序,得到以下这张主接触表
:
Phone No. | 安卓 ID | IDFV | CRM Card No. | Wechat Union ID |
---|---|---|---|---|
13700 | IOIO222 | 9440000 | oWX0064 | |
15900 | ||||
15800 | ||||
13400 | IOIO888 | oWx0128 |
得到如下对应表格:
- 安卓ID
Phone No. | 安卓 ID |
---|---|
13400 | SSSSSI |
- IDFV
Phone No. | IDFV |
---|---|
13400 | IOIO999 |
13400 | IOIO888 |
13700 | IOIO222 |
- CRM Card No.
Phone No. | CRM Card No. |
---|---|
13700 | 9440000 |
- Union ID
Phone No. | Wechat Union ID |
---|---|
13700 | oWX0064 |
13700 | oWx8096 |
13400 | oWx0128 |
JSON 格式如下
{
"UUID":"aaaa",
"Main_Contact":{
"Phone_No":"13700",
"Android_ID":"",
"IDFV":"IOIO222",
"CRM_Card_No":"9440000",
"Wechat_Union_ID":"oWX0064"
},
"All_Android_ID":[],
"All_IDFV":["IOIO222"],
"All_CRM_Card_No":["9440000"],
"All_Wechat_Union_ID":["oWX0064","oWx8096"]
},
{
"UUID":"bbb",
"Main_Contact":{
"Phone_No":"15900",
"Android_ID":"",
"IDFV":"",
"CRM_Card_No":"",
"Wechat_Union_ID":""
},
"All_Android_ID":[],
"All_IDFV":[],
"All_CRM_Card_No":[],
"All_Wechat_Union_ID":[]
},
{
"UUID":"ccc",
"Main_Contact":{
"Phone_No":"15800",
"Android_ID":"",
"IDFV":"",
"CRM_Card_No":"",
"Wechat_Union_ID":""
},
"All_Android_ID":[],
"All_IDFV":[],
"All_CRM_Card_No":[],
"All_Wechat_Union_ID":[]
},
{
"UUID":"ddd",
"Main_Contact":{
"Phone_No":"13400",
"Android_ID":"",
"IDFV":"IOIO888",
"CRM_Card_No":"",
"Wechat_Union_ID":"oWx0128"
},
"All_Android_ID":[],
"All_IDFV":["IOIO999","IOIO888"],
"All_CRM_Card_No":[],
"All_Wechat_Union_ID":["oWx0128"]
}
4.2.2 - 隐含逻辑
必须以时间为先,且假定如果客户的标识并未能获取 主标识
即为已经解绑。
如下图:
4.2.3 - 异常排查
当某个主标识
绑定了超过5个平台标识,即可认为该 主标识
可能是公用机或为作弊行为。
当某个主标识
绑定了超过20个平台标识,即可认为为内不某些平台标识为默认编号,需排查。
这个阈值可以根据企业业务的不同而进行适当调整,如游戏平台的小号排查等。
五、后续
当能建立如此泛会员
体系后,后续的分析便可以此为出发点,更框出客户的真实行为,以便进行更多维度、可能的分析。