建模指南
语义建模是 Tukun.ai 把重复出现的业务语言转成共享分析含义的方式。
建模的目标不是在一开始就搭一整套大而全的分类体系，而是消除那些会反复出现的歧义。
建模能帮助团队：
- 明确一个指标到底是什么意思
- 标准化常见排除项和过滤条件
- 减少在 Workbench 里重复解释
- 让卡片和仪表板长期更稳定
从已经反复出现的问题开始
Section titled “从已经反复出现的问题开始”最好的早期建模对象不是理论上“看起来重要”的概念，而是那些已经在实际问题里反复出现的定义。
典型的早期候选包括：
- 收入
- 每周活跃账户
- 转化率
- 留存
- 流失
- 毛利
每个指标至少要写清什么
Section titled “每个指标至少要写清什么”对每个重要指标，至少要说明：
- 它在业务上意味着什么
- 它依赖哪些源表
- 它应该支持什么粒度
- 哪些排除规则总是成立
- 谁是这个定义的负责人
如果一个指标没法用一小段话说清楚，那它大概率还没准备好成为共享事实。
维度应该减少混乱，而不是制造混乱
Section titled “维度应该减少混乱，而不是制造混乱”优先使用业务已经清楚理解的维度，例如：
- 套餐
- 区域
- 渠道
- 客户分群
- 注册月份
不要轻易引入多个含义高度重叠的近似维度，除非这种区分确实关键且已经被文档化。
一种实用的顺序是：
- 先定义一个大家每周都在看的指标
- 给它补最常一起使用的一两个维度
- 固化那些用户总在手写的排除规则
- 在 Workbench 里验证结果
- 再把稳定结果沉淀成卡片和仪表板
好的建模纪律
Section titled “好的建模纪律”- 使用统一命名
- 定义要短、明确
- 每个定义都应有负责人
- 当业务逻辑变化时及时更新模型
- 当定义变更后，回头检查依赖它的仪表板
建模不应该变成什么
Section titled “建模不应该变成什么”不要把语义建模当成：
- 所有字段的垃圾堆
- 数据源清理不干净时的替代品
- 掩盖业务分歧的方式
只有当团队真的愿意采用这套共享定义时，建模才会带来一致性提升。