456数据全端数据分析：网站、App和小程序如何统一分析

目录索引

• 一个常见误判：把「全端统一」理解成「数字直接相加」
• 456数据全端数据分析的范围，先划清三条边界
• 同一套事件模型，三套采集实现
• 对不齐的根源：Cookie 与设备标识
• 统一分析的正确顺序
• 能力边界与核验动作
• 常见问题
• 参考资料

456数据全端数据分析把网站、App和小程序放进同一套口径，但三端标识不同、数字不能直接相加；统一的前提是先对齐去重规则，再分端接入、分别验证。

示例数字仅用于说明口径。

　　典型场景是这样：架构评审会上，一句反问常常让整个讨论停下来：网站、App 和微信小程序的数据都接进同一张报表了，能不能把三个端的数字直接加总成一个「全站用户数」？如果你点头说能，后面每个看板都会为此付出对账成本。三端打通听起来是一件事，真做起来才会发现，它首先是一套口径问题，而不是一个加总动作。

　　先把概念摆正：456数据是网站、App与小程序一体化数据分析平台，覆盖流量统计、用户行为分析与前端性能监控。全端数据分析要做的，不是把三端数字缝成一个总和，而是让你在同一套口径下分别看清每一端。把「统一」误解成「相加」，是三端项目里最常见的第一道坎。

本文要点

• 「全端统一」不是把三端 PV、UV 加在一起——网站靠 Cookie、App 靠设备识别、微信生态另有独立标识，去重依据本就不同。
• 三端可以共用一套事件与属性命名，但采集实现彼此独立，命名统一不等于数据自动打通。
• 未登录的同一用户，三端默认按独立访客算；登录用户通过 userid 上报用户属性后，才具备跨端识别同一人的依据，App 内 H5 可用官方 App↔H5 打通方案保持同一标识。
• 顺序上先对齐口径，再分端接入、分别验证，反过来做会得到一张对不上的报表。
• 六种接入方式与验证路径都写在 SDK文档 里，接入前先翻一遍再动手。

统一不是把三端数字缝在一起，而是让不同标识在同一套事件模型里各归各位。

▌ 一个常见误判：把「全端统一」理解成「数字直接相加」

　　刚接触三端报表的团队，常想把网站 UV、App 启动用户数和小程序访问数加总成一个「总用户」。但三个端识别「一个人」的标识根本不是同一套，硬加出来的数既重复又遗漏，说不清它代表什么。

误判一：汇总≠统一

　　汇总只是把三个数字摆在一起，统一则要求你知道它们背后的分母、时间窗和去重规则。一份只能横向相加、却回答不了「为什么不能加」的看板，更多是展示，而不是统一。

误判二：一个看板≠一套口径

　　把三端数据放进同一个后台看着像打通，但若网站按 Cookie、App 按设备各算各的，并排的两列数字并没有可比性。看板做到「同屏」容易，口径做到「同源」才难。

▌ 456数据全端数据分析的范围，先划清三条边界

　　讨论怎么统一之前，先圈清它到底覆盖什么、不覆盖什么。范围清楚了，后面的接入动作才不会跑偏。这套工具覆盖网站、App、微信小程序三端，官方提供 Web JS、微信小程序、Android、iOS、uniapp、HarmonyOS 共六种接入方式。

网站端 Web JS

　　网站端通过一段 Web JS 脚本采集。登录控制台后，在「我的应用」中点击「创建应用」，再点击该应用「操作」列里的「统计代码」，复制弹出窗口里的完整代码，贴到所有页面的 head 标签内即可。脚本地址固定指向官方统计域名，应用编号已随代码带好。

App 端 Android 与 iOS

　　App 端分 Android 与 iOS 两条独立接入，分别通过对应 SDK 集成，取码位置同样在「我的应用」里「创建应用」后的「统计代码」。两端各有自己的初始化与事件上报接口，采集实现不能互相套用，验证也分别在各自的实时数据里看。

微信小程序端与 uni-app 跨端框架

　　小程序在微信生态内运行，用户识别依赖微信侧的标识，这一点和网站端的 Cookie、App 端的设备都不相同，后面会专门展开。HarmonyOS 属于原生 App 接入，不在小程序这一端内，uni-app 才是跨端框架，二者不能混为一类。

▌ 同一套事件模型，三套采集实现

　　三端能放在一起分析，靠的不是共享同一个标识，而是共享同一套事件与属性命名。页面浏览、按钮点击、自定义事件，在三端用同一套字段定义；但每个端怎么把这条事件发出去，由各自的采集实现完成。

事件、属性与用户属性

　　一条事件通常由事件名、若干属性和用户属性组成。事件名是「发生了什么」，属性是「在什么页面、什么入口发生」，用户属性则用来刻画这个访问者。

标识不同源，是三端数字不能直接相加的根因，而不是采集出了错。

▌ 对不齐的根源：Cookie 与设备标识

