数据埋点之神策全埋点总结

项目介绍：

项目简介：本人就职于某互联网初创公司，公司主要APP是服装领域S2B的某服装领域APP，现在需要对APP进行数据采集。

一、 准备阶段

前期准备工作主要是：

1.明确数据采集的需求：
这个因公司不同类型而不一致，也和管理对数据需求有关。一般情况下：

• 偏传统类公司：
  还没有成功转型为互联网，对用户画像、用户路径等需求不高，APP用户较少的情况下，基本直接调取数据库的结果数据进行分析即可，前期可能不需要花很多人力物力去做数据埋点，毕竟前期验证业务才是关键；
• 互联网类公司：
  公司产品是对C端用户，业务模式已经经过验证，此时管理者需要精细化运营，了解用户画像等辅助决策，并且需要了解到很多非结果数据，那么此时，就需要通过埋点方式对数据进行采集了。

2.埋点方案的确定：
人力物力时间充足的情况下也可以选择公司自己开发数据平台。在前期人力物力有限，而且时间比较紧急的情况下，一般会选择第三方工具，当前市面上有的埋点工具有很多，也比较成熟。比如神策、友盟、诸葛等。

• 想要快速能使用，并且对数据的保密性程度没有非常高的情况下，可以选择友盟等免费服务；

• 如果数据机密性程度要求很高，需要私有化部署，就需要付费购买相应的服务；具体收费情况详情因具体情况而定。

  我们公司是选择的是神策第三方工具，进行私有化部署，具体费用就不多透漏了。

3.埋点方式的选择：
当确定选择采用第三方工具进行数据埋点，此时还需要根据具体的产品埋点的需求、项目时间等因素，敲定埋点实施的方案。数据收集理论上是越全面越好，但是有些非核心数据也全部记录并上报的话，会有很多冗余数据，也可能会导致数据上报过程缓慢，给服务器造成很大的压力，因此，分析需要采集的数据指标以及了解产品、运营、市场等角色对采集数据的需求至关重要。
关于不同的埋点方式的原理，各种埋点方式的优缺点，如下图。

本次因为产品属于验证市场，而且时间比较短，通过沟通之后，选择了全埋点的方式。

二、 埋点方案设计——全埋点

全埋点和其他埋点方案属于不同的埋点方式，埋点方案会有区别。

• 核心原理：只能以前端页面和按钮等控件为单位，统计浏览人数、点击次数等静态指标；

• 优点：不需要写代码，直接调用神策的SKD接口就可以，实施难度较小，比较快速；

• 缺点： 只能统计很少的静态指标，无法获取和分析用户行为路径，不能做到很精细化分析；

• 全埋点流程：

   (1)服务器私有化部署（非必须）：神策人员+公司运维人员
   
   (2) 产品数据采集需求梳理（输出：1.核心按钮清单，2.页面维度字典）：
  

A. 核心按钮清单：便于测试和业务验收神策，主要抓准核心的按钮的点击次数等测试； 实质是：按钮名称（业务能懂的名词）–按钮属性（代码中的按钮ID等唯一性区分的属性）的对应关系。
B. 页面维度字典：页面名称/页面标题–页面地址的对应关系。
1. 以页面标题作为页面唯一性的区分标准：神策可以直接读取每个页面的地址，并和代码中的页面标题进行匹配，当APP端进入某个页面，触发该页面地址上报采集，神策后台看到的也该页面地址对应的页面标题。 该种方式不需要输出维度字典和对应关系文档，神策会自动采集，但要求开发人员代码规范。适用于后期不经常更换页面名称，产品较稳定的情况。
2. 以页面名称作为页面唯一性的区分标准：APP端进入某页面，满足上报条件，神策采集到该页面地址，将采集到的地址和产品输出的《页面维度字典》进行匹配，将其对应的页面名称展示在神策后台，方便业务，产品，运营能登陆神策后台理解。该种方式需要产品、运营和研发一起整理《页面维度字典》，该种方法对开发的代码规范相对较低，维度字典后期也非常方便维护，缺点是前期梳理该文档比较费时。

 (3) 研发开发并自测：主要测试上报机制逻辑，维度字段对应关系、上报采集数量等方面。
 
（4）测试测试：APP操作是否准确上报并采集；维度字典对应关系是否正确；采集次数是否正确。

（5）产品、运营等验收。            

三、 埋点方案设计——代码埋点

目前，暂时正在事件设计阶段，等后期项目做完，再来总结此部分内容。