06 · 渠道按时区统计¶
目标读者：副组长（重度使用）、推广 核心问题：同一个渠道在不同时区流量差异多大？下一波 Firebase 推送该落在几点？ 资料来源：非凡包网后台产品说明文档 最后更新：2026-04-11
一、功能概述¶
渠道按时区统计是副组长日常最常用的推广报表。它的核心价值在于：
- 把 04 的渠道数据按 GMT 时区切片
- 对副组长来说，这直接回答"几点发推送最合适"
为什么需要时区切片？
非凡包网主打印尼（UTC+7），但不同渠道的流量实际上来自不同地区：
| 渠道类型 | 主要来源时区 |
|---|---|
| 印尼本地 TikTok | GMT+7（雅加达） |
| 东部印尼 / 巴厘 | GMT+8 |
| 东亚代理分享 | GMT+8（吉隆坡 / 新加坡 / 港台） |
| 中东华人 | GMT+3、GMT+4 |
| 东欧 | GMT+0、GMT+1 |
发推送要按该渠道主要时区的活跃时段来定，而不是简单按印尼晚高峰。
二、入口¶
后台 → 推广渠道 → 渠道按时区统计
三、筛选字段（基于截图）¶
| 字段 | 截图实例 | 说明 |
|---|---|---|
| 时区 | GMT+07:00（下拉含 GMT+00:00 / GMT+01:00 等） | 按 GMT（格林尼治时间） 筛选渠道 |
| 推广商 | FB | 来自 03-渠道配置 |
| 推广渠道 | H5-FB-api | 来自 03-渠道配置 |
| 日期 | 2025-11-02 ~ 2025-11-02 | 按推广日期筛选 |
| 查询实时数据 | 绿色按钮 | 应用筛选 |
推广商下拉（截图实例：FB / Tiktok / Kwai / FB-TEST / APK）：
推广渠道下拉：
列表表头列（截图可见、含排序箭头）：渠道、注册人数、首充人数、注册充值比、首充金额、充值人数、充值次数、充值金额、提现人数、提现次数、提现金额、提现手续费 ……（与 04 表头基本一致，按时区切分维度独立）
四、典型使用流程¶
4.1 找出某渠道的主力时区¶
1) 选定渠道，例如 TT_Push_ID
│
▼
2) 展开时区切片
│
▼
3) 看哪个 GMT 段的注册 / 首存 / 存款最大
│
▼
4) 该时区 = 此渠道的主力时区
4.2 定推送时间¶
找到主力时区后，副组长日常 5 次推送的节奏可以这样排：
| 推送 | 本地时间（主力时区） | 印尼时间（GMT+7）例 |
|---|---|---|
| 早醒推送 | 07:00 | 07:00 |
| 午饭推送 | 12:00 | 12:00 |
| 下班推送 | 18:00 | 18:00 |
| 晚高峰 | 20:00 | 20:00 |
| 深夜召回 | 23:00 | 23:00 |
如果渠道主力在 GMT+8（比印尼晚 1 小时），那印尼时间所有推送要 延后 1 小时才能命中用户本地晚高峰。
4.3 对照 Firebase / JPush 发推送¶
见 02-技术体系/16-firebase，在推送任务里按目标时区分组发送。
五、副组长视角¶
5.1 避免"一刀切全量推送"¶
新手副组长常犯的错：不看时区，按印尼 20:00 全量推送。结果： - 东亚渠道的用户在 21:00 才到晚高峰 → 推送错过 - 中东渠道的用户还在中午上班 → 推送被误删
正确做法：先看 06 报表 → 再定推送时点 → 分时区发送。
5.2 推送打开率 / 点击率反向验证¶
发完推送后： - 回来看 04-推广统计报表 对应渠道的增量 - 配合 Firebase 的打开率数据 - 反向调整下次的时区定位
5.3 值班交接关键点¶
交接时，写清楚每个渠道今天的主力时区，避免下一班不看数据盲推。
六、注意事项¶
6.1 时区是"用户本地"不是"服务器"¶
报表里的时区指用户所在时区（基于 IP 或手机系统时区），不是后台服务器时区。
6.2 节假日偏移¶
印尼斋月、东亚春节、中东斋月期间，活跃时段会整体后移 1–2 小时。06 报表会反映出来，但需要副组长主动去看。
6.3 夏令时¶
欧洲渠道每年 3 月和 10 月切换夏令时，同一个 GMT 标签背后是不同的本地时间。排推送前翻一下日历。
七、交叉引用¶
- 03-渠道配置
- 04-推广统计报表
- 05-推广效果评估
- 02-技术体系/16-firebase —— Firebase 按时区推送配置
- 副组长工作指南 —— 推送节奏日常