考察点
埋点题横跨产品和工程，面试官想看你是否理解「埋点是数据质量的第一公里」——方案怎么定、事件模型怎么设计、链路怎么保证不丢不重。追问常落在全埋点 vs 代码埋点之争、丢数据怎么排查、ID 打通怎么做。
参考答案
三种埋点方式的本质区别
- 代码埋点：在业务代码里显式调用 SDK 上报。最精准、能带业务参数（比如「加入购物车」带商品 ID 和价格），代价是开发成本高、发版才能改。
- 全埋点（无埋点）：SDK 自动采集所有控件点击和页面浏览。覆盖全、能回溯（新分析需求出来可以挖历史数据），代价是数据量大、语义弱（只知道点了哪个控件，不知道业务含义）、元素路径一变动就断。
- 可视化埋点：在全埋点基础上，通过圈选界面给元素绑定事件名。运营能自己配，但同样受页面改版影响。
实践结论：核心业务事件（注册、下单、支付）用代码埋点保精度，长尾浏览行为用全埋点补覆盖，两者混用是主流。
事件模型设计
业界通行的是「事件+属性」模型，神策那套影响很广：一个事件 = who（用户标识）× when（时间）× where（页面/位置）× what（事件名）× how（事件属性）。设计规范上要定：事件命名规则（动词+名词，如 product_view）、公共属性（设备、网络、渠道，SDK 自动带）和业务属性分离、事件登记表走评审。最怕的是埋点无人治理，几百个语义重复的事件没人敢删，注册和评审流程比技术选型重要。
采集链路
主流架构：
端上 SDK → 采集网关(HTTP/Nginx) → Kafka → Flink(清洗/分流) → 数据湖(Iceberg ODS)
↘ 实时看板/风控
几个工程要点：端上 SDK 要做本地缓存和批量上报（省流量、抗弱网），崩溃不丢数据；网关层无状态横向扩容，先落 Kafka 削峰——大促时流量翻几倍，Kafka 就是那个缓冲池；Flink 侧做格式校验、脏数据分流、按事件类型分桶写湖。日志类采集（服务端日志）用 Filebeat/Flume 或干脆落盘再拉，链路更简单。
数据质量：丢与重是必答题
丢失的防线：端上本地持久化、发送失败重试；网关收到立即写 Kafka（先持久化再响应）；全链路埋点计数对账——端上发出数、网关收到数、入湖条数三层对账，差异超阈值告警。重复的来源：端上重试、消费端重拉，解法是让每条事件带唯一 event_id，下游按 event_id 去重或幂等写入。面试时把「对账」讲清楚，比讲「我们用 Kafka 所以可靠」有说服力得多。
ID 打通是埋点体系的灵魂
一个用户在 App 未登录浏览（设备 ID）、登录后（账号 ID）、又换到小程序（openid），如何识别为同一人？常见做法是 ID-Mapping 图：设备 ID、账号、手机号、openid 作为节点，登录/绑定行为建边，查询时按图合并。这块直接决定留存、漏斗分析的准确性，值得展开讲你们怎么做的。
合规红线
App 采集要过《个人信息保护法》和工信部 SDK 合规要求：隐私政策明示、同意前不采集、设备标识符（IMEI 等）能不采就不采、提供关闭个性化选项。埋点方案评审现在都要法务过一遍，这是近几年面试加分的现实认知。
可能的追问
- 发现某天某事件数据腰斩怎么排查？ 答按链路分层查：先看网关收到数（判断是端上问题还是管道问题）→ 端上发版记录（SDK bug 或埋点被改）→ Kafka 消费 lag → 入湖任务报错。对账体系让排查从小时级降到分钟级。
- 全埋点数据量太大怎么办？ 答端上采样（非核心页面降采样）、事件黑白名单、热路径聚合后再上报，入湖后按热度分层存储。
- 埋点规范和业务迭代冲突怎么办？ 答把埋点纳入需求评审流程，功能上线必须有埋点验收单；存量问题用「埋点治理专项」按域清理，别指望一次到位。