先说结论：转化不是一次点击，是一条链路
先说结论：10-11 那天，一位访客在 18 分 29 秒里走完了「申请 Demo → 登录 → 生成 PPT」三步，产品被真实用通了；同一天，我们的官网线索表里没有他。不是他没用，也不是我们没测——是「申请成功」这个动作，被记在了另一套系统里。
把这件事拆开看，它由三条各自独立的通路组成，每一段都工作正常：
- 申请提交：访客在产品页面上提交申请，产品自己的接口返回成功、发体验账号——这条记录在产品自己的库里；
- 行为埋点：站点把「申请成功」这个动作上报到我们的行为库，形成事件；
- 线索入库：只有官网的三处表单（联系我们、数据能力页、AI 成熟度自测）会把留资写进线索表。
问题就出在第三条：三条通路各写各的表，中间没有桥。于是同一个人，在行为库里是一串事件、在产品库里是一个已开通的账号、在官网线索表里是零行。销售看到的是半张表，市场看到的是另一张表。
边界先说清楚，避免过度解读：① 该访客的 IP 段是境外地址，我们无法确认他是外部客户还是自家用代理做测试；② 我们只能看到官网这一侧的线索表，产品端是否另有申请记录，我们这里看不到。但这两条都不影响本文的判断——「申请成功」和「拿到线索」是两件事，中间必须有一根显式的桥；没有桥，转化就等于没发生。
那天下午的 18 分钟里发生了什么
我们不写排查流水账，只把行为库里的原始时间线摆出来（全部可复算）：
| 时间 | 事件 | 含义 |
|---|---|---|
| 14:24:42 | page_view | 同一 IP 段的另一位访客进入产品页，随后 8 分钟内连续浏览官网首页、服务体系、轻服务、数据能力、区域业务、客户案例、内容中心、开放能力共 8 个页面（10 次页面浏览，最后一次 14:32:46） |
| 14:24:50 | page_view + demo_apply_success | 本文的主角进入产品页并提交申请，载荷 repeat=false（首次申请） |
| 14:25:20 | demo_apply_success | 30 秒后第二次申请成功，载荷 repeat=true（同一访客重复提交） |
| 14:25:35 | login_success | 用演示账号登录成功（方式为 demo 体验账号） |
| 14:43:19 | ppt_done | 生成 PPT 完成——产品闭环走到最后一步 |
| 合计 | 5 个事件 | 从申请到拿到 PPT，18 分 29 秒 |
从产品的角度看，这是一次相当完整的体验转化：申请 → 登录 → 产出，三步都走通了，没有报错、没有中断。而两个访客在同一分钟到达、一位进了产品、一位把官网读了 8 个页面，这不像误触，更像一次有目的的考察。
真正值得写下来的不是他做了什么，而是我们记下了什么、又漏下了什么。
三条通路，只有一条通向我们看的表
这是本文的核心：同一个人的同一个动作，在三条链路上留下了三种不同状态的痕迹。
| 通路 | 由谁写入 | 写进哪张表 | 我们（官网侧）能不能看到 | 这次有没有留下痕迹 |
|---|---|---|---|---|
| 申请提交 | 产品自己的服务 | 产品自己的数据库 | ❌ 看不到 | ✅ 有（体验账号已开出） |
| 行为埋点 | 站点的行为上报接口 | 行为库（事件表） | ✅ 看得到 | ✅ 有，5 个事件 |
| 线索入库 | 官网三处留资表单 | 线索表 | ✅ 看得到 | ❌ 零记录 |
关键在第三行：访客点上「申请」的那一刻，前两条通路同时启动，第三条通路不会启动——因为线索入库的触发条件是「填官网表单」，而不是「申请体验账号」。这两件事在页面上看起来是同一个动作，在系统里却是两个完全没有交集的入口。
这里有一个可以自证的细节：产品的申请逻辑是先调申请接口、拿到成功响应之后，才上报「申请成功」埋点。也就是说，我们能在行为库里看到他两次「申请成功」，这件事本身就已经证明——申请接口返回的是成功，不是失败。所以这不是一次「提交失败」，而是一次「成功被记在了另一张表上」。
两者的处置方式完全不同：提交失败要修链路，记录分家要修口径与关联键。看到「线索为 0」就去排查接口，会白跑一趟。
这笔账：6 次申请成功，3 条申请来源线索
把两条通路的历史记录并排放在一起，事情就很清楚了：
| 项目 | 数量 | 说明 |
|---|---|---|
| 「申请成功」事件累计上报 | 6 次 | 09-19 三次连发（重复提交）、09-28 一次、10-11 两次 |
| 线索表中来源为申请表单的记录 | 3 条 | 最新一条停在 09-28 |
| 其中能一一对上的 | 1 次 | 09-28：线索写入 01:31:21，事件上报 01:31:35，相差 14 秒 |
| 10-11 的两次申请 | 0 条线索 | 只有事件，没有对应线索记录 |
这里要主动交代口径：6 和 3 都只是「几个」级别的数字，本文不据此计算任何比率。分母太小，算出来的百分比每次都会变。我们内部的规矩是：到达数不足 100 时只报绝对数、不报比例。贴这张表的原因只有一个——它能证明两条通路之间没有稳定的桥，能对上属于偶然。
顺带给出近 7 天（10-07 至今）的官网外部真人口径，让读者知道这不是孤例而是常态：48 位外部访客、157 个事件，其中 151 个是页面浏览（96%）；转化类动作只有 6 个，而这 6 个里有 4 个来自本文这位访客。换句话说，一周里真正发生转化的机会只有一次，而这一次我们没有把它记进表里。
同样的事，在企业自己的系统里每天都在发生
把视角换到读者自己的公司：一个客户从产生兴趣到签单，同样会被记在三套互不相识的系统里，也很少有人真的对过账。
| 系统 | 它记的是什么 | 常见状态 |
|---|---|---|
| 官网 / 小程序 / 表单 | 谁提交了信息 | 通常是唯一被当作「线索」的口径 |
| 企微 / 客服工具 | 谁被谁加了、聊了什么 | 有沟通记录，但没有转化标签 |
| CRM | 谁在跟、跟到哪一步 | 靠人手补录，漏录率无从得知 |
由此派生出三个典型断点，每一个都可以当天自查：
- 同一个动作，两个入口。填表单和注册试用是两套入口，只打通了一套——就是本文这种情况。
- 同一个客户，三个身份。表单留手机号、企微留微信号、产品注册留邮箱，谁也不是谁的主键，事后无法合并。
- 同一张报表，两套口径。市场报「提交量」、销售报「商机量」，两个数字从来对不上，因为定义本就不同。
判断只需一句话：你上一次把「同一笔转化在三套系统里的状态」并排打印出来，是什么时候？如果答案是「从来没有」，那么「转化率低」这个结论大概率是错的——不是没有转化，是转化看不见。
我们做的三件事（都不是改页面）
这类问题的常见反应是去改页面、改文案、加弹窗。我们没有这么做，因为这次断的不是页面，是两套系统之间的记账。落地的是三件更便宜的事：
| # | 动作 | 状态 |
|---|---|---|
| 1 | 把对账做成可复跑的脚本：并排打印「申请成功事件数」与「申请来源线索数」，跑一次只需几秒；差值不为 0，必须当天给出解释 | ✅ 已完成，本文第 4 节那张表就是它跑出来的 |
| 2 | 把口径写进报表规范：任何「转化」数字后面必须注明它落在哪张表；没有落进可跟进的那张表的，一律标注为「未落表」，不得与线索数混算 | ✅ 已写入内部运营规范 |
| 3 | 打通写入本身：让申请动作把访客标识、时间、来源写进线索侧 | ⏳ 待产品侧排期——这需要改一行代码，我们选择先上对账、再改写入，因为对账立刻可用，改代码要等排期 |
第 3 条特意标成「待排期」而不是「已完成」。数据类工作最容易犯的错就是把「发现问题」当成「解决问题」——我们不愿意在文章里把没做的事写成做了。
一张自查清单：20 分钟查清你的转化落在哪张表
这套动作不依赖任何工具，用一张 Excel 就能做完，建议按顺序走：
| 步骤 | 做什么 | 通过标准 |
|---|---|---|
| 1 | 列出你认可的「转化」动作清单（提交表单、加企微、注册、申请试用） | 每个动作都能说清「谁在记」 |
| 2 | 每个动作找到它真正写入的系统与表 | 不存在「只在页面上弹了成功提示」的动作 |
| 3 | 检查每条记录有没有可关联的主键（手机号 / 访客标识 / 客户编号） | 至少有一个全链路通用的字段 |
| 4 | 并排打印最近 30 天：动作次数 vs 表里记录条数 | 差值能被解释，或为 0 |
| 5 | 把第 4 步变成每周固定动作 | 有脚本或固定责任人可复跑，不用每次重新找人 |
最后一句提醒：第 2 步过不了的动作，先别谈转化率优化。分母本身就没记全的时候，优化只会让报表更精确地错下去。
微信内识别二维码分享此文
