1、埋点基础：什么是埋点、埋点的价值、埋点的类型

大家好，我是这门课的主讲。做了快十年用户增长，我经手过的产品少说也有二十多个。每次带新人，第一个要讲透的就是埋点。为什么？因为埋点是一切用户行为分析的起点。没有数据，你所有的增长策略都是拍脑袋。

说白了，埋点就是在你的产品代码里，有意识地安插一些「记录器」。用户点了哪里、停留了多久、在哪个页面流失了——这些信息都会被记录下来，送到后端做分析。嗯，就这么简单。

1.1 埋点的价值：为什么非做不可？

我记得刚入行那会儿，带我的老大说过一句话，我一直记到现在：「没有埋点的产品，就像蒙着眼睛开车。」你觉得自己开得挺稳，其实随时可能翻沟里。

埋点的价值，我归纳为三个层面：

• 量化用户行为——PV、UV、点击率、转化率，这些指标全靠埋点才能算出来。没有埋点，你连DAU是怎么涨的都不知道。
• 定位产品问题——用户为什么在支付页流失？是加载太慢，还是按钮不明显？埋点数据能告诉你答案。
• 驱动增长决策——A/B测试、漏斗分析、留存分析，所有增长实验都依赖埋点提供的数据基础。

我在项目中遇到过最典型的例子：某电商App的「加入购物车」按钮点击率一直上不去。产品经理改了三版文案，设计师调了五次颜色，都没用。后来一查埋点数据才发现，按钮在首屏底部，60%的用户根本滑不到那里。你看，没有埋点，你连问题在哪都找不到。

1.2 埋点的三种类型

目前业界主流的埋点方案有三种。我按自己的理解，给你排了个序：从最灵活到最省事。

代码埋点

这是最传统、也是最可靠的方式。开发人员在需要采集的位置，手动调用埋点SDK的API。比如用户点击「注册」按钮时，你可以在点击事件里加一行：

// 代码埋点示例
registerButton.addEventListener('click', function() {
  // 采集注册按钮点击事件
  tracker.track('register_click', {
    page: 'home',
    source: 'banner',
    userId: getCurrentUserId()
  });
});

我个人习惯用代码埋点来处理所有核心转化路径。为什么？因为你可以携带任意业务参数。比如上面这个例子，我不仅知道用户点了注册，还知道他是从首页banner进来的。这种上下文信息，全埋点给不了你。

全埋点

全埋点也叫「无埋点」或「全量采集」。你只要在App或网页里集成一个SDK，它就会自动采集所有用户交互——点击、滑动、页面浏览、输入框聚焦……几乎无所不包。

听起来很美好对吧？但这里有个坑。我曾经接手过一个项目，前任团队上了全埋点，每天产生几亿条事件。数据分析师光清洗数据就要花半天。而且全埋点采集的事件是「无语义」的——它只知道用户点了一个<div>，但不知道这个<div>是「立即购买」按钮还是「联系客服」入口。

可视化埋点

可视化埋点算是前两种方案的折中。运营或产品经理可以在后台打开一个页面，然后用鼠标「圈选」某个按钮，系统就会自动生成对应的埋点代码。整个过程不需要开发介入。

我记得有一次做活动页，运营临时要加一个「分享得优惠券」的按钮，第二天就要上线。按正常流程，提需求给开发、排期、测试、发版，至少三天。用可视化埋点，运营自己花十分钟就配好了。嗯，这种场景下它确实香。

但可视化埋点也有硬伤：如果页面结构变了（比如前端重构了DOM），之前配的埋点可能全部失效。另外，动态加载的内容（比如弹窗、下拉加载）也很难圈选。

1.3 三种埋点的选型策略

你可能会问：那我到底该用哪种？

我的经验是：不要只用一种，要组合使用。下面这张图是我自己总结的埋点选型框架：

你看，这三种方案不是互斥的。我现在的团队，核心业务用代码埋点，日常监控用全埋点，运营活动用可视化埋点。各取所长，效果最好。

1.4 埋点数据的基本结构

不管用哪种埋点方式，最终上报的数据结构都大同小异。我一般把埋点事件拆成三个部分：

• 事件标识——事件名称（如 register_click）、事件ID
• 公共属性——设备信息、用户ID、时间戳、网络环境等
• 业务属性——页面来源、按钮位置、商品ID等自定义参数

举个例子，一个完整的埋点事件JSON大概长这样：

{
  "event": "purchase_click",
  "timestamp": 1696000000000,
  "common": {
    "user_id": "u_12345",
    "device": "iPhone 15",
    "os": "iOS 17",
    "network": "wifi"
  },
  "properties": {
    "product_id": "p_67890",
    "price": 299.00,
    "source": "search_result",
    "page": "product_detail"
  }
}

这里要注意：公共属性最好由SDK自动采集，业务属性由开发手动传入。我曾经见过一个团队，把用户ID也写在业务属性里，结果每次改版都要改代码，折腾得够呛。