获客是一本账，不是一次发布

发布日的数据证明那天有人看见了你，不证明你拥有了一条渠道。

一、发布日的幻觉

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

一位开发者做了一个浏览器扩展，功能是批量整理标签页。发布当天，他把链接发到三个社区，一天之内来了 400 次访问，30 个人装上并留下邮箱。他很兴奋，在日记里写下「渠道验证成功」。

第二周，访问 35 次；第三周，12 次；第四周，4 次。他以为是产品不行，于是花两个月重做了界面。重做之后他又发了一次，数据几乎一模一样：发布日冲高，然后归零。

问题不在产品。他从来没有建立渠道，只重复了三次事件。 事件的特征是「你推一下，它动一下」；渠道的特征是「你不推，它也在动」。区分这两件事，靠的不是感觉，是一本按周记的账。

二、四个数与四个分母

获客最常见的错误，是把四个不同层级的数字当成一个漏斗随口相乘。正确的做法是每一层单独记，并且每次只拿同一层的分子除以同一层的分母。

四个数之间的关系不是一条直线，而是四段各自独立的过程。曝光到访问取决于标题与场景匹配；访问到注册取决于落地页；注册到激活取决于产品本身。任何一段坏掉，表达出来的都是「获客不行」，但修的地方完全不同。

所以账本的最低要求是：每一行都写清这四个数，缺哪个就写「未记录」，不要用估算补齐。缺数据本身是一个结论——它说明这条渠道无法被判断。

三、渠道账本长什么样

一个人用的账本不需要工具，一张表就够。关键是按周、按渠道分行，不要按天，也不要合并渠道。

这张表能直接回答三个问题：这条渠道的成本是多少、它现在还在不在产出、它的转化率是哪一段坏掉的。

第三列开始才是判断依据。只看「访问」会高估社区，只看「激活」会低估目录站——目录站曝光少，但持续有人来；社区曝光大，但只在发布那一周。

3.1 一行只放一条渠道

把「社区」写成一行的账本没有用，因为 Hacker News、Reddit、V2EX 的规则、人群和衰减速度完全不同。合并之后，你既看不到哪条成立，也看不到哪条该停。

如果一次动作同时发到了五个地方，就记五行，每行只放这个来源带来的数据。做不到精确归因时，用不同的落地页路径或 UTM 参数区分（见第 08 篇），不要用「大概各占两成」估算。

四、每周 6 小时的预算

获客不是免费的，它消耗的是本来可以写代码的时间。所以第一件事不是选渠道，而是先算出自己每周能拿出多少小时。

「每条渠道 2 小时/周」不是行业标准，而是一个下限估计：写一条帖子、回评论、看数据、处理被删或被问的问题，加起来很少低于两小时。低于这个投入，渠道会自然衰减——不是因为你不想做，而是因为社区的注意力本来就按天计算。

复算：每周 6 小时，分给 3 条渠道是每条 2 小时，刚好到达维持下限；如果分成 4 条，每条 1.5 小时，低于下限，四周内通常会有一条先停更。这就是「一个人同时最多运营三条渠道」的算术来源，不是性格问题。

4.1 预算要写进日历

把「每周三晚上两小时写社区帖」写进日历，比写「今年要好好做推广」有用。获客最容易失败的方式不是做错，而是在赶功能的时候被无限期推迟，等到想起来的适合，账号已经被社区判定为长期潜水。

五、1 主 + 1 备 + 1 自有

三条渠道不是随便选三条，而是三种不同性质的位置：

主渠道和备渠道都寄生于别人的规则，随时可能因为一次改版、一次误判或一次账号问题归零。自有渠道的意义不是量大，而是在主渠道失灵的时候，你还剩一条能说话的路。

三者不要求同时开工。合理的顺序是：先用 4 周把主渠道跑通，再加备渠道，自有渠道从第一天就开始攒——因为它增长最慢，也最需要时间。

六、渠道「成立」的判据

本组统一用一条可打断的判据：

渠道成立 = 连续 4 周，每周至少 1 个完成激活的新用户，
          且期间没有因违规被删除、限流或封禁的记录。

三个条件缺一不可。只满足第一周不算；只有注册没有激活不算；被删过帖的账号即使还有流量，也不构成稳定来源。

第四行的情形最容易被误判成「渠道成立，只是这周忙」。判断方法很简单：回看那一周是否投入了 2 小时。没投入就不算中断，算主动放弃。

七、三种记账错误

错误一：只记总量。 「这个月来了 500 人」无法指导任何动作，因为不知道 500 人从哪来、哪一段在漏。

错误二：只记最好的一周。 用峰值代表渠道水平，下次按峰值做预算，结果每个月都完不成。

错误三：把老用户算成新增。 同一个用户从社区来一次、从邮件来一次，被记成两个新增。归因口径必须写死，见第 10 篇。

还有一种隐性的错误：把「有人点赞」当成「有人来」。 点赞是内容的表现，不是产品的数据。它可能说明话题好，也可能说明人群不对。中间还隔着访问、注册、激活三段。

八、行动清单与复算验收

• 建立一张按周、按渠道分行的表，字段固定为四数加成本。
• 用自己的日历算出每周可用于获客的小时数，除以 2，得到可维持的渠道上限。
• 选定一条主渠道，连续投入 4 周，不同时开三条。
• 从第一天开始记录自有渠道的订阅数，哪怕每周只增加 3 个。
• 第 4 周末按判据做一次「成立 / 未成立」的判断，并把结论写进下周计划。

复算：每周 6 小时对应 3 条渠道，是因为 6 ÷ 2 = 3，并且每条都达到 2 小时的维持下限；如果只做 1 条，每周会剩下 4 小时，可以投入内容生产而不是再开一条。发布日 400 访问、30 注册，注册率是 30 ÷ 400 = 7.5%；30 注册里 12 人激活，激活率是 12 ÷ 30 = 40%；这两个比例分母不同，不能合并成「3% 转化」再拿去和别的渠道比较。

使用边界与实操验收

这套账本适用于「有明确落地页和可观测注册事件」的产品。如果产品完全离线、没有账号系统，激活只能用可核实的行为替代（例如下载后主动回信），此时应把结论降级为「弱证据」，不要伪造比例。

验收标准只有一条：换一个人拿着这本账，能说出上周哪条渠道在产出、哪条在衰减、下周该把两小时投给谁。 说不出来，就是账记得不够细。

关键参考与核验范围

以下链接支持对应的规则；本组的四数口径、预算与成立判据均为方法演示，不构成营销建议。核验日期：2026-10-23。

• 中华人民共和国个人信息保护法 ：收集访问与注册数据、记录来源参数时，按可识别性、必要范围与告知义务核对。
• 中华人民共和国电子商务法 ：通过信息网络提供商品或服务时，经营者义务的适用范围需在收费与推广前确认。

平台（社区、目录站、应用市场）的具体规则页面在本次核验中无法访问，因此本文不引用条款原文，也不附链接。执行时请以平台当日规则为准。

系列导航

• 下一篇：十二条渠道的全景与打分
• 回到目录：一个人让产品被看见：十条获客路径
• 相关阅读：一个人的前 100 天 、独立开发者的平台寄生