新表单的提交按钮很醒目，实验报告显示点击增加，销售却没有收到更多询盘。可能因为用户点击后校验失败，也可能有垃圾或重复提交。实验接入不能只问脚本有没有安装，还要确认报告记录的究竟是什么动作。
WordPress与其他网站，接入方式不同
XunL A/B测试接入说明提供WordPress插件与JS SDK两条路径。前者把现成表单集成封装起来，其他平台则从后台创建站点连接、复制属于自己的脚本，放进公共head。不要把示例公钥当作真实连接，也不要把连接密钥放进网页。
Shopify、Webflow、自建站与跟踪代码管理器的安装位置和平台限制不同，应按当前接入说明与账户实际条件核对。通过标签管理器加载可能更晚，若可视化改动明显闪烁，需要检查加载位置与改动范围，而不是反复增加同一脚本。
先决定主要目标，再写事件
例如目标只是询价按钮点击，可以使用明确的CSS选择器，如 #quote-button；若目标是开始填写，可定义 quote_started 自定义事件。它们都是行为线索，不应直接命名成已成交或成功询盘。
成功询盘应由服务器在保存或发送成功之后确认。表单需要带上实验上下文，服务器按页面提供的签名方案提交确认，并使用自己的询盘编号去重。点击、校验失败和未接受的垃圾内容，不应被当作成功事件发出。
可以先画事件链：看到页面、点击按钮、提交请求、业务接受、通知销售。每个节点都有不同含义，选一个主要目标作实验判断，其他作为参考。开跑后再挑最好看的动作替换主指标，会改变原来要回答的问题。
访客同意与单页路由，要单独验收
默认pending模式下，SDK等待同意。应把网站已有同意机制与接入回调连接，并测试同意、拒绝和撤回三个状态。具体采用何种同意策略应由网站实际要求决定，不应为了让数据快点出现就直接跳过既定流程。
单页应用不一定重新加载整份页面。使用history.pushState改变路由后，应按说明调用 XunLExperiments.refresh()，重新匹配实验。只在首页确认脚本存在，不足以证明内页路由、前进后退与目标事件也都正确。
用一条真实业务链路核对报表
验收材料应包含站点连接、目标定义、测试条件和对应业务编号。预览与正式实验要区分，服务端确认也要检查重复请求是否不会重复计数。不要通过批量制造假询盘让报表看起来有数据，应使用经过授权的测试或真实事件核对。
SDK配置失败或超时时保留原页面，不等于所有视觉体验都无需检查。页面分流适合整页方案，可视化修改适合较小变化；无论哪种方式，都要检查导航、表单和移动端功能。实验安装完成后，还要按样本计划运行，统计工具不会替代业务判断。
只统计感谢页访问，能代表询盘成功吗？
要看感谢页是否只能由真实成功流程到达，以及刷新、直达和重复访问如何处理。若需要与销售线索一致，服务端确认通常更接近真实业务状态，不能仅靠页面名称推定。
报表为空，是否要立刻重复安装脚本？
先查同意状态、连接信息、页面匹配与事件定义，再看实际请求和业务流程。重复安装可能制造新的问题，应沿接入链逐项定位。
个人微信：ssevening
