延后收集优于一次收齐
别名: 延后收集 · 渐进披露信息 · just-in-time data · deferred fields
概念解释
当前任务还不消费的数据，不必在这次提交里收齐。延后收集把问的时机挪到真正用得上的那一步：先完成注册再问地址，先下单再问发票，先用核心功能再问公司规模。它不是把同一张长表拆成多步——多步仍是一次收齐，只是分页。也不是因为说不清用途而删除；用途在未来某刻确实存在，只是不是现在。一屏看见多少框，管的是当前视口的密度，不管问的日历。
机制
人愿意给的信息量随互惠已经发生多少上升。注册当下产品还什么都没给，问公司规模是单方面索取；用过一周、要开具发票时再问抬头，索取绑在一个刚出现的目标上。第二层是未使用数据的腐坏：提前收来的地址、职级、兴趣在真正被消费时已经过期，等于付了一次放弃成本，还要再付一次更正成本。延后把放弃成本挪到转化已经发生之后，那时离开损失的是附加功能而不是主任务。延后失败的典型做法是「先跳过」但仍把字段留在主路径上闪烁——那是推迟几秒，不是推迟到消费点。消费点必须是一个真实的界面：开票、配送、报销，而不是「资料完整度 80%」这种内部指标。
怎么研究
把同一组非必要字段做成「注册时全收」「首次使用相关功能时再问」「永远不在主路径出现」。看主任务完成率与后续功能的补全率。
自变量：询问时机（任务开始 / 消费点 / 从不）、跳过是否把字段留在主路径。 因变量：主任务完成率、延后那一项在消费点的完成率、过期数据被更正的次数、因资料不全而在消费点卡住的比率。
实验室很难等到「一周后开票」。要用产品里真实的消费事件做漏斗，或在可用性测试里把消费点做成下一任务。不要把分步向导的转化提升算成延后——分步没有改变「这次会话要收齐」。
边界
风控和法定义务在任务开始就必须有的数据（实名、年龄门槛）不能延后到消费点，否则消费点会变成无法完成的死胡同。延后到的界面若本身已经很重（结账），再叠加当初省下的字段，会把放弃从注册挪到支付，净完成可能不升。跨设备时，延后收集依赖账号；游客会话没有地方挂延后项，要么在升级为账号时收，要么接受永不上收。
怎么落地
- 列出每个字段的第一次真实消费点；消费点不在当前任务里的，从当前表拿掉，挂到那个界面再问。
- 「稍后再说」必须离开主路径，不要在下一屏用进度条把同一项再推出来。
- 在消费点询问时说明为什么现在要，并允许用当时的值，而不是强迫沿用可能已过期的早先填写。
- 验证：注册表拿掉地址和发票抬头后，注册完成率是否上升；在第一次开票和第一次配送时这两项的完成率是否仍够用。若支付页被这两项压垮，说明延后的落点选错了，再找更早或更轻的消费点，而不是退回一次收齐。