助贷客户数据来源怎么填？三层字段和一条能被倒查的链

8495 条线索，来源字段一共只有 5 个取值：两个市场渠道各 4673 条和 3197 条，一个渠道代号 615 条，「手动新建」9 条，还有 1 条是空的。没有「来源类型」，没有「提供方」，没有「授权凭据」——这三个东西在系统里都不存在。

这就是「助贷客户数据来源怎么填」最真实的答案：不是填一个名字，是填三层。名字只能回答「从哪条路来的」，回答不了「谁给的、凭什么给的、能不能倒查到具体某一批」。而检查时被问到的，往往是后三个。

这篇不谈该不该买数据（那是法律判断，本文不给结论），只谈一件事：如果一家机构想让自己的数据来源说得清，系统里该有哪几个字段、每个字段该存什么、录进去之后怎么被查出来。文中数字来自自有系统生产库实测（2026-10-24），只说明字段结构，不涉及任何真实客户信息。

一、助贷客户数据来源怎么填：三层字段，不是填一个名字

先看现在的通行做法。多数助贷 CRM 的「来源」是一个下拉框，选项大致是：电销名单、信息流、转介绍、渠道合作、老客复购。销售录客户时选一个，管理端据此做渠道分析。这套设计在「算投放 ROI」这个用途上是够的，但在「说明数据来历」这个用途上几乎没用。

原因很简单：同一个下拉值，背后的法律状态可能完全不同。「信息流」可能是自己投的落地页（有表单授权），也可能是从第三方买的点击包（授权来历不明）；「渠道合作」可能是签了合作协议的持牌机构转介（有协议、有授权），也可能是同行之间互相倒名单（什么都没有）。选项一样，性质差了一个量级。

所以要拆成三层，每一层回答一个问题：

类型层回答「怎么来的」——自采、采购、转介、投放、客户主动咨询。五种，不多不少，因为这五种对应的举证材料完全不同。

提供方层回答「谁给的」——具体到一家公司或者一个渠道编号。这一层是「可追责」的落点：出问题时，你要能指到具体主体，而不是一句「渠道给的」。

凭据层回答「凭什么给的」——授权文本的版本、授权时间、授权的业务范围、有没有撤回记录。这一层最容易被做成摆设，第四节专门讲。

三层落成字段，一张录入页就能承接。但先别急着设计表单——把三层的判据讲清楚，表单自然就出来了。另外提一句验收时最容易漏的角色：提供方本身要有资质材料，站内助贷中介需要什么资质那篇把五份材料分成「能做」和「能证明」两类，可以直接拿来当提供方准入的清单——数据从谁那里来，先看那个人能不能拿出材料。

二、类型层：五种来源，举证方式各不相同

五种类型不是拍脑袋分的，是按「你能拿出什么」分的。

第一种，客户主动咨询。官网表单、公众号留言、电话打进。举证最轻：一条提交记录 + 一次勾选。实测里系统的咨询表（`consult_leads`）有 12 个字段，其中 `agreed_at`（授权时间）、`ip`、`source_path`（从哪个页面来的）都有——这是五种类型里唯一一种「举证材料天然存在」的。可惜这张表只有 2 条记录，说明官网咨询这条线的量极小，主力不在这。

第二种，自采。自己的地推、自己的电销团队、自己的老客转介。举证靠「过程记录」：谁采的、什么时候采的、在什么场景下采的（扫楼、市场摆点、老客介绍）。这一类最容易出问题的地方是「员工私下攒名单」——采集动作发生在系统外，事后无法说明。

第三种，采购。从数据服务商买。举证最重：采购合同、数据字段清单、提供方的合规声明、交付批次记录。这一类的关键不是「有没有合同」，是合同能不能对应到具体哪一批数据。合同签了 10 万条，系统里进了 12 万条，多出来的 2 万条说不清。

第四种，转介。同行、担保公司、助贷经纪人推过来的客户。举证靠「转介协议 + 客户知情的证据」。这一类的灰色地带最多：很多转介是「我一个朋友给的」，没有协议，也没有客户同意。这一类在系统里如果只记一个渠道名，等于没记。

第五种，投放。信息流、搜索、短视频。举证靠「落地页快照 + 表单授权记录 + 投放平台后台」。这一类的坑是落地页改版：三个月后要举证，发现当时的授权文案已经改了三版，找不到客户当时看到的那一版。

把这五种列出来，你会发现一件事：五种类型里只有第一种的举证材料是自动产生的，其余四种都要靠流程去造。这就是为什么「来源」不能只是一个下拉框——它必须带着「这一类该有哪些附件」的规则。

