完成度停滞不前时需要识别具体卡在哪一步
别名: 上手卡住 · 哪一步没做 · onboarding stall · drop-off step
概念解释
清单完成度停在 40% 或 3 / 5，本身不是诊断。要问的是哪一项没被勾、该项是没被点开、点开后失败，还是做完了系统没记账。停滞是分布，不是平均数。把停滞当成「用户不够积极」会催促整张清单；识别具体一步才能改那一步的入口、文案或外部依赖。这条是清单的测量与定位，不是进度怎么显示，也不是项该不该有价值。
机制
各项的成本结构不同：有的是一键，有的要等同事接受邀请，有的要去别的网站拿密钥。停滞会堆在成本最高或失败不可理解的那一项上，而不是均匀洒开。若不拆项，运营会给所有未完成的人发同一条「完成设置」的催促，已经卡在 OAuth 失败上的人收到的仍是总账，问题解决不了，催促变成噪音。定位还要分开「从未打开此项」和「打开后未完成」：前者是清单里找不到或不敢点，后者是流程内部失败。系统漏记（人已经连上邮箱，勾没打上）会制造假停滞，人反复做已经做过的事。所以完成度仪表盘若只有一个百分比，它在鼓励错误的干预。
怎么研究
按项做漏斗：展示、打开、成功、记账。对打开后失败的会话看错误类型；对从未打开的人看该项在清单里的位置和文案。
自变量：项的外部依赖、在清单中的次序、失败文案是否可行动。 因变量：每项的打开率和成功率、停滞时长、催促后是否仍停在同一项。
不要用总分完成率当唯一 KPI。实验室里外部依赖被研究者代劳，停滞会被低估。回访时问「卡在哪」要指向项的名字，不要问「上手难不难」。
边界
乱序清单里「没做的项」可能是有意跳过的低价值项，停滞不一定是失败；要结合该项对核心任务是否必需。团队空间里卡在「邀请成员」可能是组织政策禁止，不是界面失败。完成度因套餐墙停住，应标成获取问题，不要当成上手卡住去催促。清单被用户关掉之后，完成度不再更新，不要把关闭当成停滞。
怎么落地
- 为每一项分开记录展示、打开、成功；停滞报警按项触发，不要只看总分百分比。
- 对打开后失败的项提供该项内部的可行动错误，而不是回清单顶上一句「继续完成设置」。
- 核对记账：用真实已完成状态抽查勾选是否一致，假停滞先修记账。
- 验证：找出完成度不动超过一定会话数的账号，列出他们未勾的那一项。若干预仍是统一催促而不是改那一项，定位就没有进到产品里。