实测｜申请链路 12 秒走通、5 个事件全部落库：
卡住的不是页面，是「入库之后没人接」

先说结论：链路通到「入库」为止

上一轮我们把 29 篇文章的承接链路摊开算，发现读者读完就走、内容之间不互链。这一轮换个方向：假设人已经来了、也愿意留联系方式，我们接得住吗？这个问题不能靠看报表回答，只能自己走一遍。

先说结论：从开放能力页点「申请 API Key」，到线索落进数据库，这条路在技术上已经通了——两次点击到表单、6 个字段、提交返回成功、5 个行为事件全部上报、线索里连上一页来源都记下了、全程 12.3 秒、前端 0 报错。真正卡住的不是页面，是「入库之后」：没有任何人在被通知，也没有任何字段记录「有没有回」。所以转化的最后一步不是「提交成功」，而是「有人第一次响应」——这一步，我们一直是靠人记得。

口径先说清楚：行为数据来自官网自建埋点库，统计窗口 2026-09-18 至 2026-10-21，已剔除自家 IP 段与程序化访问，按访客去重；实测时间 2026-10-21 上午，测试数据（1 条线索 + 5 条事件）核对完即删，不进入任何业务口径。全文所有分组分母都远小于 100，只报绝对数，比例仅作方向参考。

我们真走了一遍：两次点击、6 个字段、12.3 秒

选这条路径是因为它在数据里最值得看：开放能力页是外部访客最集中的落地页之一（34 位外部访客、64 次浏览），正文有 10 处「申请」字样、3 个申请入口；它也是唯一一个「来访者目的很明确」的页面——他不是来读文章的，他是来要东西的。所以在这里掉人，最不该。

三个细节值得写在纸上：

① 点两次才到表单。第一次是页内锚点，落在只有两行字的区块上（「立即申请 API Key」「免费额度 · 申请制」，整块高度约 60px），第二次才真正跳到表单页。这不算错，但它把一次意图拆成了两次点击，中间那一下的转化我们从来没测过——因为这些入口一个埋点都没有。

② 申请 Key 的人，落的是一张咨询表。表单记录的来源是「咨询表单」，字段是姓名、手机、公司、行业、关注方向、需求描述——没有任何一个字段在问「你要接哪个接口、要多少额度、用来做什么」。客户以为自己在申请钥匙，实际填的是一张需求诊断表。这会导致两个后果：客户预期与实际不符；我们拿到线索后还得再问一轮才能判断该给什么。

③ 表单在首屏之外 1828px。在 1440×900 的桌面视口里，点进来第一眼看不到表单。对刚读完一篇文章、被指过来的人，这是一段需要主动往下滚的距离。

另外说清一个口径：12.3 秒是机器填表的时间，不代表真人耗时。可以客观对比的只有步骤数——3 次点击、6 个字段、1 次勾选。真人的耗时我们测不出来，因为表单页没有停留时长与放弃埋点。

提交那一秒，数据里到底发生了什么

提交之后我去查库，5 条事件一条不少：

这里有个我们差点写错的插曲：第一次用浏览器网络面板看，一条上报都没有。差点得出「埋点失效」的结论——实际上埋点是批量排队、页面隐藏或卸载时用 beacon 补发的，网络面板抓不到不代表没上报。去库里一查，5 条全在。教训：判断埋点有没有生效，唯一可信的是数据库，不是浏览器面板。

线索行本身也比预想的完整：来源是「咨询表单」，来源页记了 /contact.html，上一页记了开放能力页，访客编号有值。也就是说——这条线索能回溯到他是从哪个页面来的。这是我们第一次能把「人从哪来」和「他留了什么」对上。

但把全库拉开看，画风就变了：

还有一个必须写出来的发现，因为它会让上面所有数字失真：通过产品侧「申请 Demo」入口进来的两条线索，记录里的浏览器标识是服务器端的脚本、网段是我们自己的。原因是产品侧转发时用了自己的进程去请求，把访客的标识覆盖掉了。后果很具体：一条真实的外部客户线索，在数据里长得和自家测试数据一模一样——按「剔除自家 IP」的口径过滤时，它会被当成自家剔掉。我们这次之所以能发现，是因为对比了线索表和事件表才发现对不上。

入库之后：三件只有人能做、而没人被安排的事

技术链路走通之后，剩下的问题全部落在「人」这一侧。三处，每一处都能在代码或字段里核实：

这三件事共同造成一个结果：我们所有的自动化都做到了「入库」，然后就停了。入库之后的每一步——发现、判断、联系、记录——都需要一个人主动想起来。而人会不会想起来，取决于当日忙不忙。这就是为什么「连续三周零线索」和「有人在 9 月 23 日填了一半就走」这两个事实可以同时存在：不是没人有兴趣，是兴趣落地的那一刻没有东西接住。

有一点务必说清楚，否则容易变成自我安慰：把「入库之后」修好，不会让流量变多。34 位落地访客只有 2 位走到表单，入口那一层本来就窄（下一节）。但两者的成本差得远——修入库之后是几小时的事，且一旦真有人来，立刻生效；而把落地页从 5.9% 改到 15%，要改文案、改版式、加埋点、跑一个月才有结论。在只有几十位访客的量级上，先修确定性高的那一头。

入口那一层：34 位落地访客，只有 2 位走到表单

落地页到表单之间还有一段路，数据是这样的：

两件事同时成立：一是「要东西」的意愿真实存在——6 位直接去了技能包下载页，是走向申请表单人数的 3 倍；二是申请这个动作的转化确实低——34 位里只有 2 位走向表单页（5.9%），而到了表单页的人里，外部真人只有 1 次开始填写、0 次提交。

还有一个不能忽略的结构性事实：这 34 位里 29 位（85.3%）在微信内置浏览器里。也就是说，他们绝大多数是刚读完一篇公众号文章、点进来看「开放能力」的读者。对他们来说，此刻最想要的是「先拿走点什么」，而不是「填一张需求诊断表等 1 个工作日」。6 位去下载、2 位去申请表——这个比例本身就是客户的答案。

另外补一个时间线：10 月 15 日之后到今天，这个页面连续 6 天零到访。而同期公众号没有新发文。上一轮我们已经确认「微信内新访客会在停止发文当周归零」——这句话在落地页上也同样成立。所以现阶段把「落地页改版」排在第一优先是错配：分母还没有稳定供给。

把最后一米接管：三件当天就能做的事

按「今天能不能做完」排序，三件，每件都有可验收的口径：

顺手还能做两件小事，成本很低：给开放能力页的申请入口、文档与技能下载按钮补上点击埋点（我们已经补好，等上线），这样「哪一处申请按钮真被点」才有答案；把「申请 API Key」的落地页文案改成「申请开通 · 需人工审核」，让客户预期与那张咨询表对齐。

最后是一条口径纪律，比上面三件都重要：以后谈转化，必须先说清「在哪张表里算」。埋点里的「提交成功」、线索表里的记录、以及产品侧申请产生的事件，是三张不同的表、三条不同的通路——看到申请事件没有线索，不要去查接口（接口是通的），要修的是口径与关联键。分母不到 100 的时候，只报绝对数。