电子商务中的 AI 代理： 一份准备情况核对表。
在 AI 代理大规模购物您的商品目录之前，需要审计的五个领域。零售团队本季度无需新工具即可验证每个项目。
如何使用本功能
按顺序处理这些区域。前两项决定代理是否可以读取您；后三项决定您是否可以证明之后发生了什么。将每个项目评分为已满足、部分满足或未知 — 未知通常是最有启发性的结果。
1. Product data
- 每个可购买的变体在提供的HTML中都有明确的标识符和标题。
- 价格、货币和可用性以结构化值形式存在，而不仅仅是呈现的 UI。
- 数据 Feed 的新鲜度存在已知延迟，并且有专人负责。
- 退货、配送和保修条款以代理可提取的文本形式存在，而不仅仅是图标。
2. Storefront delivery
- 主要产品内容位于服务器交付的 HTML 中，可在原始视图源代码中验证。
- 产品页面响应无需cookie、同意交互或客户端导航。
- 速率限制和机器人规则不会悄无声息地丢弃您打算允许的提供商文档化的抓取器。
3. Cart and checkout
- 结账不依赖于只有人工浏览器会话才能完成的交互。
- 风险规则是根据代理发起的请求模式进行审查的，而不仅仅是人类会话模式。
- 故障模式是可观察的：您可以区分被拒绝的代理结账与静默流失。
4. Logging and measurement
- 服务器、CDN 或应用程序日志保留用户代理、路径、引用来源和时间足够长，以便进行分析。
- 日志源请求事件可与它们访问的店面表面关联。
- 您可以报告在标记后仍未分类的合格请求事件的份额。
5. Crawler and agent policy
- robots.txt 反映了根据提供商文档令牌做出的深思熟虑的决定，而非继承的默认值。
- 允许和不允许的选择由负责需求的团队而非仅安全团队审核。
- 用户代理字符串中的身份声明在验证之前均被视为声明。
审计之后
大多数团队在完成此清单后，日志行中只有一小部分未知项。这就是 Cartograph 构建的初始条件：将日志源请求事件转化为带标签的证据集，并诚实地报告未分类的剩余部分为 未识别流量 而非推断从未观察到的意图。