无埋点数据采集,从业务视角，分析埋点思路

无埋点数据采集,从业务视角，分析埋点思路

对于产品经理来说，追踪文件的输出可以说是家常便饭，但对于新产品，大部分人还是不知道追踪的规格和注意事项，所以本文将与大家分享追踪的设计从商业视角。想法，希望对你有帮助。

本文仅描述思路，不涉及相关技术。文中的完整示例用于阐明想法。 SDK完成半自动替换。

从这篇文章中，你可能会得到：

1. 嵌入想法1.1 梳理业务流程

埋头的第一步是梳理业务流程。如果你有良好的 PRD 写作习惯，这一步已经在 PRD 中完成了。比如某电商促销的用户流程：商品-商品详情页-订单

1.2 确定关键指标

迭代功能/业务必须有一个产品目标，可以是解决某个需求，也可以是改进某个产品数据；关键指标是衡量预期目标的可量化指标，包含两个概念：

1.3 细化各工序的影响因素

梳理完业务流程，接下来就是细化各个流程节点的数据评价维度。由于每个节点的转化率都会影响最终关键指标的数据，如果发现某个节点的转化率较差，就应该优化这个节点。因此，我们还将列举影响每个过程的效果。因素，可能包括但不限于：

1.4 对旧功能/业务流程的影响

新功能的推出也会对原有的功能流程产生一定的影响。由于业务属性可能有不同的要求和重要程度，这里不再讨论；

2. 隐藏的设计原则2.1 独特的原则

埋点场相互独立，可以精确定位某个事件或行为；即一个行为事件可以通过1~2个参数精确定位。比如搜索页面上“确认搜索”按钮的点击事件就是搜索，那么就需要避免在同一个名为搜索的页面中发生其他事件；

2.2个枚举原则

购买所有可能需要的数据所涉及的数据，可以根据页面，或者根据流程进行穷举，确保不漏；

2.3准确描述

每个埋点对事件的无争议描述，包括但不限于：收集逻辑、数据结构、特殊情况的处理等；在以下情况下

涉及发生后的状态上报：比如微信分享，是需要点击分享按钮上报，还是点击跳转上报成功？涉及曝光埋点：比如内容曝光，用户上下滑动时是否需要重新曝光？切换导航是否需要重新曝光？从详情页返回 暴露的内容是否需要再次暴露？涉及内容展示楼层埋点：比如从上到下的内容流记录为1、2、3……，不同类型是否共享楼层数（比如第123条，第四位是否应该出现在广告位报4或重新统计1）

数据结构就像字面意思一样，定义了上报字段的数据类型，整数/字符串等，如果对这方面不是很熟悉无埋点数据采集，最好让BI或者分析师确认一下用于后续数据处理；

3.埋点分类及实例

在埋点例子之前，这里简单介绍一下埋点的需求这里将关注的信息总结为从“5W2H分析方法”简化而来的“4W1H”用户行为模型；有一些常用的参数，即不管是什么行为都需要上报的参数。为了避免重复工作，这些参数通常是预先定义好的，并且在每个版本中默认上报。下面列出了一些常见的例子：

3.2页访问

类似公共参数无埋点数据采集,从业务视角，分析埋点思路，一般页面访问也是底层定义的逻辑，无需重复定义

这里描述了两个参数：

是否返回i​​s_back：如果要统计一个页面的PVUV，没有这个参数，将无法区分用户和下一页返回的数据无埋点数据采集,从业务视角，分析埋点思路，导致数据偏高；动态json字符串：有些页面需要上报一些自定义的参数，比如订单页面想知道订单ID&订单状态，内容页想知道这篇文章的ID，从而细化操作;3.3 曝光类别

曝光埋点顾名思义就是不发生点击行为，而内容曝光时上报的埋点多用于内容流（商品流）的数据分析，用于计算CTR（点击率无埋点数据采集，点击次数/曝光次数）、用户时长（曝光时长），下面以某电商APP首页的产品流程为例：

p>

3.4 点类

Dot 类埋点一般用于统计各种按钮点击的事件。下面是一个点击like按钮的简单例子：

3.5个跟踪参数

有时需要跟踪用户对产品的单次使用或使用某个功能的路径。个人使用user_id+。时间戳用作跟踪 ID。这里需要注意时间戳的选择。例如，要跟踪整个产品路径，时间戳就是应用打开的时间；但是如果要跟踪搜索行为路径，则需要使用被点击的搜索框的时间戳作为跟踪。身份证

4.写在最后

写这篇文章的初衷是对一个职场社交应用做一个小调查。结果表明，大部分PM在日常工作中都需要对埋藏文件的输出负责。同时，新的 PM 对埋点感到陌生和困惑，所以：

本文通过实例提供了从业务角度设计埋点的思路。仅基于个人经验，不代表行业规范；这是初衷。

同时也欢迎前辈提供建议和补充~

本文由@gxxx 原创，大家都是产品经理。未经许可禁止转载

题图来自Unsplash，基于CC0协议