真正会被完整读完的产品更新邮件模板到底长什么样

一封真正会被读完的产品更新邮件，正是那种被发给了一个人，而这个人恰好就提出过邮件里所宣布的那个具体请求的邮件。除此之外的一切，都在和收件箱里剩下的所有内容争夺读者的注意力，而这样一场竞争，一条发布公告在大多数星期里都是会输掉的。仅仅这一个事实，就应该在任何一句具体的措辞被写下来之前，先决定这封邮件到底应该长成什么样子：到底是谁会收到它，以及这个人到底做了什么才会出现在这份名单上。

产品更新邮件到底是什么

它是一条消息，用来告诉已经在使用某个产品的现有用户，这个产品到底发生了什么变化。它一共有四种彼此不同的类型，而把它们全部当成同一份名单来对待，正是打开率不断下滑的原因。每一种类型都有各自不同的触发条件、不同的受众，以及不同的、可以被接受的发送频率。

大多数团队只会去构建第三种类型，把它发给所有人，然后得出产品更新邮件根本不管用这样的结论。而前两种类型，才真正承载了几乎全部的价值，因为读者早就已经有了一个在先的、真实存在的理由去关心这件事，而这封邮件正是在那个理由还依然鲜活的时候被送到的。

这里列出的四行内容全都是写给客户看的。销售团队、支持团队、客户成功团队同样也需要知道到底发布了什么，而且通常需要一种跟这四种完全不一样的形式；对内发布说明 讲解了这份文档到底该说些什么，以及它为什么必须比对外说明更早发出去。

邮件只是上线公告可以使用的多个渠道之一，并不是唯一的选择。该怎样发布一条新功能公告讲解了其他几种渠道，以及该根据这个功能实际的大小，在它们之间做出选择。

这份模板到底应该包含什么内容

按照这个顺序，一共六个模块。第一个模块，恰恰是通常最容易被遗漏的那一个，也正是真正在做事的那一个。

主题：  <到底发生了什么变化，用读者自己的语言来表述>

1. 你为什么会收到这封邮件
   "您在三月份曾经请求过 CSV 导出功能。"或者
   "您的集成正在调用 /v1/invoices，而这个接口将在 1 月 15
   日发生变化。"

2. 到底发生了什么变化
   一句话说清楚。现在多了什么新的可能性，或者现在到底
   坏了什么。

3. 你需要做什么
   多数情况下是"什么都不需要做"。请明确地把这一点说出来，
   而不是让它只是隐含在字里行间。

4. 在哪里可以看到
   一个指向体验日志记录的链接，而不是指向主页的链接。

5. 什么时候
   发布上线的具体日期，或者从什么时候开始生效。

6. 怎样取消订阅
   一次点击，并且立刻得到尊重。

第一个模块，正是一条真正的消息和一次泛泛的群发通知之间的区别。一个在第一句话里就被告知，这正是自己曾经亲自提出过的那个请求终于得到解决的读者，才会继续往下读。少了这一步，第二到第五个模块，无论文字写得多好，本质上都只是一份普通的新闻通讯而已。

请把整封邮件的篇幅控制在大约 150 个词以内。这封邮件本身只是一个指向那条体验日志记录的指针，而真正的细节，应该留在那条记录里。一封把整条记录原样复制过来的邮件，既不会给读者留下点击的理由，也不会给你留下任何信号，让你知道到底有没有人真正在乎这件事。

什么样的标题真正有效

请直接点出具体的变更内容，而不是笼统地提及这一次发布本身。“CSV 导出功能已经上线”要比”九月更新”更有效，因为前者是一个读者可以自行判断的具体事实，而后者只是一个空洞的容器。标题里的版本号，对某个 API 的调用方来说是有用的，但对其他所有人来说都只是噪音，这也是需要把受众区分开来的另一个理由。

请避免去主张一个读者根本没有同意过的好处。“您的报表现在变得更快了”这种说法，其实是在替读者的体验下结论；而”超过 10,000 行的报表现在会在一秒之内加载完成”这种说法，只是在客观地报告一个变更，然后把这件事到底重不重要的判断权，留给读者自己去决定。

应该在什么时候、发给谁

请在那件事情正式上线的那一刻，把定向通知逐一发给那些提出过这个请求的人。请在日期一旦确定下来之后就立即发出破坏性变更通知，并在临近那个日期时再发一次，而且只发给真正会受到影响的那些账户，而不是发给整份名单。只有当你积累了足够多的变更，多到读者如果不看摘要就真的会错过什么的时候，才应该发送摘要邮件，并且要让用户能够单独去订阅它。

那份你几乎永远都不应该使用的名单，就是”全体用户”。它会把一条本来非常具体的消息，硬生生变成一条泛泛而谈的消息，并且会训练用户去取消订阅。请按照你已经在记录的那些行为特征来划分受众：谁提出过这个请求、谁正在使用这个接口、谁正处于哪一个具体的方案之中。

发送这封邮件到底需不需要事先取得同意

