产品初创期间，需要分析天使用户的行为来改进产品，甚至从用户行为中得到新的思路或发现来调整产品方向；产品 growth 过程，通过对用户行为的多角度（多维）分析、对用户群体的划分以及相应行为特征的分析和比较，来指导产品设计、运营活动，并对市场渠道效果进行评估。

配合上 A/B 试验平台，可以加速产品的迭代，更快得到用户的真实反馈。同时，这些数据沉淀下来，对业务的数据仓库建设、数据智能应用等方面也能起到促进作用，比如做实时推荐，需要能更快获得用户尽可能多且明细的行为数据；做用户分类、意愿预测等机器学习业务，需要清洗过的规范化、结构化的数据做 training。

要能做用户行为的分析，就需要有一套用户行为数据采集、传输、处理、分析的基础设施，而埋点和分析平台就是在做这件事。业界大多产品都是通过嵌入到多个终端的 SDK 来采集用户行为数据，而后续的传输、处理等过程对需求方是透明的，这样可以以很低的成本，把数据的采集、清洗、沉淀工作做掉，为企业节省成本，提升数据驱动的效率。

在分析平台上，用户的行为定义会通过特定 Event 来标识，比如 “buttonClick”, “playMusic” 等。通常这些事件，是开发人员通过调用 SDK 提供的 API 来设置的，除了确定事件的名称外，还可以加入分析需要的自定义参数和取值，这个过程就是“埋点”工作。当然，还有一些工具/产品支持可视化埋点，这种方式不需要开发介入埋点，SDK 会自动去采集用户在各个终端上的行为。

可视化埋点是指开发人员除集成采集 SDK 外，不需要额外去写埋点代码，而是由业务人员通过访问分析平台的 圈选 功能来“圈”出需要对用户行为进行捕捉的控件，并给出事件命名。圈选完毕后，这些配置会同步到各个用户的终端上，由采集 SDK 按照圈选的配置自动进行用户行为数据的采集和发送。

无埋点是指开发人员集成采集 SDK 后，SDK 便直接开始捕捉和监测用户在应用里的所有行为，并全部发送到分析平台，不需要开发人员添加额外代码。在分析时，业务人员通过分析平台的圈选功能来选出自己关注的用户行为，并给出事件命名。之后便可以对特定用户行为（事件）进行多维分析了。

可视化埋点和无埋点比较像，都不需要开发人员手工加代码，也都需要业务人员进行所关注的用户行为的圈选。两者最大的不同是在用户终端的表现上，可视化埋点只采集业务人员关注的用户行为数据，而无埋点是会采集所有用户的行为数据，通常情况下数据量后者比前者大很多。

也正是由于无埋点默认采集所有用户行为数据，它能够做到事件的回溯分析，即在业务人员新定义（圈选）事件后，就能去分析这个事件在前面一两个月的数据情况，这也是可视化、代码埋点支持不了的。但带来的问题就是采集所有数据对应用的侵入会有些大，也会增大用户端采集的数据量。当然，可以通过一些策略，比如 Wi-Fi 下才发缓解这些问题。

无埋点和可视化埋点很大一个缺陷在于它们都是通过采集 SDK 去监测应用上控件的触发事件（用户对控件的操作），当产品 UI 在版本升级过程发生变动，或者产品做了大的改版，一些行为的“埋点”会发生丢失。如控件ID发生变化，而圈选的配置没变，导致数据采集不到；或者和业务的实际需要发生不一致的变动，比如圈选控件的作用发生了变化，但圈选配置没改；这些问题会导致对产品某些方面的分析出现差错，往往查起来还比较麻烦，在技术上完全解决也比较困难。

另外，可视化埋点和无埋点都针对的是客户端数据采集，一些用户行为数据在客户端是采集不到的，或者客户端采集的精准度不够，比如支付，因为支付成功的判断绝大多数场景都是在服务端做的，所以在客户端做支付行为的埋点，误差很大，这个时候就需要在服务端进行埋点。

我在业务选择时给的建议是，在产品初期，产品形态还不太稳定、分析的复杂度还比较低的阶段，采用无埋点或者可视化埋点，更快去做埋点，否则频繁的产品改动，会让开发人员大量时间花在琐碎的埋点代码维护上面。产品进入稳定期后，尽量采用代码埋点方式，可以保证事件模型是稳定的，便于长期的数据监控、分析和数据沉淀。

产品业务数据驱动的 workflow 往往是这样的：

