销售在 CRM 里看到一条询盘，来源写着“官网”，客户却明确说自己从百度搜索某个型号进来。运营回查时只找到提交表单的联系页面，最初访问的产品页、搜索词线索和停留路径都没有留下。表单隐藏字段可以补上这段信息，但它不能只记当前 URL，也不能把浏览器里能取到的内容一股脑塞进数据库。
先记录够用的来源字段
制造业官网的询盘来源表，至少要区分首个落地页和提交页。`first_landing_path` 记录访客第一次进入的站内路径，例如 `/products/mtx-40a.html`；`submit_page_path` 记录实际打开表单的页面。两者放在一起，销售才能看出客户先研究了哪款产品，最后从哪个入口提交。
来源信息还需要 `referrer_domain`、`utm_source`、`utm_medium`、`utm_campaign`、站点语言、表单版本和提交时间。referrer 建议只保留域名与必要路径，不要长期存整条 URL。搜索引擎、聊天工具或邮件链接有时不会传 referrer，字段为空不能直接判定为直接访问，更不能为了报表整齐强行填成 SEO。
隐藏字段名称要与 CRM 对齐。网页里叫 `utm_source`，CRM 却存到“渠道备注”，后面很难筛选。较稳的做法是给渠道使用固定枚举，如 organic、paid、email、referral、direct 和 unknown，原始值另存一列。运营负责维护映射表，销售看到的是统一渠道，排查时还能回到原始记录。
表单版本容易被忽略。联系页改过字段、验证方式或跳转逻辑后，同一来源的提交率可能变化。`form_version` 可以使用发布日期或内部版本号，配合页面路径判断结果。版本号只服务复盘，不需要展示给买家，也不该每次改一处提示文字就刷新。
首次来源和本次来源要分开
买家第一次从自然搜索进入产品页，当天没有询价；三天后从销售邮件回到案例页，再打开联系表单。只读取提交时的 referrer，这条线索会被记成邮件。首次触点说明最早怎样发现企业，本次触点说明什么内容促成提交，两者回答的问题不同，应分别保存。
首次来源可以在访客同意必要的统计设置后，写入第一方 cookie 或服务端会话，设置合理的保存期限。本次来源每次访问都更新，但提交时把首次与本次字段一并写入。跨子域名时要核对 cookie 作用域；多语言站点跳转到另一个域名，来源可能丢失，需要通过受控参数传递匿名访问标识，并在目标域重新校验。
来源参数不能当作可靠身份凭证。访客可以修改隐藏字段，推广链接也可能被转发。系统可用它做渠道分析和销售分配，不能据此判断客户身份、合同归属或佣金。涉及渠道结算时，还要结合账号、沟通记录和后端日志复核。
完整查询参数里可能带邮箱、手机号、会话编号甚至客户名称。入库前应建立允许字段清单，只接收已定义的 UTM 参数和页面路径，过滤令牌、密码重置参数与个人信息。日志保存期限也要写进隐私说明。销售只需要知道客户从哪个产品页来，不需要看到浏览器留下的全部痕迹。
入库前后各做一次验证
前端测试不能只看隐藏输入框是否有值。分别模拟自然搜索无 referrer、带 UTM 的邮件、其他网站推荐、站内跳转后提交和拒绝统计设置几种情况，检查首个落地页是否保留，本次来源是否更新。测试链接使用固定标记，完成后从统计报表和 CRM 中排除。
提交成功后还要核对后端链路。数据库原始记录、邮件通知和 CRM 字段应保持一致，中文栏目名不能写进英文渠道字段，空值也不能在同步时变成“百度”。若表单同时支持附件，要确认来源字段不会因为上传超时而重复写入，CRM 去重键也不能误用访客 cookie。
上线后的第一周，可以抽取少量询盘与销售记录逐条核对。销售问客户从哪里了解到企业，再与隐藏字段比较。两者不一致并不一定是程序错误，客户可能记不清，或先搜索后从同事转发的链接提交。持续出现同一种偏差，才需要检查跳转、cookie、隐私设置或渠道映射。
来源数据最终要服务动作。产品页带来的自然搜索询盘，可以回到具体型号与资料下载情况；某个案例页经常成为提交前的最后触点，运营就该检查它是否把工艺、材料和交付范围讲清。字段没有进入销售分配、内容复盘或预算判断，只会让 CRM 多出几列无人维护的数据。
隐藏字段不会自动解决归因问题，它只是在买家不必多填信息的前提下，保存一组可复核线索。字段定义、首次与本次触点、隐私过滤和 CRM 映射同时明确，SEO 带来的询盘才不会统统落进模糊的“官网来源”。