每天新增一万注册用户，为什么营收就是不涨

开篇

订阅者，上个月云部署平台Railway的工程博客上发布了一篇很有意思的文章。标题就很挑衅：“Kill your onboarding（干掉你的引导流程）”。我最近做副业项目时搭建了一个金融产品分析网站，当时第一次用了Railway。其实Vercel和Supabase本来就够用了。最近也曾想过要不要用用异常检测工具Sentry，但又觉得没那个必要，后来因为成本问题第一次用了Railway，结果发现比想象中好用不少。而这项服务不仅在技术上比我预想的更好，其中的销售和营销案例也很有意思。

**Railway是一项每天有超过1万件注册涌入的服务。**截至2026年4月，累计注册用户达290万。但打开内部分析一看，他们已经识别出符合销售ICP¹的21,000个企业账户，却只联系了其中不到1%。先说结论：这不是邮件写得不好，而是发送对象弄错了，而解法却简单得惊人。

🛢️ 石油早就在那了。企业收集了数据却不用

PLG²企业存在一种结构性困境。为了把用户体验做到极致，注册时什么都不问，结果就是完全无法区分谁是拿来当兴趣爱好用的个人用户，谁是打算搭建生产级基础设施的企业团队。

也就是说，像我这样出于个人兴趣做网站的人有，把它当作公司级项目使用的人也有，而对Railway来说，理所当然要抓住B2B客户。Railway正好处于这种状态。它以极其顺滑的引导流程自豪——只需一个GitHub账号，几秒钟就能完成部署——但故意不去问“您属于哪家公司？”或者“您有多少名工程师？”这类问题。他们甚至明确表示，对如今流行的Granola式引导流程——“注册后立刻连续追问职务、团队规模、使用目的”——“我们是刻意拒绝的”。通常这类问题会被问很多（很多人应该都“中招”过吧？）。

问题在于代价。**由1名AE（销售负责人）、2名SE（解决方案工程师）组成的超小型销售团队，要面对21,000个潜在企业账户，却完全无从判断谁该优先。**Railway创始人Cooper这样描述：

“油田早就在那儿了，只是没人去钻探而已。”

有意思的是，Railway并不是没有数据。他们用PostHog多年来一直在收集产品事件，内部系统backboard里详细记录着每个项目的服务配置、实例规模、数据库连接乃至部署结果。这个模式，是不是很眼熟？问题不是“数据不足”，而是没有对已经积累的数据提出问题。

这不是Railway独有的问题。截至2026年，采用PLG模式的企业已达到全体的58%，但引入基于产品使用数据评估线索的PQL³框架的企业只有25%。也就是说，剩下的75%虽然握有用户行为数据，却仍然只依赖营销漏斗。

🔍 没有哪个兴趣型开发者会去下载SOC 2报告。信号筛选的艺术

Railway的解决方案工程师Des Conlon采取的方法出人意料地经典。他没有跑机器学习模型，而是把每一个行为维度都拿出来逐一计算“企业账户相对于兴趣账户的发生比率”。他在一个叫Hex的分析工具上搭建dbt模型，反复跑数十个GROUP BY查询，筛选候选信号。

这里有一步很关键的棋：他果断舍弃了表面上预测力最强的信号。

比如是否使用SSO，几乎能100%判定“这个账户是不是企业账户”，但SSO是只有已经完成销售对话的客户才能启用的功能。这不过是把已经知道的事情再告诉自己一遍而已。这在数据分析中通常被称为标签泄漏（label leakage）⁴——答案混入了输入数据的现象。Conlon把这称为“1等于1”，意思是验证一个不言自明的事实毫无意义。

最终留下的规则只有一条：只承认那些“兴趣型开发者理论上可以做，但实际上几乎不会做”的行为才算作信号。最终留下的五项信号很有意思。

• 下载Trust Center文档：最强的概率性信号。兴趣型开发者没有理由去下载SOC 2报告。基于该信号联系客户，回复率约达到50%
• 座位数及其增长趋势：Railway去年取消了按座位计费之后，这项指标反而成了纯粹的团队规模信号
• 重设凭证：这是有内部安全政策或密码更换周期的组织的行为模式
• 连接外部数据库：真正连接实际数据的速度，正是区分兴趣与业务用途的关键点
• 特定的部署失败模式：不是“失败一次”，而是“与生产级问题反复较量”的模式 他们将这五项信号按提升比率（uplift ratio）加权求和，得出分数。既不是梯度提升，也不是随机森林，而是线性加权求和。为什么要做得这么简单？

原因有两个。第一，行为数据大多只有一天的量，复杂模型必然过拟合。第二，依据这个分数采取行动的，只是一位AE。“Trust doc + 8个座位 + 数据库连接”这样的理由可以立刻理解，但仅凭模型吐出的“0.87分”，一旦判断出错也无从察觉。用Conlon的话说：“一个可读的模型，几乎总是胜过一个精度更高但看不懂的模型。”

📧 别再滴灌营销了，改用触发式。邮件的再发明

这样算出的分数分成两条路径。中等分数走Customer.io的自动邮件，高分则走人工直接联系。

而这套自动邮件的结构，和原来的引导邮件序列完全不同。不再是“注册后第1天、第3天、第7天”这种基于时间的滴灌式，而是在特定行为发生的那一刻发送的事件触发式。

发送条件也很苛刻，必须同时满足两个条件：

• 该事件要与账户是企业账户的可能性相关
• 该事件发生的时刻，恰好是用户略微卡住或正在做出重要决定的节点 而邮件内容不是约会议。也不是推销企业版套餐。邮件以真实销售负责人的名义发出，内容大致是：“看您好像在做这样的事情，有什么可以帮忙的吗？”