1. 定义产品的阶段性目标；

   
   

2. 规划和定义指标，包括产品、运营、市场的各项目标；

   
   

3. 产品、运营等业务人员确定数据埋点需求；

   
   

4. 开发人员进行埋点以及数据的上报等开发工作；

   
   

5. 数据开发人员进行数据的清洗、宽表建设、指标计算等工作；

   
   

6. 业务人员分析数据、发现产品问题或潜在机会；

   
   

7. 继续下一阶段的产品、运营、市场等的改进工作。

用户行为分析平台的目标就是将其中 4-6 阶段的工作变得简单和自动化，把开发人员解放出来去做更多对业务有价值的工作。而 1-3 部分的工作，看起来不复杂，基于业务现状去定义指标，排出埋点需求，和开发人员确认好就完成了。但这块从实践上来看，很多企业或者业务都做的不够好。

埋点事件数量迅速膨胀，团队可能大部分人都不知道某些埋点是做什么的；或者业务人员定义了埋点需求，但开发人员埋点做错了，好久都没发现，导致分析过程出现错误解读，影响决策。

这块有几件事情可以做：

• 指标管理系统，用来维护指标依赖的数据表、字段以及计算方式，来统一开发、分析和解读过程的口径。

• 埋点管理系统，用来管理埋点的元数据，包括事件 Event 的命名、自定义字段含义和特定取值等规范定义，埋点在产品端的位置或触发场景，埋点工作流等，作为业务人员、开发者、分析师沟通的桥梁和基准。

  
  

• 埋点测试和校验系统，提供 debug 工具方便开发人员快速进行埋点调试，以及使用事件定义的规范要求，在线上对埋点数据进行校验，尽早发现不符合规范的数据，提高埋点工作的效率和准确性。

汇总就是：元数据管理系统 + 测试和校验工具

实践中，很多开发人员不太愿意做“埋点”的工作，觉得很琐碎，而且随着产品的发展，包袱有时候会越来越大，维护的工作量不小。

要让埋点工作在研发比较好的落地，最能提升的地方还是在于如何简化开发人员的工作，包括开发成本和沟通成本。

有完善的埋点管理系统，这样研发端可以依据进行开发，减少“口口相传”带来的低效和返工，也能统一口径和进度流程。有高效易用的埋点测试、校验系统，开发人员可以快速进行埋点 debug，提高开发效率，也能让业务方尽早介入需求校验，而不是等应用真正发布后才去校验，去发现问题。

当然，最好能和开发人员持续分享数据是如何促进业务的发展，让大家明白这些工作的价值，才能更重视，更认真对待这部份工作。

用户行为分析平台在建设时，数据端会包含如下能力：

• 数据接入，要支持客户端、Web、服务端等多终端的数据采集，如 iOS、Android、微信小程序等，以及各种数据源甚至三方服务的数据适配。

  
  

• 数据传输，在用户规模和数据规模增长过程中，要能保证数据传输服务的高可用、以及采集数据在传输过程的及时性。

  
  

• 数据建模/存储，要能实时的进行数据清洗、建模和存储落地。

这些能力，在互联网业务的数据资产建设过程中，尤其是用户、流量、产品相关领域，能起到基础设施的作用。规范的数据采集，加上高效的传输、建模能力，是企业业务数据资产有效建设的前提。

建模后的数据，可以作为数据仓库底层（ODS 层）的宽表，和企业的其他业务数据整合，共同完善企业的数据资产建设。

另一方面，这些用户端的结构化数据，加上实时建模和开放的能力，和机器学习算法结合起来，无论是个性化推荐，还是精准营销，又或是银行、电商的风控，都可以发挥很大威力，为企业的智能驱动业务做好数据积累，扫清障碍。

拿 DMP （用户画像）建设举个例子：

企业在建设自己的 DMP 库的过程中，常常会从常规的人口属性等准静态类标签，以及像消费能力等从自身业务积累或三方合作得到的通用类标签入手。这些标签往往是泛业务的，针对具体业务而言，很多时候会需要用户画像标签更贴近业务，比如电商业务场景下的母婴用户、电子产品发烧友、化妆品品牌喜好用户等。这些标签和用户的发掘，需要对用户的行为进行深度分析来获取，这个工作便可以借助用户行为分析平台的能力，如基于用户行为模式和用户业务属性对用户进行分群分析和比较，来发现和挖掘有价值的用户标签。

