数据准确性、业务价值、设备性能三大核心:
5个原则:
业务导向:所有埋点必须对应具体业务场景,拒绝"无意义全量采集"(如仅采集OS核心功能操作,不冗余采集设备基础状态)。
性能优先:OS设备性能差异大,不能影响OS核心稳定性,需控制埋点对CPU、内存、电量的消耗,避免影响用户体验,必须异步、轻量。
统一规范:埋点命名、参数格式、上报策略全链路统一,降低后续数据清洗与分析成本。
质量可控:支持埋点灰度发布、数据实时监控,确保上线后数据无丢失、无异常。
隐私合规:严格遵守GDPR、CCPA等法规,MAC地址、IMEI等敏感信息需匿名化或禁止采集。加密传输:HTTPS+数据脱敏(符合GDPR/《个人信息保护法》)
xml
|维度 |建议 |
|采集策略|核心业务流程用代码埋点,通用行为用全埋点补充 |
|性能优化|高频埋点采用异步队列,批量上报减少网络请求 |
|隐私合规|采集前获取用户授权,敏感数据加密传输 |
|数据验证|建立埋点管理平台,监控埋点覆盖率和数据质量 |前端埋点(用户事件、界面变化)类型选择:
xml
埋点类型 说明 适用场景 优缺点 设备适配建议
代码埋点 在特定代码位置植入统计代码 核心业务操作、异常监控、自定义事件 精准可控,支持复杂参数;需开发成本/依赖app发版 优先使用,针对高频操作优化上报逻辑
可视化埋点 通过可视化界面配置埋点 页面点击、简单按钮操作 低开发成本,灵活调整;精度略低 辅助使用,仅用于非核心、低频次操作
全埋点 自动收集所有可交互元素行为 全量行为采集(备用) 数据全量;性能开销大,易产生垃圾数据 仅用于临时调研,禁止长期全量开启后端埋点/服务端埋点:收集数据在服务端进行(http request发生时的数据)，如业务逻辑数据交互等对数据安全性要求高的
命名规则:统一前缀+业务模块+事件名称,例:os_login_success、os_feature_click、os_crash_unknown。
xml
|原则 |说明 |示例 |
|小写+下划线 |全小写,单词用下划线分隔 |page_view,button_click |
|动词+名词 |动作在前,对象在后 |submit_order,play_video |
|避免歧义 |同一含义只用一种表达 |不用click_btn和button_click混用|
|业务前缀 |多业务线加前缀区分 |mall_add_cart,live_enter_room|核心参数设计(必选+可选):
必选参数(通用，适配所有OS设备):设备ID(唯一标识)、OS版本、机型、网络类型、用户ID(登录后填充)、事件发生时间戳。
可选参数(按场景补充):
操作类:页面路径、按钮名称、操作时长;
异常类:错误码、错误堆栈、异常发生模块;
业务类:功能配置参数、操作结果(成功/失败)。
例如:
1.核心功能操作埋点(例:OS功能点击/页面跳转)
事件设计:os_page_enter(页面进入)、os_feature_click(功能点击)、os_page_exit(页面退出);
参数示例:
os_page_enter:page_name(首页/设置页/功能页)、enter_type(主动进入/跳转进入);
os_feature_click:feature_name(网络设置/存储管理)、click_position(按钮位置)。
业务价值:统计各功能使用率、页面访问深度，优化功能入口设计。
2.启动与退出埋点(OS核心体验指标)
事件设计:os_app_launch(启动)、os_app_launch_fail(启动失败)、os_app_exit(退出);
参数示例:
os_app_launch:launch_duration(启动耗时)、launch_scene(冷启动/热启动);
os_app_launch_fail:error_code(启动错误码)、fail_reason(内存不足/权限缺失)。
业务价值:监控启动成功率、耗时分布，定位启动瓶颈，优化启动体验。
3.异常监控埋点(OS设备稳定性关键)
事件设计:os_crash(崩溃)、os_anr(应用无响应)、os_performance_warn(性能告警);
参数示例:
os_crash:crash_module(系统内核/应用层)、crash_stack(堆栈信息)、device_model(崩溃机型);
os_performance_warn:warn_type(CPU占用过高/内存泄漏)、warn_value(占用率数值)。
业务价值:统计不同机型/OS版本的异常率，针对性优化设备兼容性。
4.设备适配埋点(OS差异化特性)
事件设计:os_device_config(设备配置采集)、os_compatibility_check(适配检查);
参数示例:os_version(系统版本)、hardware_config(硬件配置)、compatibility_result(适配结果)。
xml
类型 定义 特点
冷启动 App被系统杀死后,重新启动应用 后台不存在该应用进程,需要完整初始化
热启动 App未被系统杀死,仍在后台运行,重新打开应用 后台已有进程,可直接恢复上报机制:
定时上报:5分钟聚合后批量上报,减少IO消耗;
阈值触发/缓存阈值:本地缓存达到一定大小(如50条)时触发上报,避免缓存溢出
冷启动上报/即时上报:核心操作(如登录、支付、关键功能点击),确保数据不丢失
触发条件:
网络限制:仅在Wi-Fi/4G以上网络上报,避免消耗用户流量;
电量限制:低电量(<20%)时暂停非必要埋点,减少电量占用;
隐私与合规处理
匿名化:不收集IMEI,改用OAID(安卓)或VendorID
用户授权:在系统设置中提供"用户体验计划"开关
数据最小化:只采集必要字段,避免敏感信息(如通讯录、短信)
设计埋点事件的原则
同种属性的多个事件:要命名成一个埋点事件ID,并以Key-Value的形式区分。例如,对于"按钮点击"这类同种属性的多个事件(如不同按钮的点击),可以用一个埋点事件ID,再通过Key-Value(比如Key为"button_id",Value为不同按钮的标识)来区分具体是哪个按钮的点击事件。
不同属性的多个事件:应该命名成多个埋点事件ID,此时也尽量不用Key-Value的形式埋点。比如"页面浏览"和"商品购买"属于不同属性的事件,应分别为它们设置不同的埋点事件ID,而不是试图用Key-Value把它们合并到一个事件ID里。
Key-Value形式的埋点设计规划
Key的含义:Key一般表示某个事件(或事件的某个维度/属性)。
Value的含义:Value代表相对应的值,用于描述Key所代表的事件(或维度)的具体信息。
Key-Value的对应关系:一个Key可以对应一个Value或者多个Value。例如,Key为"product_category"(商品类别),Value可以是"服饰""数码"等多个值,用以记录不同类别的商品相关的事件信息。
功能:统计新股新债和ETF专区两个按钮的点击事件。
用户行为:在不同页面点击新股新债和ETF专区按钮。
xml
|事件类型(ActionType) |Key |Value |描述 |
|Click |page |sy |进入首页记录一次 |
|Click |page |jy |进入交易页面记录一次 |
|Click |source |xgxz |点击新股新债按钮记录一次 |
|Click |source |etfzq |点击ETF专区按钮记录一次 |一个完整的事件(Event),包含如下的几个关键因素:
4W1H要素完整
xml
{
"who": "user_id", //谁 即参与这个事件的用户是谁
"when": "timestamp", //何时 即这个事件发生的实际时间
"where": "page_url", //何地 即事件发生的地点
"what": "event_name", //做了什么 以字段的方式记录用户所做的事件的具体内容
"how": { //怎么做/附加信息 即用户触发这个事件的方式或上下文信息
"device": "iPhone14",
"source": "push_notification"
}
}简单来说,一个Event就是描述了:一个用户在某个时间点、某个地方,以某种方式完成了某个具体的事情。从这可以看出,一个完整的Event,包含如下的几个关键因素:
Who:即参与这个事件的用户是谁。在我们的数据接口中,使用distinct_id来设置用户的唯一ID:对于未登录用户,这个ID可以是cookie_id、设备ID等匿名ID;对于登录用户,则建议使用后台分配的实际用户ID。同时,我们也提供了track_signup这个接口,在用户注册的时候调用,用来将同一个用户注册之前的匿名ID和注册之后的实际ID贯通起来进行分析。
When:即这个事件发生的实际时间。在我们的数据接口中,使用time字段来记录精确到毫秒的事件发生时间。如果调用者不主动设置,则各个SDK会自动获取当前时间作为time字段的取值。
Where:即事件发生的地点。使用者可以设置properties中的ip属性,这样系统会自动根据ip来解析相应的省份和城市,当然,使用者也可以根据应用的GPS定位结果,或者其它方式来获取地理位置信息,然后手动设置ip属性,这样系统会自动根据ip来解析相应的省份和城市,当然,使用者也可以根据应用的GPS定位结果,或者其它方式来获取地理位置信息,然后手动设置ip属性,这样系统会自动根据ip来解析相应的省份和城市,当然,使用者也可以根据应用的GPS定位结果,或者其它方式来获取地理位置信息,然后手动设置city和province。除了province。除了province。除了city和$province这两个预置字段以外,也可以自己设置一些其它地域相关的字段。例如,某个从事社区O2O的产品,可能需要关心每个小区的情况,则可以添加自定义字段HousingEstate;或者某个从事跨国业务的产品,需要关心不同国家的情况,则可以添加自定义字段Country。
How:即用户从事这个事件的方式。这个概念就比较广了,包括用户使用的设备、使用的浏览器、使用的App版本、操作系统版本、进入的渠道、跳转过来时的referer等,目前,神策分析预置了如下字段用来描述这类信息,使用者也可以根据自己的需要来增加相应的自定义字段。
xml
$app_version:应用版本
$city:城市
$manufacturer:设备制造商,<字符串String>,如Apple
$model:设备型号,<字符串String>,如iphone6
$os:操作系统,<字符串String>,如iOS
$os_version:操作系统版本,<字符串String>,如8.1.1
$screen_height:屏幕高度,<数值Number>,如1920
$screen_width:屏幕宽度,<数值Number>,如1080
$wifi:是否WIFI,<布尔Bool>,如trueWhat:描述用户所做的这个事件的具体内容。在我们的数据接口中,首先是使用event这个事件名称,来对用户所做的内容做初步的分类。event的划分和设计也有一定的指导原则,我们会在后文详细描述。除了event这个至关重要的字段以外,我们并没有设置太多预置字段,而是请使用者根据每个产品以及每个事件的实际情况和分析的需求,来进行具体的设置,下面给出一些典型的例子:
xml
对于一个购买类型的事件,则可能需要记录的字段有:商品名称、商品类型、购买数量、购买金额、付款方式等;
对于一个搜索类型的事件,则可能需要记录的字段有:搜索关键词、搜索类型等;
对于一个点击类型的事件,则可能需要记录的字段有:点击URL、点击title、点击位置等;
对于一个用户注册类型的事件,则可能需要记录的字段有:注册渠道、注册邀请码等;
对于一个用户投诉类型的事件,则可能需要记录的字段有:投诉内容、投诉对象、投诉渠道、投诉方式等;
对于一个申请退货类型的事件,则可能需要记录的字段有:退货金额、退货原因、退货方式等。埋点文档规范
xml
场景:业务场景(非必填,方便检索) 描述埋点对应的业务场景(如"商品详情页""支付成功页"),帮助快速定位埋点的业务上下文,非必填但建议补充,便于后续数据检索与分析。
事件英文名:这件事的概括(代码用) 代码层面的事件标识(如click_buy_btn),需简洁、可读性强,方便开发在代码中埋点时引用。
事件显示名:给自己或者其他业务人员看 业务层面的事件描述(如"点击购买按钮"),让产品经理、运营等非技术人员快速理解事件含义。
属性英文名:能详细说明事件里的信息(代码用) 事件的附加信息字段(如product_id"商品ID"、price"价格"),代码中用于传递事件的细节数据。
属性显示名:给自己或者其他业务人员看 业务层面的属性描述(如"商品ID""商品价格"),帮助非技术人员理解属性含义。
属性值示例或说明:字段的具体值,例举格式规范,取数逻辑 明确属性值的格式/逻辑(如product_id的示例是1001,格式为"数字"；price的示例是29.9,逻辑为"取商品最终售价"),确保数据采集的一致性。
事件触发条件:要被记录的行为。像"点击"、"长按" 明确事件触发的行为规则(如"用户点击'购买'按钮时触发""用户长按商品图片3秒时触发"),确保埋点逻辑与业务行为一一对应,避免漏埋/错埋。
xml
场景| 事件英文名 | 事件显示名 | 属性英文名 | 属性显示名| 属性值示例或说明 | 事件触发条件
分享| ShareChannel| 第三方渠道分享| channel_name| 渠道名称 | 微信、朋友圈、QQ好友、QQ空间、新浪微博、复制链接、分享图片| 点击分享渠道时上报事件: submit_order (提交订单)
xml
|字段 |类型 |必填|说明 |示例 |
|event_time |timestamp |Y |事件时间 |1699123456789 |
|order_id |string |Y |订单号 |ORD20231101001 |
|sku_list |array |Y |SKU列表 |[{"sku_id":"123","qty":2}] |
|order_amount|decimal |Y |订单金额 |299.00 |
|source_page |string |Y |来源页面 |cart/detail/direct_buy |
触发时机: 用户点击"提交订单"按钮,服务端返回成功
版本记录:
-v1.0.0: 初始版本
-v1.2.0: 新增source_page字段核心设计原则清单
xml
|原则 |具体要求 |
|单一职责 |一个事件只描述一个明确动作 |
|不可变追溯|事件一旦上报，内容不再修改 |
|向后兼容 |新增属性，不删除旧属性 |
|最小够用 |属性数量控制在20个以内 |
|敏感脱敏 |手机号、身份证号等加密或脱敏|数据流向
端侧(OS):采集 -> 聚合 -> 压缩 -> 加密 -> 存储。
传输:HTTPS(或MQTT长连接) -> 批量上报。
服务端:接收网关 -> 数据校验 -> 分发至Kafka -> 实时计算/离线数仓。
应用:监控大盘(实时展示OS崩溃率) -> 日志检索(排查用户具体问题) -> 行为分析(优化产品功能)。
埋点验收与问题排查(面试必问)
1.埋点验收核心动作
数据准确性:对比埋点上报日志与业务实际操作，验证事件、参数是否完整无缺失;
数据一致性:多设备/多版本验证，确保上报格式、参数含义统一;
性能验证:监控埋点对设备CPU、内存、流量的影响，控制在合理阈值(如CPU占用<1%)。
2.常见埋点问题及解决方案
xml
问题类型 排查步骤 解决方案
数据丢失 1.检查埋点代码是否触发,2.查看本地缓存是否有数据,3.排查网络/上报策略限制 1.修复代码逻辑,2.调整上报阈值,3.优化网络兼容逻辑
数据重复 1.检查上报是否重复触发,2.排查缓存未清理问题 1.增加去重标识(如事件唯一ID),2.定时清理已上报缓存
性能开销大 1.监控埋点模块CPU/内存占用,2.分析上报频率是否过高 1.优化埋点代码效率,2.降低非核心操作上报频率
数据异常(参数缺失/错误) 1.核对参数设计与上报代码,2.排查版本兼容问题 1.统一参数规范,2.针对不同OS 版本做兼容适配需求拆解、方案设计、落地执行、验收优化四步设计OS埋点方案:
需求拆解:先对接业务方,明确核心目标(如提升启动体验、监控设备稳定性),拆解核心业务场景/具体指标(DAU、功能使用率、异常率);
方案设计:优先选择代码埋点保障精准性,统一命名/参数规范,按操作重要性区分即时/批量上报策略;
落地执行:针对OS核心场景(启动、功能点击、异常)设计具体埋点,先对10%的目标机型/OS版本灰度上线发布验证,监控数据指标(上报率、异常率、性能消耗);
验收优化:通过监控上报率、性能消耗定位问题,定期清理无效埋点(无业务使用、数据无波动),保持体系轻量化。
比如在OS启动场景,我会设计os_app_launch和os_app_launch_fail事件,采集启动耗时、错误码,既监控成功率,又定位瓶颈。