资料下载后如何记录来源、语言版本和销售跟进状态？

后台每天都有表单提交，月底也能导出姓名、邮箱和公司名。可一到复盘，哪条渠道带来的客户更合适仍然说不清；销售接过名单，也不知道对方看的是英文产品册、阿拉伯语选型手册，还是两年前的旧版 PDF。表里有数据，前后工作却没接上。

问题通常不在于少装了一个工具，而在于记录方式从一开始就只围着表单字段设计。下载是一次行为，联系人是一个会重复访问的人，销售跟进又是一段持续变化的过程。三者有关联，却不是同一件事。

一次下载，至少要留下三层记录

比较稳妥的做法，是把下载事件、联系人和销售跟进分开保存，再用统一的联系人 ID、线索 ID 或 CRM 记录 ID 关联起来。

这一步看似多了一层，后面反而省事。同一个联系人一个月内下载三份资料，不必在 CRM 里生成三个互不相干的人；同一份资料被不同渠道带来访问，也不会因为表单字段相同而丢掉来源差异。

联系人去重时，企业邮箱通常可以作为主要线索，但不能把它当成永远可靠的唯一键。有人会换邮箱、使用公共邮箱，也可能先匿名下载，之后才填写完整资料。系统内部仍应生成不随邮箱变化的联系人 ID，并保留合并记录。否则一旦改邮箱，过去的下载和跟进历史很容易跟着断开。

来源要同时保存“原始值”和“归一值”

来源记录最忌讳只留一个“来自 Google”或“来自展会”的下拉框。它能做粗略汇总，却无法解释客户究竟点了哪条广告、哪封邮件、哪个合作伙伴链接，也不能还原没有 UTM 参数时的真实入口。

建议至少保存下面这些值：

Google Analytics 对手动广告系列参数的公开说明中，utm_source、utm_medium 和 utm_campaign 用来识别来源、媒介和活动；utm_content 可区分同一活动中的素材或链接。企业内部可以沿用这套通行命名，但字段值要先定字典。例如邮件统一写 email，不要让 Email、edm、newsletter 和中文“邮件”同时存在，最后再靠人工合并。

原始值不要删。归一值是为了报表，原始值是为了追查。渠道命名规则改过，或者某次链接被错误标记时，保留 source_raw 才能重新计算。第一次来源和本次来源也应分开：前者回答客户最早怎样认识企业，后者回答哪次触达促成了这次下载。只保留最后一次，会把前面的内容贡献全部冲掉；只保留第一次，又看不到后续培育发生了什么。

语言版本不是只记一个“English”

跨语言网站至少有三个可能不同的值：客户浏览页面的语言、实际下载资料的语言，以及客户希望销售后续使用的语言。

比如客户在英文页面进入，下载了德文技术手册，并在表单里选择希望德语联系。如果系统只记页面语言，销售就可能继续发英文资料；如果只记下载语言，又会把一次偶然下载误判成长期沟通偏好。

因此，建议分开保存：

• ‎page_language：提交下载时页面使用的语言。
• ‎asset_language：所下载文件本身的语言。
• ‎preferred_contact_language：客户明确选择或后续确认的联系语言。
• ‎asset_id：资料的稳定编号，不随文件名改变。
• ‎asset_version：发布版本或修订号，例如 ‎v3.2。
• ‎asset_published_at：该版本正式发布时间。

语言值最好采用 IETF BCP 47 的语言标签。en 表示英语，de-DE 可表示德国地区使用的德语，zh-Hans 表示简体中文书写系统。是不是需要细到地区或书写系统，要看业务是否真的存在差异；没有差异时不必为了显得精细而强行增加层级。

资料版本也不能靠文件名猜。catalog-final-new.pdf 对上传者或许看得懂，进入 CRM 后几乎无法稳定识别。更实用的关系是“同一个 asset_id 下有多个版本和语言变体”。资料更新后，旧下载记录仍指向客户当时真正拿到的文件，不会被新文件覆盖。遇到参数、认证或价格信息更新，团队也能找到曾下载旧版资料的联系人，判断是否需要补发新版本。

销售阶段与跟进状态，最好分成两条线