另一方面，用户画像的数据，也可以和分析平台进行整合和集成，提升平台各分析模型对不同用户群的洞见能力，让分析和指标的比较更有针对性，提升数据对业务的促进能力。

A/B 测试产品是通过提供专业高效的试验平台，帮助产品进行产品决策的验证和分析。常规使用流程如下：

接入 SDK -> 创建试验版本 -> 设置变量、以及优化指标 -> 调节试验流量 -> 运行试验 -> 实时监控数据进行效果评估 -> 正式发布

试验平台和分析平台的 SDK 在很多功能上是重合的，在 SDK 实现上可以整合，减少业务应用接入太多 SDK 的负担。

在数据采集、建模、分析层面，分析平台可以做为 A/B 试验平台后端数据的承载，优化指标的效果评估就能覆盖用户的全量行为，无需业务及开发人员维护多个工具带来的重复埋点定义和开发工作。另外，在分析平台积累的很多分析模型和指标，在 A/B 试验平台直接可以选取使用，无需在试验平台再进行设置，除减少业务人员工作外，还能保证统计口径的一致。

反过来，A/B 试验平台的一些对比试验，以及特定灰度发布的用户群，也能整合到分析平台，通过分群分析能力，将这些群体应用到各个分析模型进行针对性的分析，甚至试验结束后，也能持续对这些用户进行追踪和分析，更好的洞察用户。

这是个归因的问题，一般提到帐号打通，就会有归因的讨论 。

现在的分析产品在一般情况下，移动端会通过 SDK 生成唯一 ID 来标识用户/设备。移动化发展早期，很多采集工具用过 mac address、IDFA、android_id、IMEI 等从移动操作系统可以获取的设备软硬件信息来标识设备，但随着操作系统的发展，很多信息获取接口要么被封禁，要么已经失去了精准性。反倒是一开始就通过自己生成的 ID 来标识用户的工具，受到的影响不大，基本保持了用户/设备标识的稳定。

但这种方式有个问题，在用户卸载、重装或者刷机后，ID 信息会丢失，导致生成新的用户/设备 ID。

我们采用过 ID Mapping 的技术来做过 ID 的打通：对每个用户生成一个虚拟 ID，对同一个用户的多个设备和帐号进行映射，并绑定起来。

• 可以通过操作系统提供的一些稳定性稍差，但短时间还比较稳定的指标，如 iOS 的 IDFA，来做 mapping。

  
  

• 借助分析产品的应用覆盖率，如用户是应用 A 和 B 的用户，卸载并重新安装 B 应用后，可以通过应用 A 的 ID 修复应用 B 的。

  
  

• 通过引入产品用户帐号体系，来做绑定，这种方式稳定性最强，但非登录匿名用户的问题不好解决。

  
  

• 通过 IP、Wi-Fi 信息、机器型号、甚至地理位置进行 mapping，这种方式需要用户授权更多数据获取权限，虽然是近似匹配，但当信息足够多且发散（信息熵足够大）时，也可以起到统一标识的作用。

通过这个虚拟 ID 实质上就打通了产品的多端数据。ID Mapping 体系的建设工作量不小，Mapping 后用户标识如果需要发生调整，在基于事件的分析产品上需要对老数据进行重写，比较复杂。所以对于一些强帐号体系的产品，可以退化到只用用户帐号来做关联，只有非登录匿名用户才用设备 ID 来标识，这往往是性价比比较高的方案。

推广渠道归因就方便了。

支持营销效果评估的分析平台会要求产品在平台上生成推广链接进行投放。用户在点击链接时，会从分析平台的域下做跳转再到目标页，这样就可以借助浏览器的 cookie 机制进行匹配，来对用户来源进行归因，但这种方式在移动端上面的表现不太好（iOS 已经取消了 SFSafariViewController 多应用共享 cookie 的支持）。除此之外，也可以采用 ID Mapping 提到的近似匹配技术，很多厂商声称的设备指纹技术大多也是这种，不太准，但定性分析是可以的。

归因这块，一些推广渠道做了些工作，解决移动端不好溯源的问题：支持设备 ID 的回传功能来方便产品归因问题的解决。

产品方在投放链接的时候，遵照特定格式即可

比如 https://xxx.com/aaaafD?idfa=__IDFA__&imei=__IMEI__

渠道在用户点击广告链接后，会把设备 ID 如 IDFA 或 IMEI 加到链接的内容里面，用户激活后便可以通过相应 ID 匹配来归因。