Zovda
监听看板回答「这周发生了什么」，回答得很好；回答「下一步该做什么」，回答得很差。两个问题起步成本差不多，但从第二季度开始越走越远。
这不是选哪个产品更好的问题，而是：看板把记录呈现给你之后，你打算拿这些记录做什么。
工具优化的是「在工具里做决定」
监听类产品优化的是工具内部的决定：提醒、情绪图、声量面板、保存的搜索。记录被呈现，但很少被取走，也几乎不稳定到能与自己的数仓对接。
对每周回答几个问题的市场团队，这非常合适；对「明年要换个口径重算」的需求，完全不合适。
数据接口优化的是记录本身
接口优化的是记录：字段一致、schema 可版本化、量按自己的节奏取、结果落在自己的存储里，而不是别人的看板里。
代价也很直白：你拿到自由，也接过工作——建模、存储、去重，以及原本看板替你做的分析层。
三个问题决定方向
- 你要的是原始记录，还是别人从记录里得出的结论？
- 同一批数据要喂给不止一个产品或团队吗？
- 以后需要按新口径把历史重算一遍吗？
两个以上「是」，指向接口；一个都没有，指向工具，而买工具是更便宜的决定。
多数团队最后两个都要
工具负责每周的读，接口负责作为事实底座的那份记录。真正的失败模式是：看板变成了数据唯一存在的地方——那一刻，供应商的界面就是你的数据库。
交付前我们跑的清单
- 记录能不靠手工导出就离开这个产品？
- schema 写得足够清楚，可以对着它做版本管理？
- 口径一变，历史记录还能重新拉取？
- 产出落在你自己控制的存储里？
- 两个团队拿到的是同一套字段，还是两套不同的视图？
答不上这些，你买的是一个带导出按钮的看板，而不是「拥有这份数据」。
从哪里开始
如果答案指向记录，先从下游真正需要的字段开始，而不是从量开始。社媒数据接口说明了接入方式，统一 Schema 那篇讲了同一套字段如何在差异极大的内容类型之间保持一致。
Zovda 做的是数据接口，不是监听工具：Datuva 上的语料按版本寻址，而不是按一个日期选择器。
告诉我们你打算在上面建什么、需要多少量，我们会在 1 个工作日内回复；范围确认后提供字段说明。