很多 CRM 只有一个“线索状态”字段，市场、销售和管理人员都往里面写。结果是“已下载资料”“已联系”“商机”“暂无需求”混在一起：有的是生命周期阶段，有的是销售动作，还有的是暂时结果，彼此无法比较。

可以把它拆成两类。

生命周期阶段回答这条关系走到了哪里，例如新线索、营销确认线索、销售确认线索、商机、客户。HubSpot 在 2026 年 7 月更新的生命周期阶段说明中，也把 Lead、Marketing Qualified Lead、Sales Qualified Lead、Opportunity 和 Customer 作为不同阶段，并允许企业按自身流程定制。这里值得借鉴的是“阶段用来表示关系所处位置”，不是照搬某一家产品的默认名称。

销售跟进状态回答销售眼下做到了哪一步，例如待分配、待首次联系、已尝试联系、已建立联系、需求确认中、转长期培育、已判定无效。状态必须配进入条件，不能只给一串名称。

例如，“已尝试联系”应当有真实的联系动作和时间；“已建立联系”意味着已经获得对方回应，不能因为发出一封邮件就自动进入；“需求确认中”至少要记录客户关注的产品或问题；“无效”必须选择原因，如测试提交、非目标地区、个人邮箱无法确认、重复记录或明确拒绝。把所有没回复的人都标成无效，会让市场团队误判内容质量，也会让后续培育名单越来越失真。

每次状态变更还应留下这些信息：

• 状态变更前的值、变更后的值和变更时间。
• 操作人或自动化规则名称。
• 当前负责人及分配时间。
• 最近一次有效联系时间和联系结果。
• 下一步动作、计划完成时间。
• 暂缓、退回或关闭的原因。

只保存“当前状态”不够。它能告诉管理者现在有多少条待联系线索，却解释不了一条线索在某个阶段停了多久、被谁退回、为什么又重新启用。保留状态历史，才能计算首次响应时间、阶段停留时间和转化路径，也便于纠正误操作。

把字段放回一条真实记录里看

假设一位联系人第一次通过自然搜索进入英文产品页，后来点击 LinkedIn 广告回到网站，下载了 VALVE-GUIDE 的德语 v3.2 版本，并选择德语联系。这次记录可以这样落：

这不是要求销售每天手工填写十几个格子。页面语言、资料 ID、资料版本、UTM 参数、落地页和下载时间都可以由网站在提交时写入；渠道归一、负责人分配和初始状态可以由规则处理。真正适合销售补充的，是联系结果、需求判断、下一步和无效原因。自动采集和人工判断各管一段，字段才会长期有人用。

上线时还有几处容易漏掉

下载链接被转发后，来源参数可能已经丢失，因此下载事件应在网站服务端或受控的表单流程中落库，不能只依赖浏览器页面临时保存。页面表单也要防止重复提交和机器人记录，至少保留提交时间、IP 风险判断结果或验证码结果、表单版本及隐私同意文本版本；涉及个人信息时，只收集完成当前用途所必需的内容，并按企业适用的隐私规则设置访问权限和保留期限。

资料本身要有一份可维护的主数据表。资料标题可以改，文件可以替换，asset_id 不应随之改变；语言、版本、发布时间、适用产品、有效状态和替代版本要能查到。否则 CRM 虽然记了一个文件名，半年后仍然没人说得清客户当时看到了什么。

销售状态字典也需要有人负责。增加状态前先说明它和现有状态的区别、谁有权修改、进入与退出条件是什么、报表里怎样计算。长期没人使用的状态应停用，但历史值不要直接删除。流程变化是正常的，历史记录被改得面目全非才是问题。

红数科技配置资料下载与线索承接时，会把验收放在一个很具体的场景里：销售只打开这一条记录，能不能确认客户从哪里来、拿到过什么、该用什么语言联系，以及前一位同事已经做过什么。下一位经手人不需要回头翻广告后台、网盘和聊天记录，下载动作才算真正接进了销售流程。

参考资料：

• Google Analytics：流量来源维度、手动标记和自动标记
• IETF RFC 5646：用于识别语言的标签
• HubSpot：使用联系人和公司的生命周期阶段