uid是什么意思(数据产品经理的第一步)
本文作者基于工作中项目实践的思考，结合案例，分享了非常有用的数据嵌入点相关知识，供大家参考和学习。
最近给团队里的新伙伴做了一个数据埋点的分享。当时基本都是我口述稿子。我讲完后发现还有很多不足，然后回到公司一年多。其实各队埋分的实际情况还是比较差的，所以我决定把作者一年多来写埋分的经历整理记录下来。
一、关于葬点的几个问题在进入正题之前，作者先自问自答，回答几个与葬点相关的问题，以便本文内容结合大家的理解。
1.1为什么要埋？通过有效的嵌入，可以收集和观察产品中用户的第一手数据。真实反映产品的运营情况，是量化工作收入、计算KPI和ROI、在迭代中通过数据说服他人的重要依据，等等。
基本上作者的产品都会被设定，不埋，不上线，不发布，否则事后无法解释收益，也没有解释。
1.2产品经理为什么要写一个埋单文档？如果有专门的数据产品经理或业务线数据分析师，直接负责的产品经理可能没有必要编写隐藏文档。
但大多数情况下，公司可能没有专人负责。我建议产品经理亲自写埋档，而不是操作学生和R & ampd学生。原因如下：
如上所述，埋点产生的数据将是判断你的工作目标是否达到的关键。每一次产品迭代和项目上线，最终的收益都会通过数据体现出来；数据嵌入点也是产品需求文档，可以和需求文档一起写，结合你的需求；埋点可以服务你的长期规划和版本迭代；你最熟悉整个产品的业务流程，通过思考，你可以做出最低的成本，最高的收益；好的埋档可以促进你的逻辑思维能力，尤其是归纳和抽象的能力；1.3什么是点？这个概念对于第一次接触的人来说会比较难。作者会有几个语句来多维度描述它：
Point指定在特定触发条件下录制节目的策略；以excel为例，第一行的标题栏是点，标题栏会指定这个excel记录了哪些数据；用户在我们的app和网页中会有各种行为，程序会根据我们的规则记录用户的行为。事件模型=点；以上每一种说法都可以结合一个眼神，你就明白了。
1.4如何埋斑？嵌入技术有很多种，如代码嵌入、可视化嵌入、无嵌入等。嵌入的位置可以是客户端嵌入和服务器嵌入。
在本文中，嵌入文档将使用代码嵌入点和客户端嵌入点。也就是程序员根据我们埋藏的文档，在网站或app中报告用户的目标行为。
因为服务器端并不直接抓取用户的行为。此外，通常有一个日志系统从R & ampd，额外的掩埋点可能会降低服务器的性能。
二、如何描述一个点？个人认为一个点的描述基本可以和常用的5W2H模型相匹配。我们从左向右看。
红色部分是我们对一个点的描述的思考。根据情况和实际需要，我们可以适当增加或减少描述的纬度。比如我们不需要知道是哪个用户发的事件，所以不需要谁这个维度背后的数据，或者说用户都是产品内部的闭环，不需要知道用户的来源，所以为什么不能用。
这里有几点需要注意：
正常情况下，我们应该尽可能丰富地描述每一个事件。如果不提前记录数据，以后就无法完成。5W2H模型不需要从下面的描述中生搬硬套，只是一个思维维度，读者熟悉后可以按照自己的思路来。在how中，突出了用户的具体动作，也就是说这基本上是整个事件的核心骨干，一般是不可或缺的。白色部分是我们的点,或事件模型.虽然它是中文的，但它清楚地描述了我们需要记录的事件。也就是说，需要对JD.COM商场中从Tik Tok广告跳转到商品的用户进行统计。目的可以是看Tik Tok带来新用户的能力，或者这个产品曝光后的转移能力等等。
最后，绿色部分是一个事件：2020年4月11日23: 11: 00，一位手机号为京1386的iPhone6SPlus用户在刷Tik Tok的同时，通过广告3412的链接访问了JD.COM商城的自热米产品。而这样的数据，每一分钟，程序都会根据我们在白色部分的描述，在程序中产生上千块。
理解了这个模型之后，我们应该正式开始编写我们的埋点文档。
三、一个案例3.1产品原型作者在这里画了一个简单的产品原型，具体逻辑就不赘述了，一目了然。
3.2埋点文档根据前面的点描述和产品原型，作者简单的写了一个如下图的埋点需求文档。这里会有10个点的描述，也就是每一行相当于之前的一个思维导图。
红色区域:只是把思维导图绘制在前面，帮助大家管理它。
解和思考的，平时写文档时不用写；黄色区域：则是事件描述，简单描述埋此点的意义和方法（本表中写得略简单），如果有比较复杂的情况，需要和研发同学进行沟通确认；绿色区域：为事件模型、点描述，其中每一列，都称之为一个属性，或者叫纬度；蓝色区域：为传值描述，即相应的属性里会放入哪些值；通过上面这份文档，研发同学已经可以进行埋点操作。
但不难发现，这个文档却有几个明显的问题：
所有的点都用到了，AppName、Time、Uid等属性，文档看上去很累赘；不是所有的点都需要使用Title，Fav，Like等属性；部分事件描述不够详细，继续加Howmuch类属性将会使整个文档的可读性直线下降，笔者目前有过100列属性的情况演示用的APP才两个页面就10行了，如果有100个页面将如何处理？为了解决以上问题，让我们的埋点文档优雅起来，还需要进行以下几个优化步骤。
不难观察到，其实Time、AppName、Uid这三个属性每一点都需要进行使用，且传值的规则一致，笔者会将此类属性定义为点的公共属性。
在这种情况下，笔者一般会将一篇文章中的公共属性在正式对各点进行描述前进行总结。这样研发同学也可以根据此对所有的埋点方法（研发意义上的）进行抽象，在每次用户所产生的事件上报时，都会调用这块儿的属性值。
之后文档改起来也会非常方便。如下图所示：
备注：好的埋点工具，会自带默认采集的属性，比如：设备型号，系统型号，地理位置等。
根据笔者的经验，每个不同的页面，单独做一个表的可读性会更强，在删除之前的公共属性后，整体的事件埋点如下所示：
在表的旁边再配上各页面的截图，将会使整个文档更清晰。即使是新来的同学也会知道各页面上有哪些操作。
最后我们以小说主页这个页面来进行一个私有属性的折叠。私有属性则是相对于前面的公共属性来说的，在前面的图中我们会发现两个问题，不是每个事件都需要使用Title,Fav,Like这几个属性，且在不同的点中，Fav、Like的含义也会有区别（一个表状态，一个表行为，当然差异还可以更大）。
所以就会将私有属性根据点的维度进行单独补充描述，如下图示。这样不仅可以对一些重要的事件进行比较详细的描述，且和别的事件在使用同名属性的时候还不会互相冲突，提高了属性的复用率。
关于如何对产品进行埋点的入门篇，到这里就差不多能够应付绝大多数简单的场景了。这份简单的文档笔者还遗留了很多的优化空间，将会在下一篇进阶技巧中进行补充。相信运用得当，将会秒杀90%以上的产品经理，对于数据埋点方面的理解。
作者：核桃壳，微信walnutshell911
本文由@核桃壳原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。