下载掌阅APP，畅读海量书库
立即打开
数据埋点是指基于业务需求（如淘宝双11促销页面统计每个banner的点击次数）、产品需求（如推荐系统统计推荐商品的曝光次数及点击人数），对每一个用户行为事件对应的位置进行埋点，并通过SDK上报埋点的数据结果，将记录数据汇总后进行分析，以推动产品优化或指导运营。
本章详细介绍数据埋点需求的实现，是《数据产品经理：实战进阶》第4章“数据埋点体系”的补充和延展。主要内容包括数据埋点的应用场景与工作流程、埋点需求实战案例、埋点规范样例与测试样例。本章讲述的是后端埋点，通篇以电商平台广告埋点为例进行讲解，同时基于精细化运营的需要进行多维度分析，并对与用户账户、风控有关的业务数据进行深入分析。数据埋点的逻辑是相通的，读者可以结合自己公司的业务需求进行调整。
数据埋点可以记录用户的被动行为和主动行为，对用户行为的各种数据进行统计和分析。
对于互联网公司来说，数据埋点有着多方面的实际作用，包括但不限于以下这些。
了解和跟踪数据的总体情况：PV、UV、曝光点击数、用户数、会员数、复购率等。
用户行为分析：用户的使用习惯、用户的决策路径、用户使用产品的热力图分布等。
掌握产品的变化趋势：产品每日流量、产品所处的生命周期，以及电商大促活动前后一周、两周的数据变化趋势等。
数据形成反馈，用于产品迭代：用户行为的转化漏斗，基于用户行为（浏览、点击、关注、收藏、加购、评论、分享）、商品、店铺、品类、大促活动等的转化率。
按照统计数据的不同，后端数据埋点分为曝光埋点、点击埋点和页面事件。
1.曝光埋点
页面曝光是为了统计各业务端（App、内嵌H5、PC、WAP、微信小程序）内的页面局部区域是否被用户有效浏览，比如淘宝App首页联版、微信朋友圈露出的广告资源位、抖音App的开屏页等。
要衡量页面各区域用户的点击率，需要先弄清楚各个区域分别被多少用户看到过。一个区域每被用户看到一次，就可以记为一个曝光事件。有了曝光，才会有用户点击行为。对于页面曝光需要单独埋点，即页面曝光埋点。
进行曝光埋点时需要获悉以下两点。
曝光统计逻辑 。同一用户上下滑动页面只算一次曝光，不会重复统计。如果用户在浏览时页面重新请求接口，认为用户浏览的区域发生了替换，则会重复统计用户的曝光。（这是数据采集时统计曝光的逻辑，与客户端按照请求次数来统计有所不同。）
曝光统计标准 。曝光统计并无一致的标准，各家公司要求不同。在页面曝光的区域大小上，一般来说，App、WAP等终端露出100px（不到1cm）就算曝光了；在页面曝光的停留时间上，以笔者的经历来看，10s甚至15s的用户停留时长才算曝光。用户曝光是用户的被动行为。
2.点击埋点
用户在各应用内的任意一次点击都可以记为一次点击行为。比如，购物车的点击、微信朋友圈的点击、图片的点击等都可以记为一次页面点击。区别于被动的用户曝光行为，用户点击是主动行为。对页面点击进行单独埋点就是页面点击埋点。
我们可以通过用户行为得到点击PV、点击UV，也可以通过页面曝光和页面点击计算出页面各个区域的点击率（点击率=页面点击数/页面曝光数）。
3.页面事件
页面事件通常指对页面各种维度的信息的统计，常见的有当前页面URL、用户账号等。事件往往通过页面各个参数进行透传并最终落表。
页面事件统计的信息通常包括以下几部分。
用户来访设备信息 ：用户设备标识码、浏览器版本、浏览所用的终端、站点编码、屏幕分辨率等。
当前页面访问信息 ：用户账号、用户会员编码、当前页面URL、用户访问时间、上次访问时间、访问时长、页面停留时间、用户退出页面时间等。
页面来源信息 ：广告来源、上一页面URL等。
页面去向信息 ：去向页URL、去向页标题等。
商品信息 ：商品编码、供应商编码、店铺编码、商品名称、商铺名称等。
本节介绍日常工作中数据埋点的完整工作流程，它既有流程图，也有数据埋点的需求，涉及项目需求（含产品经理自提需求）的承接、评审、跟进、上线以及项目复盘的各个业务环节。
数据埋点工作是以数据产品为核心来推动的。数据产品经理负责数据埋点的整体工作，包括验证数据埋点的质量、判断数据埋点的准确性（包括日常工作中上线的数据埋点的准确性）等。一般的数据埋点需求关联的工作人员如下（另外还有部分需求会涉及数据采集、数据仓库），其工作流程会在本节的流程图中体现。
业务方 ：页面运营人员、产品运营人员。
数据产品线 ：数据产品经理、数据产品测试人员。
广告产品线 ：广告产品线产品经理。
页面产品线 ：页面产品经理、页面测试人员、页面前端开发人员。
互联网公司的点击埋点、曝光埋点的协作流程图如图2-1所示，详细说明如下。
1）业务方提出需要对接的坑位信息，运营人员填写《广告坑位埋点位置表》。
2）广告产品线产品经理梳理业务场景，完善《广告坑位埋点位置表》并通知各页面产品经理、数据产品经理接入。
3）页面产品经理提供《页面需求文档》（内含《广告坑位埋点表》），数据产品经理提供《数据埋点需求文档》（内含《埋点规范》），由各产品线合并文档生成《广告需求文档》（内含《广告坑位截图表》）。
4）广告产品线产品经理通过邮件邀约所有人员进行线下评审，邮件标题：【重要】××（广告位名称）-××（类别）-××（广告位置）需求评审。会后发送《会议纪要》（内含《上线时间表》与《需求计划时间里程碑表》）。
5）功能开发完毕后发布到测试环境，由页面产品经理通知各广告产品线验收，广告产品线验收后通知数据产品测试人员验收。
6）数据产品测试人员发送测试验收结果及《测试报告》。
7）页面产品经理和广告产品经理整理上线流程并发送《上线公告》，通知数据产品经理验收。
8）数据产品经理验收后提交广告产品线验收，并由广告产品经理发送《上线验收说明》告知业务方验证结果，待业务方验收。
9）业务方验收后反馈数据供产品线验证，产品线提供数据供数据产品经理验证，之后数据产品经理反馈《验收结果报告》。
10）结束埋点需求，埋点正式上线。
图2-1 点击埋点、曝光埋点的协作流程
1.提出埋点需求
运营人员提出埋点需求：不仅涉及埋点的位置，比如App的开屏页、App首页联版、App首页banner位，还涉及需要埋点的终端，比如有的埋点需求只需要进行App端的埋点，而有的埋点需求需要进行App端、微信小程序、WAP端等多端的埋点。
产品经理自提埋点需求：数据产品经理在进行竞品分析及日常使用产品时，也会根据业务情况提出埋点需求。
2.梳理埋点需求，整理埋点方案
不同终端（App、内嵌H5、PC、WAP、微信小程序等）的埋点方案各不相同，通常至少需要包括以下几点。
埋点的位置 ：需要添加埋点的位置，比如登录页上的按钮、页面底部导航、搜索结果页等。
埋点的参数 ：用户浏览、点击的页面位置需要通过前端页面开发埋入的参数，比如页面编码、模块编码、区位编码、商品编码、店铺编码、页面特殊参数等。每个位置的埋点必须是全站唯一的，不能重复。
终端类型 ：对各终端进行约定，表示终端的标识。比如，约定App终端为数字1，WAP终端是数字2，等等。
模板名称 ：需要埋点的页面的模块位置、页面的模板名称。例如，模块位置—App首页轮播banner，模块名称—轮播banner位第二个资源位。
数据产品经理需要将自己整理的数据埋点方案与业务方、前端开发人员核对，以确保埋点方案可行。
3.需求评审，埋点文档评审
数据产品经理写出数据埋点需求文档，列出埋点位置、埋点所需的参数、涉及的埋点终端、埋点需要调用的接口、埋点是否需要异步触发、本次埋点需求期望的上线日期和联调日期等。
埋点需求评审的参与人员有业务线产品经理、数据产品经理、页面产品经理、前端开发人员、测试人员、业务线开发人员、数据开发人员。在必要时，比如新增埋点的产品类型时，还需要与数据采集人员、数据仓库管理人员沟通数据埋点需求。
4.埋点开发阶段
前端开发人员需要根据埋点需求进行埋点开发，实现相应的曝光埋点、点击埋点、埋入页面参数、异步触发请求（对于广告等埋点需求，在点击埋点关联到广告扣费结算时，需要再触发一次请求）。
5.埋点联调测试阶段
埋点开发结束后，进入埋点联调测试阶段。在联调测试阶段，需要在测试环境下验证曝光埋点和点击埋点是否正确、埋点的参数是否有遗漏或错误。
6.埋点上线
埋点测试验证通过后，将埋点按照约定的日期上线。上线时同样需要测试。在生产环境下，可以下订单来验证订单归因（简单来说，订单归因就是通过订单能否验证订单的来源、来源对应的埋点位置）。
7.埋点需求复盘
埋点上线后，及时更新埋点验证情况，列出每期上线的埋点及需求内容。总结在每期埋点项目中遇到的问题，这样后面在推进新的埋点需求的过程中可以少踩一些坑。
8.埋点数据统计与用户行为分析
部分公司会开发数据埋点平台，这些平台会按天、按周、按月对每个数据埋点进行数据统计；可以对同一个位置进行曝光埋点、点击埋点和页面事件的同比、环比趋势对比，比如淘宝App首页在618、双11等大促活动的趋势对比；可以根据埋点数据做用户增长，提升用户留存率，比如根据淘宝App商品四级页的点击到达率来分析用户在之前哪个环节跳出。
1.业务方的需求太多了怎么办
需求太多是非常普遍的问题，因为业务方都希望能获得更多的数据支持。如果多个业务方同时提需求，很容易超过数据团队的工作承受量。这时，产品经理可以考虑这样做。
1）算出具体人力缺口 ：列出本期业务方所有需求，计算所有需求总共需要多少开发人力以及目前能提供的总开发人力，得出开发人力缺口是多少人天。
2）填补人力缺口 ：开发人员加班调休补上缺口；缺少测试，数据产品经理可以进行自测；从其他中心部门借用开发人力。
3）补人力缺口后依然有缺口的策略 ：向业务方反馈，召集业务方、开发人员、测试人员、产品经理共同开会，说明开发人力本期能承接的最大需求数量。 请业务方给出每个需求的优先级，本期只承接优先级靠前的若干个需求 ，按照需求优先级来开发，其余需求留待下期完成。
2.数据埋点工作中的其他常见问题及应对措施
1）埋点被污染、被占用。笔者曾遇到过公司金融部门误用了广告埋点的规则，造成金融App页面的数据大量被作为广告埋点的数据上报，严重影响了广告数据埋点的准确性。出现类似的情况时，需要第一时间对占用埋点的页面数据进行过滤，回刷数据，同时通知占用埋点的页面方改变埋点方式，并实时监测埋点上报数据是否正常。
2）没有进行埋点或者错误地进行埋点。在实际工作中，页面开发人员有时会忘记埋点或者将埋点字段弄错，导致页面没有埋点数据。页面开发人员新上电商促销页面或者进行页面改版时容易出现这样的情况。该问题出现时，需要先抓包，看是否有埋点，如果有，看埋点是否正确（比如曝光埋点与点击埋点有没有分开），同时需要看埋点上报缺少哪些数据。问题定位后，通知页面产品经理、页面开发人员进行相应的埋点，并实时验证埋点。
3）埋点上报大数据中心时解析错误。数据埋点会被采集数据并上报到数据仓库，数据仓库会对埋点进行解析，解析后将数据下发到对应的部门。在实际工作中，会出现大数据数据仓库并没有对于某些数据埋点进行解析，造成下发数据丢失的情况。出现这样的问题时，需要快速定位哪些埋点没有被解析，正确的解析规则是什么，同时通知大数据数据仓库变更埋点解析规则，并回刷历史数据。接受下发数据的部门也需要回刷历史数据。在解决这样的问题时需要再次验证埋点数据并确保已回刷数据。
4）数据埋点落表的数据错误。在实际工作中，会出现接受埋点数据进行统计的报表数据出现错误的情况。这时需要查清是否可以实时及离线接受下发的数据、报表接的数据源是否有误、报表进行数据统计的代码是否有bug等情形。定位问题所在后，需要开发人员及时进行修复，回刷数据，并在修复发布后及时验证数据。
本节以笔者所在公司的经验为依据，介绍对App端搜索结果页坑位进行埋点的实战案例。
运营人员或数据产品经理会提出每期要上线的埋点需求，其中包括埋点的位置、埋点涉及的页面终端类型（App、PC、WAP、微信小程序）等。App的埋点位置说明见表2-1。
表2-1 App的埋点位置说明
以互联网广告业务埋点为例，数据产品经理需要在需求评审阶段告知开发人员埋点在电商App中的具体位置。在如图2-2所示的业务线坑位截图中，左侧带“广告”字样的位置就是需要埋点的坑位（搜索结果页—冰箱—坑位1）。业务线坑位名称为App端搜索结果页业务线单品。
在需求评审阶段，数据产品经理还需要根据数据字典，告知开发人员在搜索结果页—冰箱的广告坑位埋点需要埋入的具体参数。页面参数是App页面已有的参数，比如页面编码、模块编码、坑位编码等，如表2-2所示。
图2-2 业务线坑位截图
表2-2 页面坑位埋点参数
运营人员、数据产品经理、开发人员、测试人员会根据每期埋点的开发量评估出埋点上线时间（正式对外提供服务的时间，比如SDK更新时间、App页面改版时间），如表2-3所示。
表2-3 埋点上线时间表
需要规定好数据埋点上线流程各个阶段的时间节点（从需求梳理到最终上线）。在表2-4中，左侧的重点工作任务就是数据埋点的各个阶段，右侧给出了对应的时间节点。
表2-4 埋点需求的时间节点
开发人员完成埋点开发后，需要对本次埋点进行数据测试，测试埋点质量，比如能否统计到埋点数据、埋点数据是否有空值、埋点数据是否有丢失。（2.4节包含本次埋点的翔实测试样例。）埋点测试报告的样例见表2-5，该报告由测试人员提供。
表2-5 埋点需求测试报告（测试案例覆盖情况展示）
需求确认后，需要通过邮件将本次埋点的上线公告发送给埋点涉及的运营人员、开发人员、测试人员和产品经理。公告的具体内容如下。
搜索结果页（业务线位名称）—冰箱（类别）—坑位1（业务线位置）将于4月23日上线。
经过评审，新坑位可以实现和业务沟通确认的需求。
本期上线功能：
同测试需求。
在埋点上线后，需要通过邮件将本次埋点的上线验收说明发送给埋点涉及的运营人员、开发人员、测试人员和产品经理。验收说明的具体内容如下。
搜索结果页（业务线位名称）—冰箱（类别）—坑位1（业务线位置）已于4月23日上线。
针对本次埋点项目，对上线数据进行了埋点数据校验，校验结果如下。
本期效验功能：
同测试需求。
在埋点上线，有展现和曝光等数据以后，需要通过邮件将本次埋点的验收结果报告发送给埋点涉及的运营人员、开发人员、测试人员和产品经理。验收结果报告的具体内容如下。
搜索结果页（业务线位名称）—冰箱（类别）—坑位1（业务线位置）已于5月4日上线。
针对本次埋点项目，当前业务线曝光数据和点击数据请见报表。
数据来源：5月5日数据报表。
本节以笔者的工作经历为依据介绍埋点验证过程，并提供验证埋点的思路。读者可以将其作为参照，并结合自己所在公司的具体情况进行埋点验证。本节中的数据来源于2.3节介绍的实战案例。
要对App端搜索结果页坑位进行埋点，页面前端开发人员需要埋入埋点所需的全部参数，并且需要对曝光和点击分开埋点，即曝光埋点需要埋一次，点击埋点还需要埋一次。详细的埋点样例说明如下。
对于数据来源为广告系统的场景，须页面在targeturl字段中传入广告接口中的apsClickUrl参数。
因为App是使用路由跳转的，而广告使用点击进行计费，所以需要异步触发访问apsClickUrl进行计费。
目前App的点击事件，调用自定义接口进行上报，其中event_name固定为comclick。
App的曝光事件，调用自定义接口进行上报，其中event_name固定为exposure。
对于内嵌H5务必异步触发（需要多请求一次埋点链接，即请求两次）。使用sahref=apsClickUrl进行点击埋点，使用clickurl进行跳转。
注意，pageid、modid、eleid参数最好是字母和数字的组合，如果一定要有符号，不能有符号“.”。
表2-6给出了埋点需要埋的具体参数。
开发人员在埋入本次埋点需要的eleid、modid、pageid、targeturl等参数后（具体参数见2.3节，其中参数targeturl是广告参数，会有CPC和CPM等广告业务线信息、广告计划、广告跳转页面等），生成链接或二维码，告知测试人员进行测试。
测试人员浏览、点击冰箱搜索结果页中带有“广告”角标的广告位（见图2-3），测试广告位置的曝光、点击、页面传的参数等（见2.3.3节中的埋点参数）。
1.验证点击埋点
在测试工具Charles（网络公用的测试软件）中可以看到图2-4所示的请求信息，找到saSdkLog.gif的logType为2的报文。
表2-6 埋点需要埋的具体参数
（续）
图2-3 埋点坑位截图
图2-4 埋点报文截图1
复制图2-5中的logType=2＆saData=...行，并粘贴到数据采集系统中进行解密。
图2-5 埋点报文截图2
打开http://ssa.dianshang.com/ssa-config-web/ssa2-tools/index.html＃/msgDecryption。该链接平台是笔者公司的内部平台，外网打不开，读者可以在百度搜索“报文解析”，找到网络公用的报文解析平台。
依次选择“埋点测试”→“报文解密”，再将报文粘贴到文本域，最后点击“解密”按钮，见图2-6和图2-7。
图2-6 报文解析平台示例
图2-7 报文示例
搜索关键字“th.”（prd环境、xgpre环境、sit环境的关键字不同），检查targeturl是否正确（prd环境、xgpre环境、sit环境的URL是不同的，此处为prd环境），点击埋点的targeturl的参数需要与曝光日志一致。检查event_name，comclick表示点击日志（区别于曝光日志），见图2-8。
图2-8 点击埋点示例
2.验证曝光埋点
重新进入广告商品页面，点击商品页面查看logType为9的报文，见图2-9。
图2-9 曝光报文示例
报文解密后可以看到event_name为exposure，它表示曝光日志（区别于点击日志）。检查targeturl是否正确，其参数需要与点击日志的targeturl带有的参数相同，并且eleid、modid、pageid这些参数与点击日志中的值一致（见图2-10中的方框）。
图2-10 曝光埋点示例
3.验证埋点的异步触发
因为App是使用路由跳转的，而广告使用点击进行计费，所以需要异步触发访问apsClickUrl进行计费。（点击的时候需要异步请求apsClickUrl里的值，请求两次。）
具体的检查内容如下。
1）检查上报的＜head>＜title>是否为302。
2）检查event_name。报文解密后可以看到event_name：为exposure表示曝光日志，为comclick表示点击日志。
3）检查targeturl（具体埋点参数）是否正确。
4）检查eleid（坑位编码）、modid（模块编码）、pageid（页面编码）与点击日志中看到的值是否一致。
下面通过3张图来看看检查的内容。
检查上报＜head>＜title>的参数。图2-11为检查方框中上报的＜head>＜title>是否为302。图中出现的是302，说明上报正确。
图2-11 异步触发抓包的报文
检查点击日志。图2-12中的方框中是需要检查的埋点targeturl、eleid、modid、pageid、event_name。
检查曝光日志。图2-13中的方框中是需要检查的埋点targeturl、eleid、modid、pageid、event_name。
图2-12 异步触发点击埋点的样例
图2-13 异步触发曝光埋点的样例
经过大量的埋点需求项目实践，笔者总结出埋点的七个要点，简称“七字诀”（对应图2-1所示的点击埋点、曝光埋点协作流程）。
位 ：埋点的位置。
埋 ：埋点规范对接，前端开发埋点。
时 ：开发进行埋点后的联调时间、上线时间。
测 ：埋点在联调、上线时测试。
传 ：埋点测试通过后传的参数，埋点传参经过数据采集、数据仓库（对部分字段进行解析）。
表 ：埋点经过数据采集、数据仓库传参后落表，为实时或离线的Hive表。
统 ：埋点验证成功后的统计。