注册表单：六个字段砍到三个，与 2.8 个百分点的提交率

注册表单不是收集信息的地方，是用户第一次为你的产品付出成本的地方。

一、六个字段的那一版

2026 年 3 月，林澈的注册表单有六个字段：邮箱、密码、姓名、公司名、手机号、邀请码。设计时的理由很统一——「以后都要用」。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

上线三个月后回看，三个字段从第一天起就没被真正用过：公司名大部分填「无」或产品名，手机号只有 7.4% 的人填，邀请码在内测结束后就形同虚设。

他把 1,240 次「开始填写」与 1,180 次提交之间的 60 人拆开，发现 41 人停在手机号或公司名。手机号要等短信验证码，公司名则让人犹豫：个人用户不知道该填什么。

字段不是信息收集，是一次交易。 你向用户要一条信息，用户向你要一个理由；这个理由必须是「现在就要用」，不是「以后可能用」。

他后来把六个字段按「谁在用」分类：邮箱、密码、姓名是产品自己在用；公司名、手机号、邀请码是「想象中的需求」在用。

这个分类很粗糙，但足够做第一轮决定：凡是没人真正读取的字段，先别问。

二、每个字段要付两次钱

第一次钱在提交时付：字段越多，放弃越多。第二次钱在提交之后付：每个字段都要校验、存储、解释、清理。

看这张表会发现：字段的维护成本通常高于转化成本。 少一个字段，省下的是每月几十人 × 十几秒；多一个字段，留下的是永久的校验分支和一类新工单。

维护成本还有一个特点：它按月发生，而转化损失是一次性的。一个人因为手机号放弃，你只损失他一次；但手机号字段留下的短信通道与失败工单，会跟着产品一直存在。

这也是「以后都要用」最危险的地方：它把一次确定的转化损失，换成了一项不确定的维护负担，而后者不会出现在任何报表里。

还有一种隐性成本：字段会进入数据库，进入导出文件，进入隐私政策的数据清单。每多一个字段，这三处都要跟着改一次。

所以每次评审表单，他都先问一句：这个字段，谁在读？如果答不出具体功能，它就是在为「想象中的需求」收集数据，而不是为产品收集数据。

这句问法比「这个字段有用吗」更有效，因为后者总能找到理由，前者必须指名道姓。

三、六个砍到三个

砍字段不是凭感觉，用三条判据。

三条判据都过的是邮箱与密码。姓名留下，但设为可选——它只影响称呼，不影响功能。

剩下三个字段不是删除，而是后置：公司名在创建第一个工作区时问，手机号在开启两步验证时问，邀请码改成注册链接里的参数，点进来就自动带上。

后置的关键是「在需要它的那一刻问」。 激活之后再问公司名，用户已经知道产品能做什么，回答的意愿反而更高；注册时问，他连这个字段用来干什么都不知道。

后置还有一个副作用：字段从必填变成可填，校验逻辑也会简化。必填字段的每一个错误分支都要写文案、都要测试，可填字段不需要。

第三条判据最容易被误用。有人说「公司名可以后置到付费时」，但企业客户在注册时就想确认这个产品支不支持公司主体；后置的时机要跟着「用户什么时候需要这个信息」走，不是跟着你的开发顺序走。

他给自己定了一条硬规则：新增字段必须同时回答三个问题——哪个功能会读它、不填会坏什么、能不能等到激活后再问。三个问题答不全，就不加。

四、一次对照实验与 34 个提交

他把两个版本各跑了一个月，用同一批渠道导流，避免渠道结构影响结果。

34 个提交按下游转化折算：34 × 95.8%（验证完成）× 93.9%（首登）× 9.0%（付费）= 2.75 个付费/月，按 19 美元/月计是 52.25 美元 MRR。

必须说清楚局限：1,240 的样本、34 人的差异，统计上并不显著。真正的依据不是这 2.8 个百分点，而是「少三个字段不会带来新的支持成本」——这个结论不依赖显著性。

小样本实验的价值在排除坏方案，不在证明好方案。 如果 B 版本让工单上升，哪怕提交率更高也该退回去；实验同时要看转化与成本。

