产品经理整理埋点需求的6个步骤.docVIP

产品经理整理埋点需求的6个步骤 / 互联网发展到现在这个阶段，数据驱动已经被很多人认同甚至奉为圭臬，因为有效所以扩散，观察和分析数据是产品岗位的标配了，所以对于一个产品经理来说这是必备技能之一。 从市面上各种数据分析课程和python课程以数据爬取和分析为卖点，数据热潮可见一斑。人重要的是顺势而为，既然市场有需求当然要会。 对数据的使用是分为采集、清洗、存储、提取、挖掘、分析这些部分的，采集、清洗、存储、提取是技术在处理，挖掘和分析一般是数据分析师和产品、运营等在看，各有分工。 但是源头还是需要产品或者运营来梳理，因为技术通常并不知道要采集哪些数据，所以就需要产品提供数据采集说明，也就是埋点需求的说明文档。 那么埋点需求怎么梳理？ 第一步，确定公共数据点，主要是用户属性和设备属性。 用户属性和设备属性的样例见下图 公共数据点其实一般来说都是不变的，一旦确定之后很少修改，所以复制粘贴即可。 因为一般不会变化所以在第一次提的时候需要尽可能的提全面，因为如果是后续补充的话历史数据是无法追溯补充的，分析的时候可能就会有维度缺失。 第二步，确定一下产品需求的范围，也就是这次需求优化了哪些地方，把需求涉及到的app端页面全部梳理出来-不分原生或者H5，单列一个表格，每个页面列成一条。 第三步，把页面上涉及到的所有按钮补充到对应页面的下方，也单列一条。譬如一个注册页面，一般会有获取验证码按钮、注册登录按钮，每一个按钮都需要单列一条。如果是二级页面，左上角的返回按钮可列可不列，一般也不重要。 第四步，把数据埋点需求表填充完整。这就是一个填充的过程，不遗漏就行，比较需要关注的是埋点由前端埋点还是后端埋点，这个需要根据情况定一下，一般来说如果仅仅是时间譬如访问和点击这种就做前端埋点，但是需要有结果的，譬如帖子发布成功这种的就做后端埋点。如果不确定可以和技术讨论一下。 埋点需求的样表是这样的，大家可以做个参考。 第五步，埋点需求表理完之后最后需要做一下核对，看一下是不是完整了。怎么核对呢？根据数据统计需求去核对，看一下配套要做的数据统计报表能不能根据这些页面埋点统计到，如果可以的话一般问题不大。如果有遗漏的补充一下。 敲黑板：这是最重要的一步。 校验内容你可以按照以下步骤去做： 1）看一下中英文的命名是不是正确，有没有重复。正确一般不是问题，但是重复这个可能时间长了会有出现，尤其是英文名，毕竟大家英文一般都不6，所以在命名的时候尤其是尤其要注意，取个巧的方法是拿着中文去百度翻译成英文，如果重复换一个或者加001这种以示区分。 2）看事件定义完不完整，够不够清晰，如果是刚开始写的可以拿公司的历史文档去比对，照着改就行。 3）事件触发的时机对不对，如果是按钮的话其实问题不大，就是个点击事件，如果是页面访问一定要写清楚是页面100%加载完成。 4）埋点的前后端区分对不对，这个之前也有讲，如果只是事件本身其实一般做前端埋点，如果还要统计结果，譬如提交内容成功这种的就需要做后端埋点。 5）属性定义完不完整，属性会包含很多东西，譬如类型、渠道之类的，会有多个，在这个时候一定要看一下是不是全部包含了，漏掉的话在统计的时候就会有问题，虽然技术后面可能还会来确认，但是少让技术问比较好，人设靠谱。 第六步，给技术看一下，看看是不是有哪些地方需要进一步细化说明，针对性地做补充说明。这个步骤一般就是细节没讲清楚，譬如页面访问，那么什么情况下定义为一次访问，需要说明这个页面100%加载成功了才算一次访问。 埋点需求交付以后技术会排期开发，开发完之后的验收也是一个比较重要的环节，根据我们的经验埋点通常会有遗漏或者采集不完整、采集不准确的情况。 那么埋点数据怎么验收呢？ 如果你有技术背景，那么就去看操作之后相应的数据字段有没有入库；如果没有技术背景那么就去看统计报表上会不会反应出来。譬如你打开一个页面，就去看一下统计报表上这个页面的访问人数和访问次数有没有+1。 埋点验收是需要一个一个页面、一个一个操作看过去的，所以可以结合页面验收一起做。 那么验收了之后就没有问题了吗？ 不是的，实际上我认为即便是做了验收，也无法彻底解决数据不准确的问题，因为会有数据污染的问题，单次验收仅仅只是个例，而数据污染可能是个普遍性的问题。 从实践经验来看也是这样，大部分小厂都无法解决数据的准确性问题，数据污染问题比较严重，如果是大厂那么就会相对好很多。 数据污染产生的原因比较复杂，可能的原因是采集的时候就不对，或者提需求的时候不够准确。大概率会需要一个逐渐修复的过程，而且是一个相对长期的过程。所以如果发现数据不准确的话不要慌，一点点修复就行。说实话其实急也没用，这种就是需要花时间做的东西，表面看不到的才更花功夫。 另外，如果说技术部门愿意做全埋点的话就不需要产品额外提数据需求，如果是这样，那么必须感