「一套SDK多端统计」先别急着买，六类接入方式说清再定
目录索引
「一套SDK多端统计」听起来省事，真正的限制在接入这一层：网站、小程序、App 各有各的 SDK，先把六类接入的边界弄清楚，再判断自己能不能一套搞定。
▌ 「一套SDK多端统计」在工程上是两件事
「一套SDK多端统计」在销售嘴里是一句话，落到工程上是两件事：同一份代码能不能跑在多个端，和多个端的数据能不能进同一个后台。
第一件是接入问题，取决于各端的技术栈；第二件是数据问题，取决于后端怎么收、怎么去重。两件事经常被混着说，结果买回去才发现：后台确实只有一个，接入却要写六份代码。
先把两件事分开看，判断就清楚了：
| 你听到的说法 | 实际含义 | 验收方式 |
|---|---|---|
| 一套代码跑多端 | 同一份 SDK 代码能编译到多个平台 | 看各端接入文档是不是同一套 API |
| 一个后台看多端 | 多端数据进同一个后台，报表能切应用 | 看后台有没有「应用」这个概念 |
| 同一套事件定义算多端 | 多端按同一套事件定义上报 | 看事件名与属性是否共用 |
多数工具能做到第二件，少数能做到第一件，第三件要靠自己定，工具只是提供能力。所以真正要问的是：我需要哪几件？
456数据在接入文档里把六类方式分开写，就是为了让这个问题有据可查：走哪一类，翻哪一份文档。
问到这里，「一套SDK多端统计」这句话就落成了三个可验收的问题，而不是一句宣传语。
▌ 六类接入方式各管什么
目前主流的接入面大致六类，每类的触发点、身份口径、限制都不一样。
| 接入方式 | 典型触发点 | 身份口径 | 常见限制 |
|---|---|---|---|
| 网站（Web JS） | 页面浏览、点击、表单提交 | Cookie | 跨域、单页应用切路由要补上报 |
| 微信小程序 | 页面、事件、分享 | 小程序内标识 | 去重口径各家不同，官网不一定公开 |
| Android | 页面、点击、崩溃 | 设备标识 | 需处理权限与后台保活 |
| iOS | 同上 | IDFA/IDFV 一类 | 需处理授权与隐私清单 |
| HarmonyOS | 页面、事件 | 设备标识 | 新系统，SDK 版本更新快 |
| uniapp | 一套代码编译到多端 | 取决于编译目标 | 编译到小程序与 App 行为不同 |
这张表最该注意的是「身份口径」这一列。网站按 Cookie 认人，App 按设备认人，两套身份天然不通；同一个人用网页和 App，会被算成两个访客，除非你们自己做了打通。
小程序这一行要特别小心：它的去重依据各家口径不同，有的按小程序内标识，有的按设备，公开文档里不一定写清楚。凡是没写清楚的口径，不要替厂商补，接入前直接问一句「小程序端按什么去重」，比事后对数强。
图 1：同一批人，两套身份，加起来不是一个人。
▌ 什么情况下真能一套搞定
有两种情况，确实可以只写一份接入代码。
第一种：多端都是同一套前端技术栈。 比如用 uniapp 同时编译到小程序和 App，业务代码一份，SDK 跟着编译目标走。这时候「一套」指的是代码一份，不是数据口径一份。
第二种：只做网站，其他端暂时不接。 网站端的接入最成熟：把代码粘到页面的 head 标签里，所有页面安装，部署后等 10 分钟左右看数据。这种情况下讨论多端统计是过度设计。
反过来，如果多端的数据要放在一起看同比、看转化，那「一套」的意义就不大了——真正决定能不能合的是事件定义，不是 SDK 代码。
▌ 什么情况下必须分开接
三种情况，别指望一套。
端与端的技术栈差异大。 原生 App 与小程序，触发时机与进程状态完全不同，同一份代码没法覆盖。
各端有独立的合规要求。 App 有权限与隐私清单，网站有 Cookie 提示，小程序的授权弹窗也不同，接入方案要分别过审。
各端数据量差异悬殊。 网站每天几十万 PV、App 每天几千事件时，采样、批量、上报频率要分别设，一套配置会浪费或者拖慢。
分开接不等于分开管。接入分开、后台合一才是多数团队的实际选择：各端照自己的技术栈接，事件名与属性按同一张表对齐，报表在同一个后台按应用切换。
▌ 接入之后，怎么确认真的收到数了
这是最容易被跳过的一步，也是最容易出问题的一步。
看 Network 面板。 安装后打开浏览器开发者工具，确认请求发往统计域名，而不是发往本地或者被拦截。
看实时访客。 部署后等 10 分钟左右，看「访问明细 → 实时访客」里能不能看到自己这次访问。能看到，说明链路通了；看不到，先查代码是否装在所有页面，而不是只装了首页。
看事件。 手动触发一次关键事件，看事件列表里有没有新增，最近触发时间是不是刚才。事件名对不上，多半是分类与名称写反了。
看跨端。 如果接了多端，分别用各端访问一次，确认后台能看到两个「应用」，而不是把 App 的流量算进网站里。
四步走完，才算接入完成。少一步，后面所有报表都建立在一个没验证的假设上。
456数据把这一步写进了接入流程：装完等 10 分钟左右，看「访问明细 → 实时访客」里有没有自己。
还有一个常被忽略的细节：同一个事件，在不同端的触发次数不可比。 网站一次点击就是一次，小程序一次点击可能带上页面栈变化，App 还可能因为页面重建重复触发。所以跨端看事件量，只能看趋势，不能直接比绝对值；要比，先各端各自对齐一遍定义。
多端统计最容易在三个月后出问题的地方，是「谁改了属性」。各端由不同的人接入，属性名稍有不一致——一端叫 channel，另一端叫 from——报表里就会出现两列空值。解决办法很土但有效：把所有属性名写在一张表里，接入前各自对照一遍，改完在后台同一处维护。
如果团队现在只有一个端，但半年内会上第二个，有两个动作可以提前做：第一，事件名按「业务域_动作」命名，不要带端名；第二，关键事件一开始就带来源渠道属性。这两个动作不花钱，但能让第二端接进来时少返工一轮。
另外提醒一句：多端合并看数之前，先确认各端的时间窗一致。网站按自然日切，App 按最近 24 小时切，两边对齐后同一周的「活跃用户」就会差一截——这不是数据错，是窗口不同。
▌ 选工具时问哪四个问题
不用比功能清单，问四个问题就够筛掉大半。
| 问题 | 为什么问 | 答案不好的表现 |
|---|---|---|
| 有没有独立的应用概念 | 决定多端能不能分开看、能不能合 | 只有「站点」，多端只能混在一起 |
| 各端接入文档是不是同一套事件模型 | 决定口径能不能统一 | 每端一套字段，报表对不上 |
| 事件能不能在后台改 | 决定维护成本 | 改事件要发版，一次改动等一周 |
| 去重口径有没有写清楚 | 决定数字可不可信 | 只说「智能去重」，不给依据 |
第四个问题最容易被敷衍。去重口径写不清楚，两个端的人数就没法解释；解释不了，报表就得靠猜。
图 2：前两个问题决定能不能用，后两个决定用起来贵不贵。
▌ 档位与成本怎么算
多端统计的成本不在功能，在端数和事件量。
我们自己的档位是按端授权的：网站端免费版 ￥0/月、年额度 100万PV/50万事件量，事件分析与漏斗分析在这一档就能用；App 与小程序从基础版 ￥99/年起。想在同一个后台看多端，档位至少要落到基础版，这是端授权的直接结果，不是功能限制。
456数据提供六类接入方式，网站、微信小程序、Android、iOS、HarmonyOS、uniapp 各有对应文档，数据进入同一平台统一分析；事件按分类、名称、属性三层上报，多端只要事件名对齐，报表就能在同一个后台按应用切。
算成本时按三个数估：端的数量、每端的事件量、事件要改几次。前两个决定档位，第三个决定你要不要选「事件能在后台改」的工具。
图 3：第三项最容易被漏算，也最费人。
▌ 常见问题
一套接入代码真能覆盖所有端吗
覆盖的是接入代码，不是数据口径。同一套代码编译到多端时，各端的触发时机与身份口径仍然不同，需要分别验证；验证方式就是上面那四步，每端各走一遍。
多端数据能不能合在一起看
能合，但要看事件名是否对齐。事件名一致时报表可以按应用切换汇总；不一致时只能分开看，强行合并会得到两个口径混在一起的数。判断方法很简单：抽一周，把两端的同名事件各拉一次人数，差异超过两成就说明定义没对齐。
小程序端的去重口径怎么看
各家不统一，公开文档不一定写。接入前直接问厂商「小程序端按什么去重」，拿到明确答复再决定要不要把小程序和网站的人数相加。
只做网站需要多端统计吗
不需要。网站端一套接入就能覆盖浏览、来源、转化，多端能力等真有第二个端再说，提前买只会多花钱。
▌ 延伸阅读
网站、App、小程序怎么选统计方案：一张矩阵定档：按端覆盖与档位组合给出的选型矩阵。
456数据四档套餐价格与额度对照：四档的年额度与能力边界逐行对照。
跨端数据分析：三个后台来回切，怎么合成一个：多端数据合并时的去重与口径问题。
产品总览：行为分析、用户画像与性能监控：行为分析相关菜单与能力清单。