给一条可操作的判据：在系统里把类型选完之后，页面应该自动要求补齐对应的材料。选「采购」不传合同编号，提交不了；选「转介」不填协议编号，提交不了。做不到这一点的，说明来源字段只是标签。

三、提供方层：谁给的，协议里要能看出三件事

提供方这一层，难点不在技术，在「主体」这件事本身容易被写虚。

实测里 `customers` 表的 `channel` 字段只有 4 个取值，`leads` 表的 `source` 只有 5 个取值——这意味着一个渠道就是一个字符串，没有对应的主体信息：这家渠道的全称是什么、统一社会信用代码是什么、合作协议什么时候到期、能不能联系上。这些信息一旦不在系统里，出事时就要去翻合同柜。

正确的做法是把提供方做成一张独立的表（主数据），渠道字段只存这张表的 ID。这张表至少要有六个字段：主体全称、统一社会信用代码、合作类型（转介/采购/投放代理）、协议起止日期、协议附件、状态（合作中/已终止）。

为什么必须单独建表？三个很实际的理由：

理由一，一个主体可能供多种数据。同一家渠道，既给你转过介客户，也卖过名单。如果渠道只是字符串，你分不清这批客户走的是哪条合作线。

理由二，协议会到期。协议到期后继续用这家渠道的数据，是一个很容易被忽略的时间差问题。做成表之后，到期提醒是一个功能；做成字符串，就只能靠人记。

理由三，终止合作时要能切断。某家渠道被叫停，你要能在系统里一次找全它供过的所有客户。字符串靠模糊查询，表靠外键，后者不会漏。

协议里要能看出三件事，这三件事直接对应系统字段。顺带说，渠道主数据这张表不只服务「合规」，它同时是分佣的底座——站内助贷分佣管理怎么做讲的渠道版结算，前提就是渠道必须是一个主体而不是一段文字，否则月底对账时两边的名字对不上。

一是数据用途的边界。协议写「用于甲方自身助贷业务的客户开发」，那这批客户就不能拿去二次转卖、不能拿去给关联公司用。系统里对应的是「用途范围」字段，以及一个很硬的问题：这条客户能不能转派给别的机构？如果系统没有这个概念，用途边界就落不了地。

二是授权链条的传递。客户当初同意的是「被 A 机构联系」，还是「被 A 及其合作机构联系」？这两种表述决定了你能不能把客户转给资金方。转介类业务里，这一条几乎全靠口头，最后变成「客户投诉说没同意过」时才补材料。

三是终止后的处理。协议终止，数据要删还是要留？留多久？这一条如果写不清，系统里就没有「到期自动归档」的动作，数据会一直躺在库里。这一层和SaaS系统的数据到底放在哪那篇的「留存与删除」是同一个问题的两面：那边问「存多久」，这边问「凭什么存」。

四、凭据层：授权是一份可回看的文本，不是一个时间戳

这一层最容易被做成摆设，因为它看起来「已经有了」。

实测里 `consult_leads` 表有 `agreed_at` 字段，两条记录的值分别是 2026-09-05 20:52:29.829276 和 20:52:29.833605——注意它们的 `created_at` 分别是 20:52:29.833605 和 20:52:29.534536。授权时间和提交时间相差 4 毫秒。

4 毫秒说明什么？说明「勾选同意」和「提交表单」是同一个动作，一次点击完成的。这在工程上完全正常，但在举证上是一个只有时间点、没有内容的记录：你知道他什么时候同意的，但你不知道他同意的是哪一版文本。

授权文案会改版。今年写的「同意由本平台及合作机构为您提供服务」，明年可能改成「同意由本平台为您推荐持牌金融机构的产品」。这两句话的授权范围不一样。如果系统里只存一个 `agreed_at`，一年后你无法证明某个客户同意的是哪一版。

所以凭据层要存四样东西，缺一样都不完整：

第一，授权文本的版本号。不是把全文存进每条记录（那会让库爆炸），而是存版本号，再把每一版全文存在一张「授权文本」表里。查的时候用版本号去关联。判据：能不能查到 2026 年 3 月那一版授权文案的原文？查不到，说明版本管理没做。

第二，授权的业务范围。同意被联系、同意被查询征信、同意被推荐给资金方，这是三件不同的事，要分开授权、分开记录。做成一个笼统的「同意」，等于什么都没同意。

第三，撤回记录。客户说「别再打了」，这个动作必须有一条记录，并且能触发后续的拦截（黑名单、外呼屏蔽）。只记「同意」不记「撤回」的系统，是半个系统。

第四，获取场景。在哪拿到的：官网哪个页面、门店哪次面谈、哪个渠道的哪一批。这一条是倒查的入口，下一节展开。

