自建数据栈,还是接三个 SDK 了事?
每个小游戏团队都在第一个下午装好一个分析 SDK。几乎没人真正拥有自己的数据。SDK 看"装了多少"没问题,但当你想知道"哪一群玩家的 D7 留存掉了、为什么"时,你就在查三个互不认同的仪表盘,跨一套你从没设计过的事件 schema。这选择不是自建 vs 购买,而是你继续租借自己的问题,还是拥有它们。下面是匆忙中常被跳过的一环。
Q:为什么三个 SDK 加起来不等于一个数据栈?
因为每个 SDK 都持有自己的 schema、自己的身份缝合、自己对"会话"的定义,而且没有一个会在没有你的情况下互相说话。你的归因 SDK 说 1200 个安装来自渠道 A;你的产品 SDK 说 900 个会话;你的广告 SDK 说 1400 次转化。它们没错——它们数的是带不同时钟的不同宇宙。没有统一的事件 schema 和一个能跨三者存活的稳定 user ID,你无法 join 它们,也无法回答唯一重要的问题:哪个渠道的用户真的付费。租三个工具意味着你只能问每个工具天生会回答的问题,而那从来不是你真正的问题。
Q:如果要自建,第一步不是写 ETL,是什么?
在写一行管道之前先设计事件 schema。数仓只是个数据库;难点在于决定一个"purchase"事件包含什么、稳定的 user_id 是什么、你怎么命名才能让六个月后"level_complete"仍指同一件事。跳过这步的团队,最后会有二十个稍微不同的"buy"事件和一个离职的数据科学家。第二步是单一摄取点——一个 SDK 把所有东西发到你的数仓,然后你再决定转发什么给广告网络。拥有原始事件;租用下游工具。这个顺序让你以后能问新问题,而不是去求供应商出报告。
Q:PII 和合规,怎么从第一天就别踩坑?
把玩家 ID 和玩家的账单国家当成放射性物质,从 commit 第一天起就如此。便宜的错误是"以防万一"把所有东西都记下来,这会让你的数仓一装满就变成 GDPR/CCPA 负债。纪律是:收集一个稳定的匿名 ID,把 PII(邮箱、支付)只推给处理器,并保存一张数据地图说清哪张表装了什么、保留多久。删除路径比收集路径更重要——如果你无法证明能擦掉一个用户,你在欧盟就留不住他。这是唯一一个"以后再修"等于埋罚款的地方。
Q:到底怎么判断自建还是购买?
用所有权测试。如果你的问题是标准的——安装、留存、崩溃率——三个 SDK 就行,该发就发。一旦你的竞争优势依赖一个只有你能问的问题——"看了教学广告的巴西玩家是不是流失更慢?"——你就得把那个事件放进自己的数仓。有效的混合是:拥有原始事件流和 user_id,把可视化和归因 API 租在它上面。下面这张表是多数团队画得太晚的那条线。
| 如果你需要…… | 做法 | 为什么 | 代价 |
|---|---|---|---|
| 只要标准指标 | 2–3 个 SDK | 快、无管道 | 跨工具的问题问不了 |
| 只有你能问的问题 | 拥有事件数仓 | 你留住了问题 | ETL + schema 维护 |
| 混合 | 拥有原始、租用可视化 | 两全 | 集成纪律 |
| 有欧盟/加州玩家 | 第一天就最小化 PII | 合规不是可选项 | 在记日志上克制 |
你的数据要么是你拥有的资产,要么是你续费的租约。租约感觉更便宜,直到你需要的那个问题不在套餐里。