他在实验期间还看了一个次要指标：表单平均填写时长。B 版本从 96 秒降到 78 秒，少了 18 秒；速度本身不产生收入，但它减少了中途被打断后不再回来的概率。

这类次要指标不能当结论，只能当解释。主结论仍然是提交率与工单量，时长只是说明「为什么变了」。

实验还有一个容易忽略的细节：两个版本必须用同一批渠道、同一段时间。他中途有一次把 B 版本放到新渠道的落地页上跑，两周的数据直接作废——新渠道的用户本来就更愿意填表，差异根本不是字段造成的。

复算：
A 版本提交率：1,146 ÷ 1,240 = 92.4%
B 版本提交率：1,180 ÷ 1,240 = 95.2%
差值：1,180 − 1,146 = 34；34 ÷ 1,240 = 2.8pp
下游折算：34 × 0.958 = 32.57 个验证
          32.57 × 0.939 = 30.58 个首登
          30.58 × 0.090 = 2.75 个付费/月
MRR 增量：2.75 × 19 = 52.25 美元/月
放弃集中度：60 人中 41 人停在手机号或公司名 → 41 ÷ 60 = 68.3%

注意最后一行：60 个放弃里有 68.3% 集中在两个字段上。砍字段要砍「集中放弃」的，而不是砍「看起来最不重要」的。

五、行动清单与复算验收

• 列出当前表单的每个字段，写下它在哪个环节被使用。
• 给每个字段标一次「提交成本」与「维护成本」。
• 用三条判据过一遍：现在就要用、不可恢复、可以后置。
• 把可后置字段移到激活之后，并写清触发时机。
• 统计放弃集中在哪几个字段，优先砍集中的。
• 检查错误提示是否说清「改哪里」，而不是「格式不对」。
• 对照实验同时看提交率与工单量，只看一个会误判。
• 记录实验样本量，样本太小就只用来排除坏方案。

验收标准：任取一个字段，都能说出它为什么现在要问、不问会坏什么、后置到哪一步。

前四条是「把字段砍对」，后四条是「把砍完的效果验证清楚」。如果只有一小时，先做第五条：放弃集中的地方，就是最该动的地方。

使用边界与实操验收

92.4% 与 95.2% 是同一产品的两个版本。 换一个产品、换一批流量，绝对值会变；判据不变。

字段数与转化不是线性关系。 从 6 个砍到 3 个提升 2.8pp，从 3 个砍到 1 个可能只提升 0.3pp；每个字段的边际成本不同。

有些字段不能后置。 涉及计费、合规或唯一身份的字段必须在注册时拿到，否则后面补不回来。

后置字段要有人接。 你把公司名挪到激活之后，就要在激活流程里真的问一次；挪了不问，等于删了。

字段顺序也有影响。 同样三个字段，把密码放在最后一位，提交率会略高；用户先看到简单字段，更容易一路填完。

错误提示要指向位置。 「格式不对」会让用户重看整张表；「邮箱缺少 @ 后面的部分」只让他改一处。

实验结论要写下来。 半年后换一个人维护表单，没有记录就会把字段加回去。

关键参考与核验范围

• web.dev：登录表单最佳实践 ：用于核对字段、自动填充与错误提示的基本要求。
• W3C WAI：表单可用性 ：用于核对标签、错误识别与必填提示的无障碍写法。
• OWASP 认证速查表 ：用于核对注册环节不可省略的安全约束。

以上链接于 2026-10-27 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-27。

范围上只讨论注册表单的字段取舍与提交率，不讨论身份验证协议、风控策略与反欺诈实现。

系列导航

• 上一篇：账号是一套流程，不是一张表：五段漏斗、七个节点与每月 26.9 小时工单
• 下一篇：登录方式：密码、魔法链接与 OAuth 的三条路，和 3.0% 的企业邮箱拦截
• 回到目录：一个人的账号体系：一百零八张找回工单、三十天冷静期与 4.2% 的验证流失
• 相关阅读：一个人把产品做得像样：品牌、视觉识别与设计系统