合规边界说明一句：上面讲的是「怎么把授权记录下来」，不是「怎么算合法」。具体到某一类数据能不能用、授权文本怎么写才有效，属于法律判断，本文不给结论。站内助贷机构怎么做合规留痕那篇讲的是六类记录怎么存、存哪、留多久，可以和这一节对着看——那边管「有没有」，这边管「够不够」。

五、实测：8495 条线索的来源字段只有 5 个取值

把实测数据摆开，问题会更清楚。

来源字段的取值分布：两个市场渠道 4673 条 + 3197 条（合计 7870，占 92.6%），第三个渠道代号 615 条，「手动新建」9 条，空值 1 条。合计 8495。

字段形态：自由文本，不是外键。这意味着「汉口北」和「汉口北市场」会被记成两个渠道；这也意味着渠道名里塞不进任何主体信息——统一社会信用代码、协议号、到期日，一个都没地方放。这类「渠道名其实是市场名」的现象在各地都一样，上海助贷CRM怎么选那篇讲过分配规则怎么配，可以相互对照。

「手动新建」的 9 条：这个取值本身很有意思。它说明系统允许「不选来源」直接建客户，而这 9 条恰好是最难举证的一类——不是渠道给的，也不是表单来的，是人在后台敲进去的。真实业务里，「手动新建」往往对应「老板朋友的客户」「同行私下转的」这些场景，恰恰是最需要凭据的。而系统给了它一个合法的出口。

再看客户表：656 行里 `channels` 只有 4 个取值，其中一个占 614 行（93.6%），10 行是空的。两个表的口径还不完全一致（线索侧 5 个取值、客户侧 4 个取值），说明这两张表各记各的，没有共用同一套渠道主数据。

这三条摆在一起，能得出一个很朴素的结论：这套系统在「算渠道效果」上是够用的，在「说明数据来历」上是不成立的。因为它把「渠道」当成一个分析维度，而不是一个责任主体。

六、倒查那一条链：从客户回到批次，中间有四道门

「能不能倒查到某一批」这句话，落到系统上是四条链路。任何一条断了，倒查就断在那一环。

第一道门，客户 → 线索。客户表里要有一个指向线索的字段。实测里 `customers` 656 行中 `source_lead_id` 有值的只有 53 行（8.1%）——也就是说九成以上的客户，无法从客户记录回到它最初的那条线索。这一道门基本是关着的。

第二道门，线索 → 导入批次。批量导入要留批次号，每条线索记下自己属于哪一批。有了批次号，才能回答「这批 226 行是谁导入的、什么时候导的、用的什么文件」。这一层很多系统有，但只存在导入日志里，没有回写到线索上——查的时候要拿时间戳去猜，很不牢靠。批次内还要能去重，否则同一个客户在两批里各出现一次，倒查时会出现「两条记录对应两个来源」，助贷线索去重怎么做拆过这套归一化与合并规则。

第三道门，批次 → 提供方与协议。批次要挂在提供方下面，提供方要挂在协议下面。这一层如果没有，前两道门白做：你知道这批数据是 10 月 12 日导的，但不知道是谁给的、依据哪份协议。

第四道门，客户 → 授权凭据。最后落到那个具体的人：他同意了什么、什么时候同意、看的是哪一版文本。这一层如果只有时间戳（如上一节所述），倒查的终点就是「他同意过」，而不是「他同意了这件事」。

四道门，每道门都对应一个字段。所以「能不能倒查」这个问题，在选型阶段就能问出答案：让对方打开一个客户的详情页，从客户点到线索、从线索点到批次、从批次点到渠道协议、再从客户点到授权记录。四跳能走通，这套系统的来源管理是成立的；跳两下就断，后面补不上——因为补的时候历史数据已经缺了。

顺带提一个反直觉的判断：不是数据量越大越难倒查，是字段越自由越难。一个只有 5 个取值但全是自由文本的字段，比一个 50 个取值但走字典 + 外键的字段，更难追责。前者的问题是「对不上」，后者的问题是「选得慢」。

七、录入页该长什么样：八个字段和三条校验

前面六节讲判据，这一节给可直接抄的落地方案。八个字段，覆盖三层。

类型层的两个字段：「来源类型」（字典，五个选项：主动咨询 / 自采 / 采购 / 转介 / 投放）、「获取场景」（自由文本 + 建议值，例如「官网表单-首页弹窗」「门店面谈-天河」「渠道批次-编号」）。后者比前者更值钱，因为它是倒查的入口。

提供方层的三个字段：「提供方」（外键，指向渠道主数据表）、「协议编号」（外键，指向协议表）、「数据用途范围」（字典：仅本机构自用 / 可转介给合作资金方 / 可内部跨部门使用）。第三个字段决定了这条客户能不能被转出去，是很多纠纷的源头。

