【产品】关于App埋点

App上线后迭代最大的财富是什么？是数据。数据如何获取？埋点。目前我们的产品采用了第三方平台记录了注册数，日活量等数据，但这远远不够，还需要对关键行为的追踪与记录。而且要为以后的运营活动铺好路，下面是我对于数据埋点的一些梳理

埋点的目的是什么？

核心是产品定位与产品目标的确定，以及这些目标的拆解以及短期，中期，长期规划以及相应的具体roadmap
一句话：用数据的埋点，监控用户行为

场景是什么样的？

新功能是否得到用户的使用与认可？新版本增加的新功能，用户点击率怎样？
用户在核心使用路径上是否顺畅？有没有因为交互体验功能按钮的设计而导致无效点击增多？
市场运营效果的回归？针对某个特别的日期进行了产品内的广告Banner推广或者促销，该活动的效果如何？

数据分类

数据分三类①产品规模②产品运营③商业指标

真实案例

在分析的一开始，并不建议采集太多的用户行为，在这一点上，倒是很像做产品里面的MVP（最小可化产品）思路，敏捷地不断迭代，不要一下子把全部用户行为都采集齐全。因为如果产品经理在一开始就试图设计实施一套庞大、全面的方案，很容易陷入复杂而又细节的泥潭并导致失败，即便最终成功，也极可能会（因为初期的错误规划）导致很多时间浪费。在一开始只记录和分析与“产品目标”最为相关的少量用户行为（如浏览、购买、下单），这样很快就能有成果产出。

产品需要做什么

其实，产品最重要的就是要关心自己的业务目标、定义事件、关心数据结果。

在这里需要注意的一个点，很多产品经理会将“用户行为”简单的等同于应用的页面（界面）或点击操作，其实这完全是两件事情。用户行为是更加具体的一个事件定义，比如说用户“提交订单”这么一个行为，就可以定义为一个事件了，但是如果用页面点击去定义它，则过于抽象不具体，不能让其他人很直观地感受到这个事件定义出来到底是干嘛的。

在这个时候可以从以下几个方面来考虑：
产品目标可以通过哪几个重要指标衡量？和指标最相关的用户的“关键行为”是什么？用户在做「关键行为」之前和之后，还有哪些行为值得关注和分析？
通过对上面问题的答案进行梳理，您就能得到类似下面的用户使用流程及用户行为事件了：

用户行为事件

另外一个需要注意的地方是，尽量在给事件取名字的时候简单处理，不要弄一些比较复杂和偏门的事件名字，不然团队其他成员也不好理解。
制作埋点表
根据上面梳理的用户行为流程及事件，我们可以尝试着梳理一下埋点事件表，如下图所示：

事件埋点表

当然，有些产品比较复杂（如电商类），数据分析不能单纯的靠一些基本事件来进行，还涉及的事件属性会比较多，所以产品经理也可以在事件埋点表中补充关于事件属性这么一项。为事件增加属性，是一种更细致的、更精确的记录和刻画用户行为的方式。比如，某个用户打开了一个吹风机的商品详情页，可以详细描述如下：事件：查看商品详情-商品类目：家用电器 -价格区间：100-399 -商品名称：飞科吹风机某某某型号…

事件属性

主流的几个埋点技术有下面几种：

第一种：代码埋点
是在代码的关键部位植入N行代码，追踪用户的行为，得到想要的数据。简单的说，就是找节点，布代码，收数据。
第二种：框架式埋点
框架式埋点也称“可视化埋点”，框架式埋点很好地解决了代码埋点的埋点代价大和更新代价大两个问题。
第三种：无埋点（目前流行）
所谓的无埋点，只要页面上嵌入 SDK，就可以采集页面上所有的点击行为，然后通过界面配置的方式对关键行为进行定义，这样便完成了所谓的“无埋点”数据采集。使用这种方案，必须在产品中嵌入 SDK，等于做了一个统一的埋点，所以“无埋点”的叫法实际上是“全埋点”的代名词。

无埋点”相比框架式埋点的优点，一方面是解决了数据“回溯”的问题，例如，在某一天，突然想增加某个控件的点击的分析，如果是框架式埋点方案，则只能从这一时刻向后收集数据，而如果是“无埋点”，则从部署 SDK 的时候数据就一直都在收集了；另一方面，“无埋点”方案也可以自动获取很多启发性的信息，例如，“无埋点”可以告诉使用者这个界面上每个控件分别被点击的概率是多大，哪些控件值得做更进一步的分析等等。

另外，这种方式只能采集前端数据比较粗的行为粒度，无法深入到更细粒度。比如提交订单操作，订单运费、成本价格之类的维度信息，都丢失掉了，只剩下“提交”这一个行为类型。

http://www.jianshu.com/p/6f47fc648e69

参考文章： http://www.pmcaff.com/discuss/answer/692426883613760?from=selection
https://sensorsdata.cn/blog/shu-ju-jie-ru-yu-mai-dian/
https://zhuanlan.zhihu.com/p/20519396?columnSlug=zhugeio