结果很戏剧性。原来通用型引导邮件的打开率是27%，而按触发条件区分后打开率升到了50%到70%的区间。第一天发送300到400封，实际收到了2封回信。

当然，这个数字背后有重要背景。Apple Mail的隐私保护功能可能会抬高打开率，而且本来就是在最恰当的时机发给了最可能感兴趣的人，选择偏差本身就很大。Railway自己也承认这一点，并表示正在设计A/B测试。

但这个方向本身很有意义。大多数PLG邮件营销指南都会推荐“基于行为的触发”，但Railway不同的地方在于，他们在触发条件本身上又叠加了一层ICP过滤。不是简单的“给连接了数据库的用户发邮件”，而是**“连接了数据库，同时又极有可能是企业账户的用户，才发”这种双重条件。正是这个差异，把发送对象从每天数千人压缩到了300到400人，而这种压缩本身反而造就了质量。**

Oswarld视角

老实说，我第一次看到这个案例时忍不住拍案叫绝。因为它把我在制定GTM战略时反复见过的、最常见的失败模式赤裸裸地展现了出来。

这个模式是这样的：企业增长放缓时，最先动手的往往是邮件文案或落地页设计，因为这些看得见。但真正出问题的地方，其实是“在跟谁说话”这层定位（targeting）。像Railway这样每天涌入一万人，但21,000个企业客户里只接触了1%的情况下，文案改得再多也没用。把完美的信息发给错的人，就是彻头彻尾的浪费。

而在这个案例里，我最关注的另有其事。**Conlon在Looker时期（后来被Google收购）遇到的问题，和在Railway遇到的问题，完美地形成了对称。在Looker，客户有合理的问题，但没有能回答这些问题的数据基础设施；在Railway，基础设施都齐备了，却没人去提问。两个情况都不是“因为没有数据”。**缺的是数据与提问之间的连接。

**今年“GTM工程师（GTM Engineer）”这个职位的招聘启事已经超过3,000份，这绝非偶然。销售团队不再凭直觉去猜“像企业的信号”，而是去计算提升比率、过滤标签泄漏、构建可读的评分体系——这一整套流程，正是眼下身价上涨最快的能力。**而这种能力不是会被AI取代的东西，而是在AI时代反而变得更重要的能力。因为无论模型多好，决定往里输入哪些信号的，永远是人。

国内GTM相关岗位依然莫名其妙地不受欢迎，我总觉得早晚会迎来一波热潮……于是坚持写着这篇专栏。毕竟到头来还是得赚钱。总不能一直只卖梦想吧……

结语

总结一下：

• PLG真正的瓶颈不是数据缺失，而是数据未被利用。75%的PLG企业明明拥有产品行为数据，却没用在线索评估上
• 精密的AI模型，比不过一个可读的简单评分体系在实战中好用。执行者看不懂的模型，一旦出错就没法纠正
• 邮件的效果不是文案决定的，而是时机与对象决定的。仅仅改变“发给谁、什么时候发”，打开率就可能翻倍以上 下次检查我们组织的引导邮件表现时，在动手改文案之前，请先确认一件事：现在这封邮件，真的发给了应该发的人吗？

订阅者所在的组织，是否已经把注册后的行为数据接入了销售流程？还是仍停留在“通用欢迎邮件”阶段？欢迎在评论区告诉我。

参考资料与延伸阅读

核心来源

• Des Conlon，“Kill your onboarding: selling to 10,000+ new users a day”，Railway Engineering Blog，2026年5月6日。：从从业者视角，完整讲述了从PLG到销售转化的整个过程

背景知识

• McKinsey，“From product-led growth to product-led sales: Beyond the PLG hype”，2023年。：这是麦肯锡在战略层面梳理从PLG向PLS（Product-Led Sales）转型的报告
• SaaS Mag，“PLG in 2026: Product-Led Growth Evolves Into Full-Stack GTM”，2026年4月23日。：这是一篇整理2026年PLG格局的最新指南，包含Cursor实现20亿美元ARR的案例。文中引用数据显示，引入PQL的企业转化率高出3倍
• Apollo，“Who Is A GTM Engineer? Revenue Systems Builder”，2026年2月24日。：用数据梳理了GTM工程师这一职位的定义与市场增长态势，引用Bloomberry数据称招聘启事较2025年增长205%

作者安光涉是世宗大学经营学教授，也是 OBF（Oswarld Boutique Consulting Firm）首席顾问。他在大学教授经营数据管理、商业分析等统计与数据分析课程，同时在产业现场负责 GTM 与人工智能战略咨询，设计技术与商业的连接方式。他曾发表关于 AI 对话系统记忆架构（HEMA）的学术论文，并运营每日策展全球 AI 论文的 Daily Arxiv 项目。他毕业于高丽大学技术经营专业研究生院与 KMBA，著有《把思考交出去的人：Homo Brainless》。

注释

1. ICP（Ideal Customer Profile）：理想客户画像。定义“什么样的组织最适合使用我们的产品”的标准，通常综合公司规模、行业、地区、融资阶段等因素构成。 ↩

2. PLG（Product-Led Growth）：产品驱动增长。不依靠销售人员，而是通过产品自身的使用体验来获取和转化客户的策略。Slack、Notion、Figma等是代表性案例。 ↩

3. PQL（Product Qualified Lead）：基于产品使用行为评估购买可能性的线索。与仅因下载了白皮书就被评估的MQL不同，PQL基于实际使用产品的经验，转化率高出2到3倍。 ↩

4. 标签泄漏（Label Leakage）：想要预测的答案本身混入了输入数据的现象。就像考题的答案写在试卷上一样，这样的模型在实战中完全没有用处。 ↩