用一张 Visit 表还原渠道真实占比（口径与取数）
同一张 Visit 表、同一个时间窗，能算出三个「总量」：59,076 次访问、20,843 个独立 ipHash、26,661 个独立 visitorId，换算成 2.83 PV/ip 与 2.22 PV/访客。选哪个当分母，决定了后面每个百分比的含义。
一、这份数据是怎么算出来的
| 项 | 说明 |
|---|---|
| 数据源 | 生产库 Visit 表（SQLite，只读连接） |
| 快照时间 | 2026-11-07 06:0x（UTC+8） |
| 窗口 | 2026-10-08 ~ 2026-11-07 |
| 样本池 | 窗口内全部落库记录，59,076 条 |
| 关键字段 | path、refDomain、uaClass、utmSource、isMobile、ipHash、visitorId、site |
| 统计方式 | 分组计数，未加权、未抽样、未去重（PV 口径） |
| 落库方式 | 站点中间件写入，非第三方统计平台导出 |
取数动作很小：一条带时间窗的 SELECT 加几个 GROUP BY。决定结论的是取数前的三个选择：分母、空值、去重。
二、口径边界
59,076 不是人数。 它是 PV，含重复访问。要人数就换 ipHash（20,843）或 visitorId（26,661），换完不能写回 PV。
空 referrer 不是「直接输入网址」。 隐私策略、App 内置浏览器、书签、邮件客户端都会剥离 referrer；38,829 条、65.7% 里混着这几类，只能当「来源不可见」。
81 条 Google 不是「Google 无流量」。 搜索结果页与部分客户端会剥离 referrer，GSC 是另一套数据源，本次未取。
4,259 条带 UTM 的访问（7.2%）不能并入 refDomain。 两个字段各记一条链路，重叠部分会算两次。
三、主体数据
三个分母放在一起看（均值 2.83 PV/ip、2.22 PV/访客）：
| 口径 | 数值 | 能回答什么 | 不能回答什么 |
|---|---|---|---|
| PV | 59,076 | 打开次数 | 有多少人 |
独立 ipHash |
20,843 | 大致人数（按出口 IP） | 同一出口下的多人 |
visitorId |
26,661 | 大致访客标识数 | 同一人多设备 |
isMobile=1 |
4,986（8.4%） | 移动端占比 | 机型分布 |
渠道前 14（refDomain，PV 口径）：
| 来源 | PV | 占比 |
|---|---|---|
| 空 referrer（直访） | 38,829 | 65.7% |
| cn.bing.com | 15,532 | 26.3% |
| bing.com | 2,261 | 3.8% |
| quark.cn | 464 | 0.8% |
| linux.do | 456 | 0.8% |
| cloud.tencent.com | 299 | 0.5% |
| link.juejin.cn | 258 | 0.4% |
| link.csdn.net | 232 | 0.4% |
| doubao.com | 116 | 0.2% |
| google.com | 81 | 0.14% |
| mcp.dpharness.com | 59 | 0.1% |
| my.oschina.net | 57 | 0.1% |
| so.com | 50 | 0.08% |
| 114.114.114.114 | 47 | 0.08% |
四、数据本身说明的四件事
规则一：报数先锁分母，锁完不许换
59,076、20,843、26,661 都能当分母，得出的百分比不是同一个东西。一句话里只留一个分母，并写进括号：「Bing 系 17,796 条，占 59,076 次访问的 30.1%」。换了分母等于换了一套统计。
规则二：空 referrer 单列一行，不摊派
38,829 条、65.7% 是最大的一块。按比例摊回各渠道会凭空造出「Google 其实不少」的结论；正确做法是留作独立一行，标注来源不可见。这也是 refDomain 各行占比加不到 100% 的原因。
规则三：UTM 与 referrer 分开记
带 UTM 的 4,259 条占 7.2%，其余 54,817 条没有参数。utmSource 里 txyun 1,406、csdn 1,135，而同一家平台在 refDomain 里可能只有 299 条（cloud.tencent.com）。一个记落地参数，一个记浏览器来源，硬加会数两遍。
规则四：异常 UA 先扣，再算占比
forged_browser 1,677 条占 2.8%，判定为伪装浏览器的请求；落点 /plugins 473、/category/chat 235。它集中在列表页，会把「列表页表现好」抬高。取数时先用 WHERE uaClass != 'forged_browser' 过一遍。
五、局限
- 30 天窗口，看不到季节性与活动长尾。
- 单站单库，没有第二数据源交叉验证。
- 未取 GSC，Google 一侧只有 81 条。
ipHash与visitorId是近似去重，多设备与共享出口会失真。path未规范化，带参数与不带参数算两条。
六、数据复核
精选榜单页 对应 9,151 条，插件列表页 对应 4,168，安装教程页 对应 1,699。逐列确认 Visit.path、Visit.refDomain、Visit.uaClass、Visit.utmSource 是否有值，空值率往往就是口径问题的来源。
七、适合与不适合
适合：要交流量报表、担心被追问口径的人；两套后台数字对不上的人。
不适合：要行业基准的人，这里只有一个站点；要做归因建模的人，7.2% 的覆盖率不够。
标签：数据口径、PV/UV、referrer、UTM、站点分析
本文由 DeepSeek Harness Hub 自动整理，数据来源于站点 2026-11-07 快照。
