埋点

如何选择埋点方式？

代码埋点：对埋点事件进行传参等自定义属性设置。较复杂，但功能最完善，覆盖了埋点中的不同业务需求

可视化埋点：分析或统计需求简单，无需对埋点事件进行传参等自定义属性设置，频繁上线或更新的H5类型的运营活动。

无埋点：分析或统计需求简单，无需对埋点事件进行传参等自定义属性设置。针对快速，频繁上线和迭代的H5类型的运营活动的评估

前端埋点：业务运营初期阶段，产品功能较简单；分析与后端没有交互的前端行为；

后端埋点：在各行业中有特殊业务需求的数据。

如何设计前后端埋点：

前端埋点：不仅是key-value形式，不同场景，会更复杂

后端埋点：使用key-value的形式进行埋点

前端埋点：

应用场景：需自定义埋点事件属性才能满足记录用户在客户端的操作行为、分析业务环节

优点：需采集全面完整的事件属性数据；有些不需要请求服务器行为，智能使用前端埋点，如：页面停留时长

缺点：需前端开发，人力成本高；会产生延迟上报和5-10%左右的漏报丢失（如客户端未联网、数据打包上报、用户删除行为数据等原因造成）；若客户端是APP，需要用户主动更新版本，新版本埋点才会生效

后端埋点：

应用场景：采集非点击、不可视行为；需整合用户属性信息和行为的数据；前后端都能采集到的信息，优先选后端方式

比如：抢群微信红包（红包人数小于群人数，即非人人可得）等需求请求服务器，否则用前端埋点可能会产生用户端显示获得红包，但实际红包已经被发完了，就会被用户投诉。

优点：支持用户身份信息和行为的整合；实时采集、无延误上报、数据准确；发版即生效，不需要前端和用户更新。

缺点：需服务端开发，人力成本高；不能直接采集发生在前端，不请求服务器的行为数据，获取前端属性需接口开发。

可视化埋点：

可视化埋点是把核心代码和配置、资源分开，通过部署在产品上的基础迭代对产品的所有交互元素进行解析，并在可视化页面进行设定，界面启动时后端（服务器）更新配置和资源。用户产生操作行为后，根据配置上报相关内容。

应用场景：分析或统计需求简单，不需要对埋点事件进行自定义传参；需频繁/紧急上线的H5运营活动

优点：节省开发、更新埋点的工期和人力；降低门槛，业务、运营可通过可视化界面配置和统计埋点；不受迭代版本影响

缺点：覆盖功能有限；不能自定义交互事件；不能支持内容瀑布式交互；一般借助第三方公司提供的埋点SDK，有数据安全隐患，且不便于改善丢包问题

全埋点（无埋点）：

复用同一套全面的SDK埋点方案，先采集所有控件的数据，有选择的配置需要分析的空间。（可视化埋点是先选择要采集数据的控件）

应用场景：分析或统计需求简单，不需要对埋点事件进行自定义传参；需频繁/紧急上线的H5运营活动

优点：节省开发、更新埋点的工期和人力，只要部署SDK；可获得全量数据进行分析，便捷的通过各种热力图等快速分析；不受迭代版本影响

缺点：传输数据大，消耗数据存储资源；不能自定义交互事件；一般借助第三方公司提供的埋点SDK，有数据安全隐患，且不便于改善丢包问题

埋点方式如何选择：

产品生命周期：导入期、成长期、成熟期、衰退期

一般导入期用户少用全埋点，后面混合埋点

如果您想深度分析，选择后端埋点和无埋点组合的方案；如果您只是想看宏观数据，可以选择无埋点。无论采用哪种埋点方式，一定要慎重，根据需求来设置，最好不要出现错埋或漏埋的情况。

埋点工具推荐：

• 企业自研
• 第三方

免费：百度统计、友盟（针对全埋点方案）

收费：神策数据、growingIO、TalkingData、诸葛ID等

埋点采集流程分析：

梳理业务——》确定需求——》设计事件——》数据采集——》构建指标体系——》数据分析

比如：

业务部门	需求场景（示例）	指标细化（示例）
产品部	希望查看用户在注册过程中，体验是否顺畅，新用户是否能顺利完成注册	用户注册流程转化率，包括以下步骤：注册页面——》发送验证码——》提交注册信息——》注册完成
运营部	希望了解用户在购买过程中，是否流程	购买转化漏斗：启动应用——》浏览商品详情页——》加入购物车——》提交订单——》支付订单
市场部	希望查看不同渠道来源的用户流量大小和流量质量	新设备数、新注册用户数、跳出率（分渠道查看）

埋点需求梳理模板

需求部门	应用场景	指标	指标释义	分析维度	备注
市场部	渠道推广分析	推广页面PV	渠道推广时的落地页的浏览次数PV	推广渠道/推广关键词/推广类型	可用于评估渠道流量大小
产品部	基础指标	新设备注册率	当天安装产品后，首日注册用户数/新设备数	地区/操作系统、应用版本/时间（日/周/月）	可用于评估产品对新设备的吸引力

对指标进行分析，该指标可以通过什么时间转化而来

用户行为	行为属性	属性值类型
浏览商品	商品ID	字符串
	商品名称	字符串
	商品所属品类	字符串
	商品价格	字符串
	商品优惠金额	字符串

数据埋点文档DRD

事件ID	事件名称	属性ID	属性名称	属性值类型	属性说明	埋点时机	埋点事件说明
pageview	页面浏览	url	页面url	字符串	页面url	前端	页面浏览包括ios、安卓、小程序采集的所有页面浏览事件，集成神策sdk之后，打开自动埋点采集即可，参考文档：xxx

有一些坑得注意

上报时机要准确；事件要尽量合并；抽离出公共属性

设计埋点事件的原则

同种属性的多个时间要命名成一个埋点事件ID，并以key-value的形式区分，不同属性的多个事件应该命名成多个埋点事件ID，此时也尽量不用key-value的形式埋点。

key-value形式的埋点设计规划：key一般表示某个时间，value代表相对应的值，一个key可以对应一个value或多个value

经过梳理指标体系和指标字典，明确了要分析活动入口的点击量等数据，如果对活动入口的点击量进行埋点统计？

方案1：每个埋点代表一个事件，这种维护成本太高了，比如入口特别多种，就得加多种事件

事件ID：页面来源page（活动A、活动B）和元素类型source（酒店入口按钮、旅游入口按钮）

方案2：key-value形式

方案2优点：维护成本低，更简单高效，新增时只需要在更新埋点文档时加一个value参数即可；减少沟通成本，提高其他业务人员，数据分析师根据埋点日志进行查询分析的效率；扩展性好，对未来上线新活动或者业务的调整等更加灵活，可在原有基础上扩展。

计算页面停留时长=离开页面时间 - 进入页面时间

埋点误区

埋点没那么重要，简单设计即可；在业务中都使用无埋点方式；所有业务都使用同一套埋点采集方案。

埋点数据采集之道

如何玩转描述和记录用户的每一次行为，可以使用事件模型：事件4w1h方法论 who when where how what 。 有数据就可以做分析