- 数据分析
- 数据治理
- 产品解决方案
- 行业解决方案
- 案例
- 数据资产入表
- 赋能中心
- 伙伴
- 关于
时间：2022-02-02来源：社会活动家浏览数：826次
导读：OneID可以说是企业数字化改革中客户运营的核心基础设施，通过把客户在不同业务板块，不同端的信息碎片进行连接，萃取指标和画像，构建全流程客户之旅，再结合场景选择有效的运营手段，重新触达客户并洞察真需求，常被用于客户营销和售后场景，其他领域的实践可在本文稍后看到。 《我的OneID的实战回忆录》主要结合本人在OneID实战经历，重点阐述它的起源，应用场景，建设难点及数澜实践。
2019年阿里云峰会上海站《数据中台实践分享》中对OneID进行官方定义，OneID是以商业要素资产化为核心，实现全域链接、标签萃取、立体画像的数据应用服务整体解决方案。简单可以理解为，通过业务规则和数据技术实现围绕一个“自然人”ID的打通（如下图）。举如你用137***注册了一个账号，下单的时候收货地址联系方式留的是你朋友133***，这个时候系统会自动关联认为你有两个手机号，137***（常用），133***（偶尔使用），因此大数据在判断什么商品适合推荐给你的时候，会考虑133***背后的偏好。
针对ID描述不仅包括常见实体ID如UserId；同时包括类似行为ID，如浏览器CookieID、设备标识符IMEI/IDFA、MAC；属性ID，如Email，Mobile；外部ID，如WeiboID、高德POI_ID,当时项目共涉及20+类ID的打通和归一 。
1.0描述过去、报告结果
企业级数据仓库 + 统计分析工具，典型场景为集团管理驾驶舱、数据参谋等
2.0 Data Driven业务
基于大规模分布式存储和计算、机器学习数据挖掘，典型场景为个性化实时推荐、个人小额贷款、数据开放平台等
3.0运营数据
数据基设施赋能更多Data Driven业务，当时典型项目为数据地图、TCIF、冰火鸟、5K和Base项目
数据服务团队（风剑）目标是全面构建DAAS能力层，打造全集团能力最全面的数据服务体系TCIF（淘宝消费者信息工厂），以统一用户识别ID（OneID）、统一用户识别（IDMapping）能力为核心的“人群的精准定义及人的精准营销”的解决方案”，服务好包括集团内外的需要用到数据或数据服务的各个业务或团队；，如御膳房、阿里妈妈、支付宝、天猫、高德和UC等。作为当时的核心项目：用户识别中心UUIC（Unified User Identification Center），具备两大核心能力：统一用户AID（Alibaba ID，后改为OneID）和统一用户识别能力（IDMapping）。
如上图，UUIC（含AID）主要目标就是不断的扩大“可被定向流量”和“正在被定向的流量”，最终让数据真正发挥价值，详细说明如下：
全网流量：
站内流量+站外流量，站内流量即阿里系本身的流量，站外流量包括外部广告的流量和收购或投资相关公司的流量。
可被定向的流量：
有能力进行识别的流量，目前PC为ACOOKIE，无线端为UTDID，IMEI，IDFA 等，后期希望替换为 AID，用来解决上述方式带来的营销上碎片化问题。
正在被定向的流量：
目前已经在使用 UUIC 接口进行识别的流量，因为识别的源本身带有标签信息，说明这些流量已经能够产生价值。
数据和服务（效果>1）：
通过使用数据和数据服务提高业务原先的使用效果。
2.以往场景
个性化推荐/跨屏/跨多渠道推荐： 个性化推荐业务，需要根据每个用户的偏好提供宝贝导购，从而提升GMV； 痛点：对于非登陆（含首次）、多渠道，不清楚这些用户的偏好，从而无法提供个性化推荐；（部分展示内容涉及互联网广告DSP、RTB和TANX等技术, 这里就不展开阐述。）
微博PC版-淘广告推荐中式装饰画
DMP定向人群包管理&推送
DMP融合UUIC能力后，品牌主在其他渠道获得的用户信息，完全可在阿里流量体系完成重定向，如线下运营活动获取Mobile，或 通过AP采集设备MAC通过UUIC-IDMapping均识别成转成AID，此类技术当时用到无线广告领域，针对任意Mobile基本可实现90%的识别率，其他任意无线流量70%在DMP都可以被识别到，如此高的识别率，绝对是当时广告投放的核武器了。
“来往”好友推荐（钉钉前身，关系网络挖掘）
来往好友推荐业务，需要充分挖掘用户之间的关系，找到你可能认识的TA，从而拉动好友关系量级；通过UUIC-IDMapping服务，将手机号码转换成来往账户信息；（此项关系度识别和量化技术还可以用于安全领域）LBS指纹（基于GeoHash的POI识别）
最早源于国外一篇论文，大意是根据常用6个GPS位置点，可识别用户的准确率在70～80%左右，基于测试验证，启动了UUIC的分支项目（UUIC-北斗项目），目标通过覆盖千万用户达到通过POI_ID的识别，具体场景为，如果你使用了高德或百度SDK的App软件，如某些O2O软件，在不获得任意信息如设备id或手机号下，能识别背后用户的准确率为70%（早期安卓手机可自动获取GPS信息并上传）。
3.建设难点
业务高要求的技术选型
阿里妈妈业务方给UUIC的要求是单点发码服务（RT<2ms，QPS>60万），在线识别服务（5W以下识别不能超过2秒），离线识别服务（根据数据量而定，一般不超过10分钟），所有的数据刷新必须在早上7点之前完成。而14/15年的基础设施，在ODPS上基于类Spark迭代技术框架并不成熟，MR计算框架（SQL+Java+Python）+在线服务（TAIR）基本就是当时的唯一选择了。针对UUIC涉及20+key，上千亿关系对处理，部分算法子模型需要设置9999个Map或Reducer才能运行出结果，完成时间往往都在凌晨5点了，给最终数据服务化（ODPS->TAIR）的时间还是非常紧张的,而且不允许出错。当时项目组也上使用了各种优化手段，如DMP7点数据基线，基线下的任务优先分配计算资源；处于性能考虑，需要ODPS安全组给UUIC集群特别的权限方便调用接口等等。业务频繁变更下的代码工程量问题
在动态识别算法之前，建设自动化数据接入框架，一方面ID所涉及的数据源业务的变更频繁，关系对接入需要不断调整，如某业务日志中的Mobile-MAC关系对需要添加，同时删除此日志中的MAC-UserID的关系等等，另外一方面因计算量实在太大影响数据产出时效，不是所有的ID和ID的识别都是支持的，因此需要有一个配置化的方式来记录哪些ID需要接入，哪些ID和ID之间需要识别服务。
业务不同属性规则下的权重问题
上面谈到的一个是技术问题，一个是数据工程化问题，那权重问题就是非常重要的业务问题了。
其他
其它注意事项，比如如何设计OneID本身，而不是简单的一个字符串，当时采用的base64 编码样式Ib5anmuEdazNdCoV8xIToA==\n，包括OneID和OneID-Property；比如如何让识别服务及背后的UserProfile完全自助化，而不是一个一个业务方对接，这里就有关数据资产服务化的设计了。总之，OneID还是一个系统性复杂建设问题，涉及方方面面，如安全又是一个大课题（数据如何加盐严？加密），缺少一句过渡。期间也多次被集团怀疑叫停，当时小组也是熬战2年多，UUIC才初步打开局面，后面的故事大家都知道了，阿里云推出数据中台建设方法论OneID/OneData/OneService。以下实践的方案和产品都属于数澜DAAS能力范畴，根据这几年的实践，总结三个趋势如下：
趋势一：企业私域流量运营（CDP）的标配在传统行业的零售板块这样的Case非常常见，如地产（住宅）、制造（汽车）、证券、教育和新零售等，如果从以往的实践经验来看，完全是降维打击，无论是数据量和维度，根本不是一个量级，但ID还是会发现一些变化，如微信OpenId\UID\头像，OneID同人收敛模型不再是一个自然人，而是一组人，如一个家庭或一个小区，如生鲜、医药的营销运营都可以是以家庭为单位。
趋势二：企业全域OneID的统一建设需求OneID是一个同人模型，主要是面向营销运营场景，也有客户定义为分析领域的ID，再和制造（汽车主机厂）客户和金融（保险）客户一些Case中，已经多次提到如何把业务如何围绕用户全周期标记，不管你在内部系统HRM中，还是在客户管理CRM中或互联网部某个APP中。这里面就要对OneID的设计重新进行考虑。
趋势三：从OneID到弱ID智能关联弱ID技术不在仅仅关注“客户/用户”，而会扩展到其他业务对象，如运营商基站的位置校准分析，因为不是所有的基站运营商都知道在哪；场景也从营销场景扩展到风控场景，如业务穿透模型（财务应收应付），因为不是所有的收款付款都会在一个系统完成；对于ID的本身也延展到行为识别，如期货关联账户问题分析，因为一个人或团队可能操作多套账号进行违法操作，但可通过识别行为，如密码输入规律、App用户操作路径等加上AI算法是可以发现是同一人或同一组人操作。类似的场景还可以在安全领域，如一些人车轨迹伴随等，因信息披露这里就不在介绍了。
