GEO-117·第 10 期·技术底座·117 / 132
日志、API 与数据仓库：GEO 数据管线
GEO 的数据散在日志、搜索后台、AI 抽样、订单与 PIM 里，颗粒度各不相同，直接 join 会放大也会丢记录。本文给出数据源清单、三层实体 ID、四层管线与刷新频率，附五步落地清单和一条示例记录，说明为什么先统一 ID 再谈看板。
本期主线可度量：AI 可见度、归因与实验
示例：十月的双周会，一家做智能门锁的出海团队放了四张表。技术说检索类爬虫对商品页的请求在掉；运营的 AI 监测说品牌提及率涨了一截；财务说 AI 渠道只有零星几单；客服说有人拿 AI 截图来问“支不支持 2.4GHz、2 英寸的门能不能装”。四张表都没算错，只是同一个型号有三个名字。
GEO 的数据问题不是缺看板，而是缺一条以实体 ID 为主键的管线：源、键、刷新频率定不下来，看板只会把四种颗粒度混成一个看起来很精确的错数。
四张表都没错，错在直接相加
日志是请求级，抽样是样本级，订单是交易级，三者相加不成立。 先定“一行代表什么”，才有资格谈 join。
日志一行是一次请求，回答谁抓了、抓哪页、什么状态码。搜索后台一行是“一页 × 一个查询”。AI 抽样一行是一次提问的一次回答，同一句问三遍可能三个答案。订单与工单一行是一笔交易或一次求助。
颗粒度不对齐，后果很具体。请求级 join 订单级，一次热门页的上百次抓取会把一张订单复制成上百行；样本级 join 交易级，二十次提问对一张订单，算出的转化率没有分母意义。两类错误都不报错，只安静产生一个漂亮的数。
| 数据源 | 回答什么 | 一行是什么 | 刷新 | 常见坑 |
|---|---|---|---|---|
| 日志 / CDN | 爬虫来没来、抓了哪页 | 一次请求 | 日更，留三个月 | 导出被采样，保留期短 |
| 搜索与广告后台 | 品牌词有没有被搜 | 一页 × 一查询 | 周更 | 归因窗口算进 Direct |
| AI 答案抽样 | 提及、引用、推荐位 | 一次回答 | 周更，每题三次 | 不记样本量，涨幅难解释 |
| 订单 / CRM / 工单 | 谁买了、退了什么 | 一笔交易 | 日更，按月结算 | 渠道字段是自由文本 |
| PIM / feed | 各出口径是否一致 | 一个 SKU | 变更即同步 | feed 常落后于页面 |
这张表最大的用处，是逼你承认缺哪个源：商品主数据常在品类运营的表格里，日志常常只有 CDN 抽样导出。缺源不可怕，假装有才可怕。
先统一实体 ID，join 才有分母
三层键必须先定：商品是 SKU，页面是 canonical URL，品牌是实体 ID。 三层混用，是 GEO 数据最常见的错。
商品层用 SKU 加变体 ID，必要时带 GTIN；页面层用去参数的 canonical URL 加 locale；品牌层用实体 ID 配 sameAs。三层寿命不同：SKU 随换代消失，URL 因改 slug 失效，品牌实体长期在。拿页面当主键统计可见度，改一次 slug 就断一条历史。
一对多要显式处理：一个 SKU 五个语言站就是五条 URL，一个页面挂三个颜色就是三个 SKU。经销商页、白标页、比价页看着像你，只能进品牌层的第三方分支。
ID map 必须带生效时间，否则上月报告重跑，数字会跟着今天的映射变。还要盯未匹配率：日志里对不上 SKU 的请求占比越高，按 SKU 的可见度就越偏。
| 层 | 主键 | 关联数据 | 一对多怎么办 |
|---|---|---|---|
| 商品 | SKU + 变体 ID（+ GTIN） | feed、订单、库存、评价 | 组合装拆父子项，别共用同一个键 |
| 页面 | canonical URL + locale | 日志、搜索后台、AI 引用来源 | 多语言多 URL 用 locale 字段，不建多张表 |
| 品牌 | 实体 ID + sameAs | 站外语料、知识图谱、媒体 | 经销与白标页标为非官方，不并入商品层 |
刷新频率按用途定，不按“实时”定
抓取日更、答案周更、订单月结、主数据变更触发，四档够用。 越实时越贵，还会把噪声当信号。
抓取健康日更，403 与 robots 变更要当天处理。答案抽样周更，跟内容迭代对齐；它是抽样，日更只会把波动放大成趋势。订单日更入库、按月结算，退款与支付回调会改历史。主数据变更触发，SKU 一改就同步。
管线分四层，各有各的失败方式。
| 层 | 做什么 | 出错的样子 |
|---|---|---|
| 采集 | 日志导出、接口拉取、抽样入库 | 漏一天，周报曲线断一截，没人发现 |
| 归一 | 统一 UTC 日、币种、UA 分类、URL 去参数 | 带 utm 的同一页被算成二十个页面 |
| 关联 | 套 ID map，未匹配记录单独留存 | 未匹配被静默丢弃，指标反而更好看 |
| 服务 | 宽表、口径文档、权限 | 三个人写三份 SQL，出来三个“提及率” |
一条硬规则：未匹配的记录不能丢，要单独落表。 它既是质量指标，也是发现新品与新渠道的线索。丢掉的记录不会消失，只会在下次汇报时以“数据对不上”的形式回来。
五步落地：从三个问题反推管线
先问本季度要回答哪三个问题，再倒推接哪些源。 接得越多不等于越准，只会越难维护。
| 步骤 | 做什么 | 谁来做 | 怎么算过 |
|---|---|---|---|
| 1 定问题 | 抓取有没有掉、答案里排第几、带来多少订单 | 增长负责人 | 每个源都能指到一个决策，指不到的先不接 |
| 2 建 ID map | SKU、GTIN、ASIN、canonical URL、locale，加生效时间 | 技术 + 品类运营 | 抽二十条订单与二十条日志，能匹配到唯一 SKU |
| 3 定口径 | 每个指标写清分子分母、时间窗、样本量、去重 | 增长 + 财务 | 两人按同一份文档各算一遍，结果一致 |
| 4 搭最小管线 | 日更日志、周更抽样、月度订单，宽表落仓，不碰实时 | 数据工程 | 连续四周无断点，未匹配率上到看板 |
| 5 接周报 | 一张周报三个数，加一列“数据可信度” | 增长 | 会上不再出现同一指标的两个版本 |
第 3 步最容易被跳过。口径写不清，管线再稳也只是把争论从“数是多少”推到“你那个数怎么算的”。每层的判定证据与分母，可以借用AI 可见度的四层指标当骨架。
示例：一条记录走完管线
以下品牌、路径与数字均为示例，只演示字段如何对上。
一对智能门锁（型号与参数虚构）在 10 月 8 日 02:14（UTC）被抓取，状态码 200。归一后得到去参数的 canonical URL，在 ID map 里对应哑黑与拉丝银两个变体——一个页面两个 SKU。
10 月 9 日的抽样里，同一问题重复五次：三次提到品牌，一次给出可点击的来源，零次进推荐位。样本量、模型版本、地区节点都写进表，下周换节点才可比。
10 月 12 日进来一张订单，渠道写着“chatgpt referral”，归一后归到 AI 引荐；两周后退货，原因“App 配对失败”。这条退货同时是内容线索：配对步骤在页面上太靠后。
三行记录对上同一个 SKU、同一个 URL、一个时间窗，这就是管线的用处；此前它们分属四张表、三个名字。
边界：什么时候别建这条管线
第一，流量太小。 一周只有几十条日志命中，周更结论都由噪声主导，先做抓取健康与月度人工核查。
第二，拿不到原始数据。 平台内卖家与部分 SaaS 建站只能读后台报表，管线退化成“抽样 + 订单”两源，仍然有用，但不能自称有取证能力。
第三，归因有天花板。 AI 引荐在复制粘贴、跨设备、暗社交里大量不可见，管线只能给下限。指标要写“可识别的 AI 引荐”，不要写“AI 带来的全部订单”。
第四，供应商是黑盒。 采样方法、模型版本、节点不透明，跨月不可比。合同要写清原始数据能否导出，否则存的只是别人的结论。
口径之外还有一层一致性问题：各源叙事冲突时，join 得再准也只是把矛盾拼得更完整，见品牌叙事一致性检查。这条线归技术底座，它解决“能不能算”，不解决“该不该做”。
这个月先做一件事：从日志、订单和最近一次 AI 抽样里各抽二十行，手工对齐到同一张 ID map。对不上的那一列，就是你的管线起点。