这里每一项都已经为面板收集好了。API 不是另一个带着另一批数据的产品，只是同一批读取的另一种接收方式。
每次读取时每个规格的件数。网店公开确切件数的，你拿到确切件数。只公开“有货”或“仅剩几件”的，你拿到的就是这个，外加一句明白话：那不是计数。
从库存下降算出的件数，以及按当天价格计的营收。按天，并按规格、商品和网店拆分。
每次读取时每个规格的价格，网店标出原价的还带上原价。是完整的变动历史，不只是今天的数字。
商品和规格，带名称、尺码或颜色、页面网址和网店自己的编号。你能看到目录里新增了什么、又少了什么。
卖光、补货、降价、商品下架。就是面板画在时间轴上的那些。这是唯一值得用 webhook 接的数据集，因为要紧的是你在哪一分钟知道。
网店在 Meta、Google 和 TikTok 上的活动和素材：什么在投、从什么时候起、说了什么。
网店在搜索里排得上的词，以及排在第几。另有评价、网店用的技术，以及它的社交账号。
有些连锁会分门店公开库存。对这些连锁，你除了总数，还能拿到按门店的拆分。
* 按门店拆分只对公开这类数据的连锁存在，而广告数据的多少在 Meta、Google 和 TikTok 之间并不相同。报价时我们会直接说明，对你的这些网店什么做得到、什么做不到。
数据要落进一个已经存在的系统，或者网店多到没人能一家一家看的时候，通常就该用 API 了。
在 Looker Studio、Power BI 或 Metabase 里，把竞争对手的库存和销量放在你自己的数字旁边。你在一个地方与市场对比，而不是并排开两个窗口。
竞争对手每个规格的价格，每两小时刷新一次，作为你自己规则的输入。旁边带着库存，因为发不出货的东西，它的价格算不上竞争。
webhook 直达 Slack、n8n 或 Make，不用循环轮询我们。竞争对手的爆款断货，是当天就该加投广告的理由，而不是周一报告里的一行。
库存和价格的历史，是需求模型现成的输入。智能体要用具体数字回答市场问题，需要的也是这一批数据。
对一个品牌或整个品类的销量估算，用同一套方法同时覆盖很多家网店。基金和顾问拿到的是一次测量，而不是卖方自己的说法。
为多个客户收集数据，放进你自己的报告。一套凭证，想接多少家网店都行，结果上是你的标志。
你说哪些网店、哪些数据集、多勤。在纸面上定下任何东西之前，我们先免费确认这些网店到底读不读得出来。
同样的扫描，同样的校验。看起来可疑的扫描永远不会变成数据，所以 API 里的数字和面板里的对得上。
两条路，也可以都用。想要一整个目录的当前状态就拉取；或者给我们一个地址，每次扫描之后、每个动态发生时都会发出 webhook，无论是卖光、补货还是降价。密钥是你的，随时可以更换。
文档随凭证一起给你。它不公开，因为响应的结构和我们用 webhook 发出的动态清单，是围绕你实际接收的内容定下来的。
四件事，值得在谈价格之前知道，而不是在第一个月之后。
库存水平无法向前回溯重建。网店接得越早，之后拿到的历史越长。
销量是从库存的下降算出来的。对于公开确切数字的网店，它很接近真相。对于只显示“有货”的网店，我们会说不知道，而不是写一个零。
我们没有任何人后台、订单或顾客个人数据的访问权，也不做这类买卖。我们读一家网店的方式，和一位买家读它的方式一样。
与其承诺数据然后交出空字段，不如在报价之前就说清楚。检测免费，而且会给出明确的答案。
起点是普通的监控价目表：目录大小对读取频率。API 不是为了拥有凭证而另外收的一笔费用。
每家网店单独定价，因为成本取决于它有多难读。
两小时到十二小时之间。越勤越精确，也越贵，因为每家网店的工作量都更大。
库存和价格是一回事。广告、搜索可见度和评价是额外的数据集，也是额外的工作。
计费是预付、以美元结算，和面板里的监控完全一样。你为成功的读取付费：读不到网店的那一天不计费。