凭据层的三个字段：「授权文本版本」（外键，指向授权文本表）、「授权范围」（多选：接受联系 / 查询征信 / 推荐给资金方）、「撤回时间」（时间戳，可空）。

三条校验，是让这套字段真正生效的关键：

校验一，类型决定必填。选「采购」，必须填提供方和协议编号；选「转介」，必须填协议编号和授权版本；选「主动咨询」，必须能关联到表单提交记录。选完类型不补材料，提交不了。

校验二，撤回落黑名单。「撤回时间」一旦有值，这条客户应当自动进入外呼屏蔽，并且任何新的拨打任务都分配不到他。这一步不是提醒，是硬拦。

校验三，批次必挂主体。批量导入时，批次必须选择提供方和协议，不能选「无」。这条校验会挡住一批「先导进来再说」的操作，而这正是最需要挡的。

三条校验会不会让录入变慢？会，但只在两类场景：批量导入时选一次主体（一次动作，管一批），和手动新建时选一次类型（一次动作，管一条）。日常跟进不需要碰这些字段——它们的生命周期是「入库时填一次、之后只读」。这一点很重要：来源字段是入库属性，不是跟进属性，别让它出现在销售的日常表单里。这一层和助贷CRM权限怎么分级里的字段级权限是配套的：来源与协议字段通常只对主管可见可改，销售只看不改。落地顺序上，建议先做「类型 + 提供方」两层（这两层能立刻改善渠道报表），凭据层随后补——因为它要牵动授权文本版本表和外呼拦截，工作量更大。分配环节也要跟上：没有提供方信息的客户，不应该被自动分配出去，这一条可以做成分配规则里的硬条件，具体配置见助贷线索怎么自动分配。

八、助贷客户数据来源常见问题

我们的客户大部分是渠道给的，是不是把渠道名填上就够了？不够，而且这是最常见的一个缺口。渠道名只回答「谁给的」，回答不了「依据什么给的」。建议至少补两个字段：协议编号、授权文本版本。补的时候不用一次性补全历史数据——按渠道倒着补，先把占比最大的那两个渠道补上（实测里两个渠道占了 92.6%），覆盖八成客户就够了。剩下的小渠道，用「协议已归档」这种粗粒度标记兜底，比什么都不记强。

客户在电话里口头同意了，这种怎么记？记「时间 + 录音 + 话术版本」三样。录音是最硬的证据，但前提是录音能关联到客户、能调出来播放；话术版本是为了说明「当时念的是哪一段」。如果系统里录音只挂在通话记录上、不挂在客户上，那要先把这层关联补上——站内助贷客户资料怎么防止被导出讲的是「别漏出去」，这篇讲的是「能说明白怎么进来的」，两件事都要做，但顺序上先做后者，因为漏出去往往就是从说不清来历的那批数据开始的。

数据服务商说他们「都是合规的」，我要看什么？看三样东西，缺一样就往下问：一是他们提供的字段清单（你要的字段是否在他们的授权范围内）；二是他们给上一家客户的授权样例（不是给你的合同，是客户端的授权文本长什么样）；三是他们怎么处理「客户撤回」。第三样最能看出深浅——只会说「我们数据都是合规的」但答不出撤回流程的，通常没有这套流程。另外提醒一句：具体到某类数据能不能采、能不能用，属于法律判断，本文不给结论，建议让专业人士看合同原文。

历史数据已经导进来了，来源没记，现在补还有意义吗？有，但要换个补法。不要试图逐条回溯（成本极高且多数回溯不出来），改成「按批次补主体」：把这批数据是谁、什么时候、依据哪份协议补在批次上，然后让这批客户继承批次的来源信息。这样做的效果是——单条客户仍然说不清他个人的授权细节，但整批客户能说清来历。如果连批次都查不到（导入日志没留），那就只能按「存量待核」标记，并且在后续新增时严格校验。想先看这套字段在你的业务里怎么落，可以查看价格与版本说明，对着现有的数据量估一下补录工作量。

回到开头那 5 个取值。它们不是错误，是阶段：一家机构从「靠渠道关系做业务」走到「靠可核验的记录做业务」，来源字段一定会先简单、后复杂。真正要避免的不是「现在填得少」，而是等到被问起来的时候，才发现系统里根本没有地方可以填。三层的意义就在这里——它不是为了报表好看，是为了在被问「这批人哪来的」时，你能点四下鼠标给出答案。想先弄清这四跳在你现有系统里能走通几跳，可以对着助贷获客平台怎么选那五个问题一起问，那边问的是「数据从哪来」，这边问的是「来了之后怎么记」。