对于现有客户来说，一条关于他们正在使用的某项服务的更新，通常和面向潜在客户的市场营销邮件，在法律层面上完全是两码事，而具体的答案，取决于这些用户身处何地，以及你在他们注册的时候到底告诉过他们什么。在欧盟，真正相关的问题是《GDPR》第 6 条当中的哪一项法律依据可以适用；而在美国，商业性质的消息则需要满足FTC 的 CAN-SPAM 合规指南中所规定的一系列具体要求。在实际操作层面，这两者的要求其实是一致的：说清楚你到底是谁，把目的讲明白，并且要让用户真正能够停止接收这些邮件。

无论具体依据是什么，都请在发送这个层面上，把事务性的邮件流和市场营销类的邮件流彻底分开。如果一位客户是因为一封破坏性变更通知和一份促销性质的摘要邮件共用了同一份名单而选择了取消订阅，那么这本身就已经是一个正在等待着自己爆发日期的客服事故了。

填好之后到底会是什么样子

定向通知，是价值最高的一种产品更新邮件，也恰恰是大多数团队从来都没有真正构建过的那一种。

主题：CSV 导出功能已经上线

Dana 你好，

你在三月份曾经请求过 CSV 导出功能。

它已经在今天早上正式上线了。报表功能现在多了一个导出
按钮，可以生成当前视图对应的 CSV 文件，筛选条件也会
一并包含在内。

你这边完全不需要做任何事情。这个功能已经在你的账户
上自动启用了。

  详情：example.com/changelog#csv-export
  发布日期：2026 年 9 月 2 日

你之所以会收到这封邮件，是因为你曾经提出过这个请求。
取消订阅请求相关的更新通知：<链接>

一共只有九十个词，而读者在第一句话里，就已经知道了这封邮件为什么会出现在自己的收件箱里。请把这个例子，和同一个变更出现在月度摘要邮件里的情形做个对比：在那种情况下，它只会是九个条目当中的一条，Dana 根本没有任何理由去注意到，那正是她自己曾经提出过的那个请求。

到底应该衡量什么

不能只看打开率这一个指标。对于定向通知来说，真正要问的问题，是那个提出请求的人到底有没有真正回来使用那项功能，所以真正应该去追踪的数字，是点击进入那条记录的次数，以及这个账户在一周之内到底有没有真正用上那项功能。对于破坏性变更通知来说，真正要看的则是覆盖率：受影响的账户里，到底有多大比例在截止日期之前就已经打开了这封邮件，以及你到底和其中哪些账户进行过一对一的跟进。

在这四种类型里，摘要邮件是唯一一种打开率本身就具有较高参考意义的类型，而即便如此，把它当作对照自身历史趋势的一个指标，也要比拿它去对照某个行业基准值更有用得多。不同类型的产品更新邮件承担着完全不同的任务，所以把它们全部平均成一个数字，最终什么都说明不了，也没有任何可以据此采取行动的价值。

它和发布说明到底有什么不同

发布说明是一份会持续保持可用状态的文档。而邮件，则是一种只会发生一次的传递机制。同一个变更往往会同时催生出这两样东西，而邮件本身应该比它所指向的那条记录更短。发布说明的最佳实践一文讨论了这份文档本身，而体验日志与发布说明的对比一文，则讨论了你到底正在写的是这两者中的哪一个。

真正值得花心思去处理好的，是这样一种关系：体验日志里的那条记录，才是那份最权威的文本，而邮件只是在引用它。一旦这两者出现了偏差，那个点击进去查看的读者，就会发现两处对这次变更的描述并不一致，然后就会同时对两者都失去信任。先发布那条记录，再从它那里去生成邮件，这种做法从结构上就直接消除了出现偏差的可能性。changeloop 在自己这一侧也是同样的做法：一条记录会被审核一次，然后同时发布到页面、信息流和小组件上，而通过小组件提出这个请求的人，会在由他的反馈转成的那个 GitHub issue 上、以及小组件本身里收到通知。changeloop 并不发送邮件；由你的邮件工具去引用那条已发布的记录。

FAQ

产品更新邮件到底应该多久发送一次? 只要收件人真的有一件具体的事情想要知道，就应该发送，而对于定向通知来说，这意味着他所提出的那个请求每次上线时都应该发送一次；对于摘要邮件来说，则意味着最多每月发送一次。

这封邮件应该包含整条体验日志记录吗? 不应该。只需要一句话加上一个链接就够了。那条记录才是最权威的版本，而在邮件里放一份完整的复制内容，只会意味着你需要同时维护两份必须保持一致的文本。

应该期待一个什么样的打开率? 请拿每一种类型自己的历史数据去和它自身做比较，而不是去和某个外部基准值做比较。定向通知和月度摘要邮件本质上是两种完全不同的产品，把它们平均在一起，只会把那个真正值得被追踪的数字给掩盖掉。

破坏性变更是不是需要一份单独的名单? 需要。而且这份名单应该是这样一种名单：用户没有真正理解后果之前，是没办法随随便便就取消订阅的，因为这正是那份会让他们真正付出服务中断代价的名单。

本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。

changeloop 相关页面： changelog 示例, 开发者文档