GeekNote
注册
登录

「分析思考」自建Newsletter系统

Newsletter在如今的信息网络中越来越流行,创建自己的Newsletter也成为一个趋势,但作为一个自托管应用爱好者,我更倾向于自建方案。这几天也研究了Newsletter的架构模式,包括从邮件系统、业务整合等多个角度进行了分析。

话先说在前头,这不是一篇教程! 正与电子邮件系统一样,自托管建立Newsletter系统并不是一个经济效益最大化的方案。如果你只是一个个人作者,想要尽可能低的运营成本,我还是更推荐使用成熟的平台(比如Revue、Substack)建立自己的Newsletter。本文是一篇比较零散的研究文,仅供参考。


Newsletter是如何组成的?

现代意义上的Newsletter本质是一种订阅营销的电子邮件 (E-Mail) 。既然是基于电子邮件系统发布,使用像Outlook这样的桌面邮件客户端,定期对订阅者的联系人组群发邮件,其实就是最简单的Newsletter了。

当然,这样是非常低效的模式,这种方式发布的Newsletter既不支持订阅者数据统计,撰写文章的排版也非常麻烦(虽说Outlook支持HTML邮件),至于付费订阅就更不用说了(除非你会让订阅者跟你联系,并附上一个PayPal地址或者支付宝收款码(开个玩笑2333))

思考一下,Newsletter是如何组成的?重要的部分,无非就是订阅系统、邮件系统、统计系统、与撰写/排版系统。

  • 其中,订阅系统能够让用户自助订阅,自动储存订阅者地址,或处理退订操作,还可通过接入额外的支付系统,实现付费订阅的目的;
  • 统计系统可以与订阅系统搭配,读取订阅信息,精准的控制邮件系统,或进一步营销、指定给单独的订阅者、订阅组;
  • 一个易于使用的撰写/排版系统也必不可少:支持富文本或者Markdown的编辑器,让作者像写博客一样轻松,并自动转为电子邮件兼容的排版格式
  • 最终,这些邮件将通过IMAP邮件系统群发,读取订阅系统的订阅者地址,将Newsletter发布到订阅者的信箱。

Newsletter作为一个古老的信息营销发布方式,其架构其实很易于理解。近年来的Newsletter也只是因为个人作者的加入,商业营销的概念被弱化,但是架构模式上都是大致相同的。

邮件系统 📧

前面也说过,Newsletter基于电子邮件系统发布传播,自然也不可避免有电子邮件的“命”与“病”:

由于大量的垃圾邮件散发猖狂,如今许多服务器提供商也对邮件系统端口进行封锁,大部分机房的IP也被列入主流邮件提供商的黑名单中。还有邮件服务器的维护、配置(如SPF、反向DNS)、容灾策略等,都是需要考虑的部分。

如何用自建的邮件系统,轻松顺利的将每一份Newsletter发送到订阅者的收件箱中,都是一件非常棘手的问题。

在这一点上,我们可以考虑使用SMTP中继服务,或使用现成的大规模/EDM邮件营销服务,如Amazon SES、Mailchimp、SendGrid、Mailgun等。但这样就不是完全自托管的方案了,不过考虑到搭建/维护Postfix、Exim等邮件服务器的难易度,选择一个三方托管的邮件系统也不是不可以,至少后端的统计数据还是可以掌握的。

业务整合、应用选择 📦

上述说到的重要组成部分,需要整合成一个系统,供大多数作者能轻松地进行操作、查看。排除掉可以外挂的邮件系统,剩下的订阅系统、统计系统与撰写/排版系统,都可以整合成一个业务栈。

Ghost

Ghost 是一个值得参考和使用的业务栈应用案例,对,就是那个广为熟知的开源博客CMS系统,近年来的版本已经提供了付费会员和Newsletter订阅的功能,主打创作转化,这是最易于理解和上手的业务栈整合案例了,无需考虑额外的维护成本,作者只需安心创作即可。(当然Ghost对于国内用户还是水土不服,实现付费功能需要接入Stripe支付平台,对于大部分国人来说门槛太高。)

我还参考了 listmonk.app 这个开源的邮件营销管理应用,其文档也提到了许多 概念 可以参考,比如跟踪像素。它甚至还支持比如退订邮件、Go动态模板等功能,如果有兴趣的话值得一试。

有些公司也提供了专有的商业化邮件营销(EDM)系统、平台,或一些CRM系统,都具有业务整合,它们有的也可以用于公司的服务器进行私有化部署。考虑到文章质量、避免广告嫌疑,这里就不再进行举例,大家可以自行了解。

可能包括我自己在内的许多人理解起来其实很懵,事实上对于大多数作者来说,选择一个活跃的、合适的应用整合系统,比如上文提到易于上手的Ghost博客系统,安心创作就可以了。

付费订阅 💰

众所周知,由于支付系统并不能直接完全自建(夸张地说,你不可能自己就能开个银行/交易所/平台),大多数作者不得不依赖Stripe或Paddle之类的支付平台,它们都支持API接口接入付费订阅系统。

此外还有两个方案分别是加密货币与激活码系统,但前者我绝不推荐、也无法管控;后者存在倒卖的问题,可以参考国内的一些付费安卓应用(Android App),这种现象屡见不鲜,所以并不推荐。

并且,激活码系统想要实现自动化销售,依然需要一个支付平台,此时不如直接将支付接口接入到订阅系统来的划算,除非你有线下/淘宝店这种实体/半实体场景下销售的想法,或者你运营了多个Newsletter,即使这样,也有许多需要解决的问题,对于一般的Newsletter的用途来说还是大材小用了。

总结

对于创作者来说,自己托管一个Newsletter系统是非常不具有经济效益的,自托管的优势是可以掌握自己的数据,但成熟的Newsletter平台实际上并没有限制作者太多的权益(除了一些非法内容),作者还是能够掌握数据的;

而从商业营销来讲,自托管的Newsletter系统,可能可以结合企业私有云,实现更强大、复杂的数据操作、进一步实现精准营销。

现实来看,Newsletter系统很难以完全地自托管运作,一方面是因为邮件系统的维护成本高、以及ISP屏蔽问题,其次是附加的支付系统不能完全自建。即使使用自托管的方案,仍然需要依赖一些外部的增值服务,除非你能够积极的维护邮件系统、并有一些复杂的云端数据操作需求,不然从经济上考虑,自建Newsletter并没有太大必要。

2
Creative Designer 🖌️ 创意设计师
登录后评论
评论 0
社区准则 博客 联系 反馈 状态
主题