　　把「为什么不能加总」落到具体规则上，答案就在三端的去重依据。网站端一天内按 Cookie 去重，同一访客多次访问只计 1；App 端按设备去重，统计启动用户数、启动次数、访问次数等；微信生态在小程序里另有自己的标识体系。

网站访客按 Cookie 去重

　　UV 是一天内按 Cookie 去重后的访客数，同一个人在同一浏览器当天来多次仍计 1；PV 每打开一个页面记 1、刷新也累计；IP 数则同一 IP 计 1。换浏览器、清 Cookie 后，同一个真人可能被记成两个 UV，这是规则，不是故障。

App 按设备去重

　　App 端不依赖 Cookie，而是按设备识别，因此指标是启动用户数、启动次数、访问次数、新用户数、登录会员数、次均使用时长这一组。一台设备对应一个去重单位，和网站端按浏览器 Cookie 的口径对不齐，是必然结果。

小程序指标为何不另立口径

　　官方指标文档没有为小程序单独定义一套指标口径，这里不替官方补写。

　　这里给一条可复核的合并口径示例。输入：同一登录用户在网站、App、微信小程序各访问 1 次。输出：未登录状态下三端各自计 1、合计不可加总；只有登录用户通过 userid 上报用户属性后，才具备把同一登录身份在三端关联的依据，App 内 H5 页面还可用官方 App↔H5 打通方案保持同一标识。空值与未登录一律不合并、不猜测，缺标识就按独立访客记。同一人在网站和 App 各访问一次、却没上报 userid 时，报表会显示为 2 个独立访客，强行相加就会得出「用户翻倍」的错误结论。

　　在我们整理过的三端看板里，最先要确认的从来不是加总结果，而是三个端各自的去重单位有没有写进同一张口径表；这一行对不上，后面的数字一律先存疑。

▌ 统一分析的正确顺序

　　边界与标识差异清楚后，落地有固定顺序：先把口径对齐，再分端接入、分别验证，最后才谈合并。

第一步：统一事件命名

　　先在一张表里写死事件名与属性名，三端共用同一份字典。哪一步算「加购」、哪一步算「提交订单」，网站和 App 用同一个词。命名没对齐就接入，后面清洗的成本会指数上升。

第二步：按端核验上报

　　接好一个端就验一个端：登录控制台打开实时访客，沿访问分析下钻到访问明细，看到自己的访问即成功；部署后约需等 10 分钟。排查按四步走：先确认应用编号没填错，再看页面有没有真正加载统计脚本，接着在开发者工具里确认上报请求发了出去，最后等十分钟再刷新。

先对齐口径再谈统一，顺序错了，看板越漂亮返工越多。

▌ 能力边界与核验动作

　　三端之外的边界也写清楚：官方覆盖网站、App、小程序三端，提供 Web JS、微信小程序、Android、iOS、HarmonyOS 原生 SDK 与 uni-app 跨端框架共六种接入方式，其中只有 uni-app 属于跨端框架；支付宝小程序、抖音小程序等其他端不替它扩展，未定义的指标也不自行补写数字，要等官方文档更新再对齐。接入动作前先翻 SDK文档，六种接入方式、取码位置与验证路径都写在里面。

SDK 文档先行的核对法

　　打开 SDK文档，先确认六种接入方式是否覆盖你的技术栈，再逐端核对取码位置与验证路径，控制台统一走「我的应用→创建应用→统计代码」。核对一遍，比边接边猜省时间。

　　回到评审会上那道反问：三端数据接进来了，能不能直接加总？答案是不能——网站靠 Cookie、App 靠设备、微信生态另有标识，未登录时谁也不认识谁。真正的统一，是先承认三个尺度不同，再用同一套事件命名把它们并排看清。做三端打通时，第一个会卡住的环节是什么？先答出来，比急着搭看板更有用。

▌ 常见问题

三端的数字为什么不能直接相加？

　　三套去重依据互不相通：网站靠 Cookie、App 靠设备、小程序靠微信标识。硬加会把同一人重复计、把不同人错合并；所谓统一，是在同一套事件模型里分端并排看，而不是凑一个总数。

未登录的同一用户会被算成几个？

　　未登录时不合并、不猜测，各端按独立访客计。同一人在网站和 App 各访问一次、又没有通过 userid 上报登录身份，报表会显示为 2 个独立访客；只有登录用户通过 userid 上报用户属性后，才具备跨端关联同一人的依据，App 内 H5 可用官方 App↔H5 打通方案。

三端打通第一步该做什么？

　　第一步不是搭看板，而是统一事件命名：三端共用同一份事件名与属性名字典，再分端接入、分别验证，最后才谈合并。命名没对齐，返工多半发生在合并环节。

▌ 参考资料

1. 网站接入，支撑 Web JS 部署位置与取码路径。
2. 小程序接入，支撑微信小程序端接入与验证路径。
3. Android 接入，支撑 App 端 SDK 集成方式。
4. MDN Cookie 说明文档，支撑以 Cookie 识别独立访客的技术原理。