网站有三张产品落地页：一张流量最多，一张询盘最多，另一张销售认为“客户质量更好”。下周只能安排一次修改，先动哪一张？如果只把流量表交给AI，答案很可能停在点击或转化率排序；把销售结果直接拼进去，又可能因为一条询盘有多次跟进而重复计算。
OpenAI在2026年9月10日推出ChatGPT Work中的Data agent，把连接业务数据、追问变化和制作交互看板放进同一分析过程。对独立站运营者，值得先试的是一个有明确决策边界的小问题：本周优先排查哪张落地页，需要补什么证据，再决定改页面还是改获客方向。
Data提供分析入口，指标含义仍来自你的业务
Data可以使用获准连接的数据源与业务定义，并生成报告或看板。当前使用文档也覆盖Codex中的使用方式。安装入口在Plugins目录；第一次可以明确用@Data发起任务，并写清数据源、时间和比较对象。
这次更新适合把原来分散的“找报表、问数字、改图表”接在一起，但插件不会替业务团队决定什么算合格询盘。一个人连续问了三次交期，究竟算三次咨询还是一个商机，必须先有口径。
也不必为了试用先迁移全部数据。先选择已经能追溯来源的一份页面流量汇总，以及一份去重后的询盘结果。若现有流程只是定期导出CSV，先用文件做一次可复算的分析，再判断持续连接数据源是否值得投入。普通文件分析和Data插件的企业数据连接不是同一个功能；文件可读，也不代表你的CRM已经接通。
准备两张表，避免一次联接把流量放大
下面的数字都是教学假设，不是本站或客户的真实数据，也不是本次插件实测。分析窗口取某个已经结束的28天，三张页面均使用同一时区、同一渠道范围和同一落地页归属规则。销售状态统一截至窗口结束后第7天，减少刚进来的询盘尚未处理造成的差异。
第一张表一行对应一个落地页在该窗口内的会话总数，字段为landing_page、sessions、period_start、period_end。第二张表一行对应一条去重询盘，字段为lead_id、landing_page、created_at、qualification_status、status_as_of。实际使用时可以用匿名编号替换个人资料。
本例将“合格”定义为：销售已确认属于目标客户、需求在当前产品能力内，并有可继续联系的方式。待判断不能偷偷并入“不合格”；重复提交先合并为一个lead_id，合并规则也应保留。
如果把一行“页面A、1000会话”直接与A的20条询盘明细联接，再求和，会话就可能变成20000。稳妥的做法是先将询盘按页面聚合，再与页面汇总表一对一联接，同时核对联接前后的总数。这里检查的是表的粒度，不是要求AI“计算时更认真”。
无法识别落地页的询盘单列为“来源未知”，不要按现有页面比例分摊。若真实业务中缺少将询盘关联到落地页的字段，本轮只能评价有来源的样本，优先补采集，而不是编出完整归因。需要重新确认页面承担什么目标时，可以对照页面任务与转化目标的关系。
用一组完整数字，区分提交多与合格多
假设去重与口径核对后，得到下面的结果。三行中的询盘均已完成判断，没有待判断项。
| 落地页 | 会话 | 去重询盘 | 合格询盘 | 询盘率 | 合格询盘率 |
|---|---|---|---|---|---|
| A：标准包装盒 | 1000 | 20 | 12 | 2.0% | 1.2% |
| B：定制包装盒 | 400 | 24 | 6 | 6.0% | 1.5% |
| C：小批量包装 | 200 | 8 | 6 | 4.0% | 3.0% |
| 合计 | 1600 | 52 | 24 | 3.25% | 1.5% |
表里的询盘率为去重询盘数÷会话数；合格询盘率为合格询盘数÷会话数。合计询盘率是52÷1600，而不是三个百分比的简单平均。它们按本例归属口径计算，不能直接当作其他系统中名为“转化率”的指标。
再看询盘内部的质量：A是12÷20=60%，B是6÷24=25%，C是6÷8=75%。如果只按询盘率排序，B表现最好；如果看合格询盘总量，A贡献最多；如果看每次会话产生合格询盘的比例，C更高。这三种答案服务不同问题，没有哪一个字段单独等于“页面最好”。
本轮应先排查B的无效询盘来自哪里。 它的24条询盘里只有6条合格，18条值得逐条看原因。不过这还不是“先重做B页面”的证据：无效可能来自投放范围、页面承诺，也可能来自销售尚未统一执行的判断标准。
追问一次，让分析真正指向改动
沿用B的18条不合格询盘，假设人工检查后分为：10条需求低于最低起订量、5条询问未提供的产品、3条不在当前服务地区。再回到页面与获客来源，才能形成有依据的动作。
| 检查发现 | 可以安排的修改 | 验证时看什么 |
|---|---|---|
| 起订量只在下载资料中，表单前未说明 | 在规格与询盘入口附近说明起订条件，避免客户提交后才得知 | 低于起订量的询盘数量与占比；合格询盘总量是否受损 |
| 某广告组的搜索词包含未提供的产品 | 先核对投放与落地页匹配，再调整相关投放设置 | 同一来源中错误产品需求是否减少 |
| 服务地区没有说明 | 在相关交付说明与表单提示中写清地区范围 | 地区不匹配询盘是否减少，并保留其他原因分类 |
这些是本例的假设发现和对应推导，不能仅靠表里的6/24得出。真实分析时，应让Data列出每个结论所依据的记录或汇总，再由运营者检查页面和投放。否则“B质量差，所以加更多信任元素”只是跳过原因的泛化建议。
对于A，下一步可以看流量是否来自过于宽泛的查询，以及表单前是否存在阻碍。对于C，6条合格询盘尚不足以承诺增加流量后仍保持3%。可以列为后续扩大合适流量的候选，但需要检查产品供给与获客成本，不能用200次会话的比率直接预测扩量收益。
SEO与广告来源应分开比较，再讨论是否能互相借鉴。具体拆分可参考SEO与谷歌广告协同，不要把付费流量的变化写成自然搜索页面改版的结果。
这段分析要求可以直接改成你的版本
把数据字段、窗口和合格定义一起提供，再发起分析。下面是本例的完整任务描述，数据可以替换，计算要求不要随意删掉：
@Data，请使用本次提供的页面会话表和询盘明细，判断下一轮应该先排查哪张落地页。先报告各表粒度、时间范围、缺失值、重复lead_id和未知落地页，不要立刻做看板。询盘按lead_id去重，待判断单列；使用文档中的合格定义。先按页面汇总询盘，再与页面会话一对一联接。输出会话、询盘、合格询盘、询盘率和合格询盘率，并展示总计的分子分母。按“已由数据支持的判断、需要查看页面或投放才能确认的问题”分别解释优先级，保留用于复算的结果表。
第一轮先核对总计。若出现52条询盘变成54条，暂停看板，追查重复记录、空值处理或联接关系。若52保持不变，但合格从24变成30，优先核对状态筛选与截止日期，而不是只调整图表标题。
第二轮才要求图表：三张页面的会话与合格询盘分别呈现，另加各类不合格原因；图旁保留窗口、渠道和更新时间。最后配一张行动表，写明“先查B的起订量表达，负责人为内容编辑，待观察低起订量询盘变化”。不需要塞进十多个只有装饰作用的指标。
刷新与分享，分别解决两个问题
做出看板以后，先用原始表复算其中一行和总计。再用同一口径刷新下一窗口，记录页面修改日期、渠道构成及是否还有待判断询盘。即使比例改善，也要分清新增询盘质量改善与流量来源变化；没有控制这些条件，就不能把差异全算在改文案上。
如果准备交给客户，分享前先检查看板中是否含明细。Data文档说明，通过OpenAI Sites发布时，分析数据会复制进发布站点。原数据源的访问限制不能替代对分享对象的检查。只需要让客户看页面级汇总时，就不要把联系人、邮箱或销售备注带进公开或广泛共享的产物。
连接失败时也要分层处理：目录里没有Data，看工作区安装策略；装了Data但找不到某个来源，查相关数据源插件和app的配置；已经连接却缺少记录，就用同一个连接身份去源系统确认权限和数据是否存在。模型无法通过更强的提示词补出账号无权访问的行。
本轮完成的标准很具体：总数可以复算，B的排查优先级有原因分类，修改针对了实际观察到的页面或投放问题，下次还可以按同样定义比较。报告如何让客户理解这些变化，可以继续看SEO月报的衡量方法。
常见问题
没有数据仓库，也值得试Data吗？
先看你的资料是否已经能回答一个小问题。整理好的导出文件适合验证分析口径；持续连接数据源则要看Data及相关app是否可用。没有必要只为做一次52条询盘的分析迁移整个数据系统。
为什么合计转化率不能取各页面的平均值？
各页面会话量不同。本例应计算52÷1600=3.25%。把2%、6%、4%平均成4%，等于让200次会话的C和1000次会话的A拥有相同权重。
Data给出的改版建议，能证明改完会增加询盘吗？
不能。已有数据可以提出值得检查的方向；页面检查和原因记录支持具体修改；修改后的结果仍需要在明确的时间、来源和判断口径下观察。本例没有真实效果测试。
安装了插件，为什么还是读不到CRM资料？
Data、数据源插件、底层app授权和源系统账号权限是不同环节。先确认缺的是入口、连接还是某些记录，再让管理员或数据负责人处理对应问题；安装成功本身不会扩大CRM权限。