个人与匿名访问
登录用户使用随机的 analytics_person_id。匿名访问使用短期 ID，登录和退出时按用途管理关联。
PRIVATE ANALYTICS BLUEPRINT / 01
TikHub 用户行为
数据体系
面向 TikHub API 升级接入新 Platform：用真实接口、账户审计、结算记录与运营流程，说明分析数据如何形成。
打开行为分析后台演示代码依据：TikHub-Platform e2ea1b8a / TikHub_API 80132ea8 · 2026-11-09。API 只提供专属接口与请求事实；账户、组织、授权、资金和运营采用新 Platform 模型。分析旁路及 API 新平台接入尚待建设与联调，页面样本全部合成。
DESIGN PRINCIPLES01 / 数据自控02 / 事件有来源03 / 身份有边界04 / 运营可衡量
01 / DATA FLOW
从行为发生，到业务行动
选择场景高亮完整路径；点击任意节点，查看数据内容和边界。
ARCHITECTURE →
系统数据流 / 架构提案
当前数据流其他路径
01 / 行为与业务来源
02 / TIKHUB 自有数据层
03 / 分析与决策
04 / 员工操作与反馈
运营效果反馈↶现有邮件投递 → 拟建第一方点击与业务转化采集 → 统一事件接入 → 效果分析
统一事件接入
采集前字段白名单、用途控制、身份确认
传输与存储TLS、访问控制、队列重试与数据删除
使用时员工权限、查询审计、营销退订
业务场景模拟
| 步骤 / 时间 | 事件或处理 | 模拟数据与结果 | 流向 |
|---|
示例用于解释目标设计；真实名称取自代码，API 新平台接入与分析投影仍待建设。高亮行跟随上方播放步骤变化。
02 / EVENT CATALOG
TikHub 应该采集什么？
以业务问题为中心定义事件，先覆盖关键节点；现有审计、业务记录与建议新增事件分别标识。
EVENTS →
| EVENT / 事件 | 采集时机 | 来源 | 用于回答 |
|---|
03 / IDENTITY MODEL
一个用户，多种业务身份
同时表达个人、组织、成员和服务身份，保留事件发生时的真实上下文。
IDENTITY →
组织与成员关系
组织拥有独立分析 ID。记录操作人和成员关系；切换组织不会改写历史事件。
服务身份
服务 Key 和自动任务标记为 service 或 system，不会被误认为自然人。
App 与事件来源
每个事件标明可信来源和所属 App，关键事实由拥有该事实的服务上报。
卖家 pairwise 隔离
沿用按卖家隔离的 sub；不向卖家暴露跨卖家身份映射或其他卖家的行为。
用途、权限与删除
映射表单独保护；查看与导出需授权和审计，注销或适用撤回时按策略处理数据。
04 / SYNTHETIC POC · 2026.11.09
三轮 PoC：验证数据与权限边界
全部使用隔离环境与合成数据。第三轮补测事件导出、队列重放、完整冷备恢复与外联；点击卡片查看范围。
TEST RESULTS →
共享项目可查询并导出其他卖家的事件
虚构卖家 A 只有项目 read 权限，仍可查询 B 的事件，并创建读取客户端后导出 B 的记录。针对另一个无授权项目的事件查询返回 403。
查看验证与设计影响
读取客户端创建、导出及撤销均返回 200。测试凭据已撤销；账号角色由合成数据库引导，不是原生卖家角色。共享链接、缓存和全部 API 尚未覆盖。卖家数据查询、字段投影与导出必须经过 TikHub 服务端鉴权，不能直接开放共享分析项目。
事件归属 ≠ 当前成员关系
Alpha 有 3 个历史事件主体，显式分配后的成员列表是 2 人。Bob 重新分配到 Beta 后，旧 Alpha 分组仍保留。
查看验证与设计影响
这是第二轮观察：事件标签和画像成员是两套口径。TikHub 需维护可撤销、带生效时间的权威成员关系，并保留事件发生时的组织上下文。分析分组不能作为授权来源。
待处理的旧事件会重新写回
暂停 Worker 后将旧合成事件送入队列，删除对应数据库行，再恢复 Worker：事件从 0 条变回 1 条。
查看验证与设计影响
这次由实际 Redis 队列与 Worker 重放，区别于第二轮手工重新发送。直接删除了 ClickHouse 事件和画像，没有安装持久删除标记；不是原生完整删除流程验收。接入、队列消费和恢复后都应检查独立删除登记。
从新目录与新数据卷重新启动
备份包含 PostgreSQL、ClickHouse、Redis 三个完整数据卷及 Compose、环境和数据库配置。恢复后 269 条事件、10 条画像原始行、2 条分组记录一致，产品导出 API 返回 200。
查看验证与设计影响
校验 10 个备份文件后，在新目录和全新卷中启动；复用本机已固定摘要的镜像。备份包约 58.1 MiB，解包后从写卷到服务健康约 18.66 秒，仅为本机小样本。备份后已在源库删除的哨兵事件与画像恢复成 1 / 1，必须重新执行删除策略。未覆盖远程灾备、镜像重下载、加密密钥恢复及生产 RPO/RTO；本地测试包未加密且没有公开上传。
CSP 拦截厂商上报与第三方脚本
浏览器报告拦截 api.openpanel.dev/track 和 cdn.userjot.com/sdk/v2/uj.js。API、Dashboard、Worker 的 DNS、IPv4 / IPv6 TCP 与空 HEAD 出站点探测均未成功。
查看验证与设计影响
覆盖项目、概览、事件、画像与 Groups 页面；共收到 6 条 CSP 报告、2 个目标。容器 internal 网络未开启 IPv6，IPv6 结果不能说明双栈部署安全。CSP 报告不是完整抓包；仍需移除外部组件，验证所有页面、故障和升级路径。测试 CSP 不作为生产模板。
从事件到用户、运营与风险视图
依据两个项目代码重建总览、5 条动态业务流、账户身份、真实群发口径、审计风险和事件依据。模拟抖音接口的 200 / 402 / 429 / 500，观察指标变化。
查看演示范围
纯前端合成数据，尚未接入 OpenPanel 或 TikHub 后端；不发送通知、不执行风控处置。刷新重置数据。展示的是员工后台，不代表卖家授权、持久存储或生产分析能力已实现。
| 对照项目 | OpenPanel 2.x | Umami 3.4.1 |
|---|---|---|
| 初轮合成事件 | 22 条成功接收；重发会重复 | 22 条成功接收；重发会重复 |
| 产品能力 | 画像、组织与事件界面已验证 | 三步激活漏斗为 4 → 3 → 2 人 |
| 第二轮轻量负载 | 240 条全部入库；约 20 条/秒的短时测试 | 未做同条件负载测试 |
| 资源观察 | 第二轮负载 2.45–2.47 GiB；第三轮恢复后约 1.58 GiB | 第一轮单次快照约 271 MiB |
| 第三轮完整冷备 | 三个完整卷 + 配置恢复；产品 API 可读 | 本轮未补测恢复 |
恢复后的 3 次快照仅为短时页面操作后观察，CPU 合计约 5.31–12.90%；不含宿主与 Docker VM。不同轮次与条件不可直接作为性能排名。完整冷备恢复已在本机验证，生产灾备、完整删除、全面权限与完整出站审计仍未验收。PostHog 仍只作功能参考，未部署实测。
05 / DELIVERY PLAN
从验证到可用的四步
先验证产品和数据边界，再逐步建设 TikHub 专属能力。
ROADMAP →
隔离 PoC
合成数据测试 OpenPanel 与 Umami，检查功能、身份适配、外联及资源。
统一事件与身份
建设事件规范、接入、脱敏、身份映射和可靠投递，不进入资金热路径。
分析与运营闭环
展示核心漏斗，连接现有员工权限、站内活动、邮件订阅与退订。
风险与上线验证
补齐规则告警、人工复核、备份恢复、删除和权限审计后评估上线。
当前进度：三轮合成 PoC 已验证完整冷备恢复并复现权限与删除缺口；后台 MVP 已可演示。建议继续以 OpenPanel 做员工分析候选，由 TikHub 自建身份、卖家鉴权和删除登记。上线前仍需全面外联审计、生产灾备与负载验收。