一键退订必须写两层,少一层Gmail就把你整个域名限流
本文目录
- 退订链接找不到的时候,用户会去点哪个按钮?
- 用户不会放弃,他会换一个按钮
- 那一笔记在哪里
- 0.3%到底是多少人
- 为什么这条链值得单独讲
- 这不是一个新问题,但要求变了
- 形式要求为什么反而更好
- 本文要拆的三件事
- 这条链上一共有几个环节
- 误读那一步最要命
- 怎么打断这个循环
- 先说清楚本文不讲什么
- 为什么这件事值得单独写一篇
- Gmail现行的硬要求逐条摆出来
- 所有发件人都必须满足的
- 每天5000封以上还要加上这些
- 最后那两行是本文的重点
- 5000这个数怎么算
- 个人账号这个限定要注意
- 格式要求里还有几条容易踩的
- 正文链接也有要求
- 发件人显示名那一节
- 清单里没写但同样重要的一条
- 还有一节讲的是共享IP
- 共享IP该不该换成独立IP
- 国际化域名那一条很少有人看
- 把这份清单当成什么来读
- 认证那三项的分工
- 对齐那一条容易被漏掉
- 怎么快速验一遍
- 这份清单多久看一次
- 为什么退订必须写在两个不同的层?
- 正文那一层会怎么失效
- 信头那一层会怎么失效
- Gmail把它做成了什么样
- 那正文那一层还有什么用
- 两层的关系不是主备
- 一个具体的对照
- 这个思路可以往外推
- 反过来的推论
- 把这条判据写成一句可检查的话
- 为什么这么便宜的事还有人不做
- 顺手说一下那条隐藏内容的规则
- 对比度这件事有客观标准
- 邮件被裁掉尾巴这件事有多常见
- 减小邮件体积的几条
- 一个具体的数量级
- 一个可以拿去说服人的比喻
- 一键退订的技术细节有哪些容易做错?
- 要写的是这两行
- 你的服务器会收到什么
- 五种典型错法
- 第三种最容易被当成好意
- 官方文档指向的两份规范
- 怎么自己验一遍
- 两天生效那条线怎么守
- 还有一条容易忽略的
- 偏好中心是加分项不是替代品
- 令牌该怎么设计
- 那个网址会经过谁
- 防护规则拦掉退订请求的后果
- 怎么确认没被拦
- 把两行信头加进去具体要改哪里
- 怎么区分交易类和营销类
- 拆成两封的代价
- Google说自己不追踪打开率,这句话意味着什么?
- 原文只有三句
- 打开率是怎么算出来的
- 为什么这算一种截断
- 那该看什么
- 点击率也不是完全干净的
- 这件事对邮件自动化流的影响
- 怎么改这类分支
- 一个更保守的做法
- 为什么打开率这个指标这么难被放弃
- 怎么优化会扭曲它
- 一个可以立刻做的替代
- 还有一件事官方没写但值得注意
- 把这套逻辑推到别的指标上
- 一个简单的分级
- 顺便说一下报表该怎么改
- 一个男士理容订阅站是怎么把投诉率养上去的?
- 症状是从一个不相干的地方冒出来的
- 真正在发生的事
- 那次改版顺手做了另一件事
- 破局的过程
- 拆开之后的账
- 那两个数是一枚硬币的两面
- 改了什么
- 代价
- 他们后来做的一件事
- 这个案例里最该学的不是修法
- 工单里那23条是最早的信号
- 后来他们加了一条规则
- 为什么按意图归类比按话题归类有用
- 这次复盘留下的两条固化
- 为什么第二条更重要
- 他们没做成的一件事
- 除了退订,还有哪些出口会被截断?
- 先把出口列出来
- 短信这条线更硬
- 推送关闭那一层的陷阱
- 订阅取消那一层的代价最大
- 怎么统一检查
- 一条反直觉的经验
- 还有一类出口容易被完全遗漏
- 怎么找出这一类
- 把这件事写进上线检查
- 把出口画在同一张图上
- 这解释了为什么这类问题特别贵
- 所以优先级排法要变
- 最后一行值得单独说
- 顺带说一下短信那条线的字数账
- 那有没有折中办法
- 还有一个没有出口的场景
- 这份检查清单怎么落到发送流程里?
- 六件自查动作
- 卡点挂在哪里
- 为什么是闸门而不是别的形式
- 最后那一项为什么只警告不阻断
- 怎么跟人说这件事
- 护住所有人的第二句
- 四条边界
- 最后一句
- 这套做法和上一件事的关系
- 还有第三种同形状的问题
- 怎么找出这类问题
- 本文自己的边界再说一遍
- 一句话总结这三篇的共同点
- 最后留一个可以马上做的动作
- 常见问题解答
- 正文里已经有退订链接了,还需要写信头吗?
- 每天发不到5000封,是不是就不用管一键退订?
- 退订率涨了怎么跟老板交代?
- 为什么一键退订不能弹一个确认页?
- Google说不追踪打开率,我的邮件报表还能看什么?
- 怎么判断点击是真人还是安全网关扫的?
- 偏好中心能不能替代退订按钮?
- 退订之后多久必须生效?
- 权威参考资料
摘要:Gmail要求群发邮件把退订这件事写在两个互不相干的地方——信头里的一键退订,和正文里那个看得见的链接。很多团队只做了后者。可正文那一层能失效的方式太多:邮件被裁掉尾巴、图片没加载、暗色模式把浅灰字吞了、模板塌成一列。而一个找不到退订入口的人不会放弃,他会去点举报垃圾邮件——那一下直接计进你的投诉率,超过0.3%整个发件域名被限流。一个显示层面的小故障,最后决定的是你所有邮件还能不能进收件箱。信头那一层之所以必须存在,不是因为它更方便,是因为它是唯一一个不经过渲染的层。
退订链接找不到的时候,用户会去点哪个按钮?
这个问题的答案决定了后面所有内容的分量。因为它不是一个体验问题,是一个投递问题。
用户不会放弃,他会换一个按钮
一个已经决定不想再收你邮件的人,处在一种很确定的状态里:他要让这件事停下来。如果退订链接就在眼前,他点退订;如果找不到,他不会耸耸肩关掉邮件,他会去点那个永远在同一个位置、永远有效、永远只要一下的按钮——举报垃圾邮件。
自动化流跑得越勤,用户碰到退订入口的次数越多,Klaviyo 7种高ROI自动化流那篇把常见的几条流和它们的触发条件列全了。
这两个动作对用户来说成本一样,对你来说差了一个数量级。一次退订是把一个人从列表里移走,一次举报是往你发件域名的档案里记一笔。
那一笔记在哪里
记在Gmail的发件人信誉数据里,然后以投诉率的形式出现在Postmaster Tools。官方给的两条线是这样的:
投递这条线的全貌在邮件投递率怎么从60%拉到97%那篇,认证配置、IP预热和声誉建设都在里面,本文只处理其中的退订那一环。
| 投诉率 | 官方表述 | 实际含义 |
|---|---|---|
| 低于0.10% | 建议长期保持的水平 | 偶尔一次波动扛得住 |
| 低于0.30% | 硬性要求,不得触及 | 触及即可能被限速、拦截或判为垃圾邮件 |
注意官方原文的措辞:把投诉率保持在0.10%以下,并且避免任何时候达到0.30%或更高。它给的是两个数,一个是目标,一个是红线,中间那段是缓冲。
0.3%到底是多少人
一次发给10万人的群发,300个人点举报就到线了。这个数字比大多数人的直觉低得多——很多团队心里的容忍度是千分之几,实际是万分之三十。
行业基准这类数怎么用有讲究,转化率、排名周期、流量占比该对标多少那篇给了一批公开基准和它们各自的适用边界。
换个角度看更清楚:如果你的列表里有0.3%的人这一次找不到退订入口,你就撞线了。而找不到退订入口这件事,取决于邮件在他那台设备上渲染成了什么样。
为什么这条链值得单独讲
一个显示层面的小故障,最后决定的是你所有邮件还能不能进收件箱。中间没有任何一个环节会告诉你出了事。
同一个形状的问题在网页那边也有,Googlebot只读前2MB而超出的部分等于不存在那篇量了46个电商站,机制跟这里一模一样。
渲染出错不会报错,用户点举报不会通知你,投诉率上升是一条缓慢的曲线,而当它触线的时候,你看到的现象是打开率下降——然后你会去优化标题。
这不是一个新问题,但要求变了
邮件里放退订链接这件事,美国的相关法规二十多年前就写进去了。变化发生在2024年2月:Gmail把它从法律要求升级成了技术准入条件,而且把它拆成了两层。
合规要求和技术要求经常各说各话,GDPR和CCPA同意横幅怎么不毁SEO数据那篇讲的是另一处两套要求打架的现场。
法律那边的表述见CAN-SPAM合规指南,要求的是“提供一个清晰显著的退订方式”,这是结果导向的;Gmail要求的是“在信头里放这两个字段,并且在正文里放一个可见链接”,这是形式导向的。后者可以被程序检查,前者不能。
形式要求为什么反而更好
因为它把一个需要人来判断的事情,换成了一个机器能验证的事情。清晰显著这四个字,每个人的理解都不一样;而信头里有没有那个字段,是一个是或否。
能被程序验证的判据比需要人判断的判据可靠得多,9条查得到出处、8条数字对不上那篇追过一批经不起验证的说法。
这个转换的代价是它管不了那些形式合规但实际难用的做法——比如退订链接指向一个要求登录的页面。但至少它把最基本的那一层守住了。
本文要拆的三件事
第一是那两层的具体要求分别是什么,以及为什么必须是两层而不是一层。第二是官方明确说了不追踪打开率之后,你的邮件报表还剩下什么可信的东西。第三是除了退订之外,邮件里还有哪些出口同样会被截断。
自动化流和一次性群发在退订这件事上的处理不一样,Flow和Campaign到底有什么区别那篇把两者的分工讲清楚了。
全文的判据只有一句话:凡是用户要用来终止这段关系的入口,都不能依赖渲染。
这条链上一共有几个环节
把它拆开数一遍,从邮件发出去到你的域名被限流,中间有六步。
不可见的环节最容易攒问题,揪出购买路径上那些看不见的摩擦力那篇讲的是转化路径上同一类看不见的断点。
| 环节 | 发生了什么 | 你能看见吗 |
|---|---|---|
| 渲染 | 邮件在收件人的客户端上显示成某个样子 | 看不见 |
| 寻找 | 用户扫一眼找退订入口 | 看不见 |
| 放弃 | 没找到,转而找一个一定有效的办法 | 看不见 |
| 举报 | 点下举报垃圾邮件 | 看不见 |
| 累积 | 投诉率缓慢爬升 | 要主动去查才看得见 |
| 限流 | 发送速率被限、部分邮件进垃圾箱 | 表现为打开率下降 |
六个环节里前四个完全不可见,第五个要主动去一个多数人没登录过的后台才看得见,第六个看得见但会被误读成另一件事。这就是为什么这类问题往往要几个月才被发现。
误读那一步最要命
限流的表象是打开率掉了。而打开率掉了,团队的第一反应几乎一定是内容出了问题——标题不够吸引、素材老了、发送时间不对。
指标异动的第一反应经常是错的,GA4直接流量突然暴增的六类成因排查决策树那篇给了一套先排除再归因的顺序。
接下来的动作是换标题、换素材、加大发送频率试试看。而这三件事每一件都会让投诉率继续涨。误诊之后的治疗,方向恰好是加速病情。
怎么打断这个循环
只需要一件事:在归因到内容之前,先去看一眼投诉率。
看错指标会让整个团队朝错误方向使劲,砍掉虚荣指标、定准北极星指标那篇讲的是怎么挑那个真正该盯的数。
这一步的成本是十分钟,包括第一次验证域名的时间。它的价值不在于它能修好什么,在于它能阻止你朝着错误的方向再走三个月。
先说清楚本文不讲什么
不讲怎么提高打开率,不讲标题怎么写,不讲什么时间发效果好。这些话题网上已经很多,而且多数结论都建立在一个后面会被否掉的指标上。
分群和频率才是投诉率的第一大来源,从RFM、生命周期到互动度的7个分群维度那篇是这方面比较完整的一份。
也不讲邮件内容策略。分群、频率、生命周期节点这些确实是投诉率的第一大来源,但它们属于另一个话题。本文只处理一件事:那个想走的人,能不能顺利地走掉。
为什么这件事值得单独写一篇
因为它是整条邮件链路里唯一一个失败会牵连全局的环节。内容写砸了,损失是这一封的效果;退订入口坏了,损失是之后所有邮件的投递能力。
列表本身的质量决定了后面所有事的上限,邮件列表从0养到能变现的合规获客实战那篇讲的是入口那一端。
一个是这一次的收益,一个是未来所有次的资格。它们不该被排在同一个优先级序列里,但在多数团队的排期表上,它们确实排在一起。
Gmail现行的硬要求逐条摆出来
先把清单摊平。Gmail发件人指南里这份要求从2024年2月1日起生效,分成两档,判据是你每天往Gmail个人账号发多少封。
所有发件人都必须满足的
| 要求 | 说明 |
|---|---|
| SPF或者DKIM | 二选一即可,为发件域名配置 |
| 正向与反向DNS记录 | 发件域名或IP必须有有效的PTR记录 |
| 使用TLS连接传输 | 2023年12月加入清单 |
| 投诉率低于0.3% | 以Postmaster Tools里报告的为准 |
| 符合RFC 5322 | 互联网邮件格式标准 |
| 不冒充Gmail的From信头 | Gmail已启用DMARC隔离策略 |
出海业务的底层配置往往一开始就该定好,Stripe Atlas美国LLC全流程的8步那篇是另一份开工期就要办完的清单。
每天5000封以上还要加上这些
| 追加要求 | 说明 |
|---|---|
| SPF和DKIM都要 | 不再是二选一 |
| 配置DMARC | 策略可以是none,但记录必须存在 |
| From域名与SPF或DKIM域名对齐 | 直发邮件必须通过DMARC对齐检查 |
| 支持一键退订 | 营销类与订阅类邮件适用 |
| 正文里有清晰可见的退订链接 | 与上一条并列,不是二选一 |
群发队列怎么管直接影响你每天实际发出多少封,Magento 2邮件订阅与群发队列实战那篇讲了队列侧的做法。
最后那两行是本文的重点
官方原文把它们写在同一个句子里:营销邮件和订阅类邮件必须支持一键退订,并且在邮件正文里包含一个清晰可见的退订链接。
一个控件的选型会决定用户能不能顺利完成动作,下拉框在独立站表单里悄悄吃掉你的询盘那篇是同一类问题的另一个现场。
一个“并且”,两个不同的层。这句话的语法结构本身就是答案——如果一层够,就不会用并且。
5000这个数怎么算
按发件域名算,不按发件系统算。同一个域名当天发出的所有邮件加起来,只要有一天超过5000封发到Gmail个人账号,之后就一直按大批量发件人的标准要求。
大促群发是把发送量推过门槛的典型场合,独立站会员日营销的5步那篇讲了这类活动的节奏安排。
这意味着一次大促群发就能把你永久推进那一档。对绝大多数还在运营邮件列表的独立站来说,直接按高标准做是最省心的,不用去算自己在哪一档。
个人账号这个限定要注意
这份要求管的是发到gmail.com和googlemail.com结尾的地址。如果你的客户主要是企业邮箱,这份清单在字面上管不到你。
不同邮箱服务商的策略差别不小,中国用户免费邮箱14个实测推荐那篇比过一批邮箱的注册门槛与隐私口径。
但实操上没有区别:Google Workspace的邮箱走的是同一套反垃圾体系,另一家主流邮箱服务商在自己的发件人最佳实践里也给出了几乎一致的认证与退订要求。把它当成行业底线来做,而不是当成一家的规定。
格式要求里还有几条容易踩的
From信头只能有一个邮箱地址;单实例信头不能重复出现(From、To、Subject、Date这几个各只能有一个);每封邮件必须有有效的Message-ID;避免过大的信头。
服务器侧那一堆配置项各有各的影响面,服务器配置对SEO影响的20项必看清单那篇可以拿来做一次交叉检查。
还有一条写得很明确:不要用HTML和CSS隐藏邮件里的内容,隐藏内容可能导致邮件被判为垃圾邮件。这一条后面还会再提到,因为它和退订链接的可见性直接相关。
正文链接也有要求
原文写的是:邮件正文里的网页链接应当可见且易于理解,收件人点击前应当知道会发生什么。
链接文案写成什么样直接决定用户点不点,SEO文案写作的8大实战技巧那篇里关于锚文本的部分同样适用于邮件。
这句话看起来像是在讲钓鱼链接,但它同样适用于退订。一个写成“点这里管理您的偏好设置”的链接,和一个写成“退订”的链接,在这条要求下不是等价的。
发件人显示名那一节
官方专门开了一节讲显示名,核心是:显示名只能用来标识发件人,不能塞主题或者内容,不能用表情符号模仿图形元素来暗示某种认证。
发件人名字是品牌声音的一部分,让产品页、客服和社媒听着像同一个人那篇讲的是这套一致性该怎么建。
这一节跟退订没关系,但它揭示了一个思路:这份清单管的不只是技术配置,还包括那些会让收件人做出错误判断的表现形式。而找不到退订入口,正是让收件人做出错误动作的典型场景。
清单里没写但同样重要的一条
退订必须在两天内生效。这条写在订阅管理那一节,不在准入要求里,但它是投诉率的直接来源之一——一个已经点了退订还在收到邮件的人,下一次一定去点举报。
订阅状态的同步时效在续费场景下更要紧,订阅商品、定期扣款与续费失败挽回实战那篇讲了状态流转怎么设计。
两天这个期限在实操上意味着你的退订处理不能走人工审核,也不能挂在一个每周跑一次的同步任务上。
还有一节讲的是共享IP
如果你用的是邮件服务商的共享发送IP,官方提醒了两件事:确认这个IP不在任何互联网黑名单上,以及用Postmaster Tools查一下这个共享IP的声誉。
共用IP这件事在别的场景下也会咬人,DTC出海网络分线5场景实战那篇讲的是广告、支付和客服各自该怎么隔离。
这一条的含义有点冷:你的投递能力有一部分取决于跟你共用一个IP的那些陌生人的行为。而你既不知道他们是谁,也管不了他们发什么。
共享IP该不该换成独立IP
判据是发送量。量太小的话独立IP反而更糟——收件方需要持续的发送记录才能给一个IP建立声誉,量小的独立IP在收件方眼里长期是个陌生人。
基础设施选型都是同一类取舍,外贸独立站用国内主机还是国外主机那篇的判断框架可以直接搬过来。
行业里常说的门槛是每月稳定发送几万封以上才值得考虑独立IP。在那之下,共享IP的问题是别人可能拖累你,独立IP的问题是没人认识你,后者更麻烦。
国际化域名那一条很少有人看
清单里有一条要求:认证域名、信封发件域名、载荷域名、回复域名和发件人域名这五个,如果用的是国际化域名,必须按一份Unicode技术标准的第5.2节格式化。
域名这一层的坑比想象的多,出海独立站起名的命名策略与SEO避坑那篇把常见的几种列了一遍。
这一条对绝大多数出海独立站用不上,因为大家用的都是纯ASCII域名。但它揭示了这份清单的颗粒度:它连域名的编码格式都管,说明这不是一份建议,是一份准入检查。
把这份清单当成什么来读
不要当成最佳实践读,要当成接口文档读。最佳实践是做了更好,接口文档是不做就调不通。
把必填项当成建议来排期是通病,独立站CMS第一年SEO隐性失分排查那篇列的12项也是这个性质。
这个心态差别会影响你怎么排期。最佳实践可以排到下个季度,接口文档里的必填项只能排在上线之前。而这份清单里超过一半的条目属于后者。
认证那三项的分工
SPF、DKIM、DMARC经常被并排提,其实它们管的是三件不同的事,理解了分工才知道缺哪个会怎样。
几个机制各管一件事、合起来才成立,这种结构在响应头那边也一样,X-Robots、缓存与Vary的响应头SEO机制那篇拆得很细。
| 机制 | 它回答的问题 | 缺了会怎样 |
|---|---|---|
| SPF | 这个IP有没有资格用这个域名发信 | 转发场景下容易失效 |
| DKIM | 这封信在路上有没有被改过 | 转发之后无法验证完整性 |
| DMARC | 前两项没过的时候该怎么处理 | 收件方只能自行猜测 |
DMARC策略可以设成none,也就是“不做任何处理只报告”。官方要求的是记录必须存在,不是策略必须严格——这是个很低的门槛,低到没有理由不做。
对齐那一条容易被漏掉
大批量发件人那一档里有一条:直发邮件的From域名必须与SPF域名或者DKIM域名之一对齐。对齐的意思是主域相同,不是完全相同。
两个系统各写各的、结果对不上是常态,装了SEO插件却冒出两个canonical那篇是另一个同构的例子。
最常见的踩坑场景是用第三方邮件平台发信,平台默认用自己的域名做信封发件域名,而你的From写的是自己的域名,两边不对齐,DMARC检查过不了。解法是在平台里配置自定义的发信域名,这一步在很多平台的引导流程里是可选项。
怎么快速验一遍
给自己发一封,查看原始邮件,看Authentication-Results这一行。里面会写清楚SPF、DKIM、DMARC三项各自的结果。三个pass就算过了。
这类检查基本都能用免费工具完成,预算为零也能做好SEO的免费工具清单那篇整理过一批。
这一步和前面查List-Unsubscribe是同一个动作,看的是同一份原始邮件的不同部分。所以这两件事可以合并成一次检查,总共不到五分钟。
这份清单多久看一次
半年一次,或者每次换邮件平台、换发信域名、接入新的自动化工具之后立刻看一次。它变动不频繁,但每次变动都是加要求,从来没有减过。
为什么退订必须写在两个不同的层?
这一节是全文的核心。答案不是“多一层保险”这么笼统,而是这两层的失效方式完全不重叠。
正文那一层会怎么失效
把能想到的都列出来,你会发现这个清单长得不太合理。
真实设备上的表现和你测试机上的差别很大,海外客户用低端机弱网打开你的独立站有多卡那篇量过这个差距。
| 失效方式 | 触发条件 |
|---|---|
| 邮件被客户端裁掉尾巴 | 邮件体积过大,客户端只显示前一部分 |
| 图片没加载 | 退订做成了图片按钮,而默认不加载图片 |
| 暗色模式反色 | 浅灰字在深色底上直接消失 |
| 样式被剥离 | 某些客户端不支持你用的CSS写法 |
| 布局塌成一列 | 页脚多列变单列后退订被挤到很远的位置 |
| 字号太小 | 为了不显眼故意做小,移动端点不中 |
| 藏在一段法律声明里 | 用户扫一眼没看见就放弃了 |
这七种里只有最后两种是有人故意的,前五种全是技术意外。而技术意外的共同特征是:发件的人在自己的测试邮箱里看不到它。
信头那一层会怎么失效
基本只有一种:你没写。
不经过渲染的那一层往往最可靠也最容易被忘记,接口和feed这类地址拿什么说自己不想被收录那篇讲的是另一处。
信头不参与渲染。它不受邮件长度影响,不受样式影响,不受暗色模式影响,不受客户端支持哪些CSS影响,也不需要用户滚动到底部。它是这封邮件里唯一一个不经过显示层的东西。
要两层的理由不是多一份保险,是这两层里有一层根本不经过那个最容易出错的环节。
Gmail把它做成了什么样
在Gmail里,检测到这两个信头之后,发件人名字旁边会出现一个退订入口。用户点它,Gmail直接替他发出退订请求,全程不打开邮件、不跳转网页。
把一个动作的成本降到一次点击,效果经常超出预期,被低估的9个反直觉UI设计杠杆那篇有几个类似的例子。
这意味着一个用户可以在完全不看你邮件内容的情况下退订。听起来像坏消息,其实是好消息——他本来的替代动作是点举报。
那正文那一层还有什么用
三个用处。第一,不是所有邮件客户端都实现了一键退订入口,用非Gmail客户端的人只能靠正文里那个链接。
页脚不是杂物抽屉,Footer怎么设计才是信任收口和转化的最后一关那篇讲了这一块该放什么、怎么排。
第二,它是给那些还没决定要不要退订的人看的。一键退订按钮只在特定位置出现,而正文里的链接旁边可以放降频选项、偏好设置这些替代品。
第三,法规要求的是正文里那个。技术准入和法律合规是两套要求,正文链接同时满足两边,信头只满足其中一边。
两层的关系不是主备
很多人把信头那层理解成正文链接的备份,这个理解会导致一个错误决策:既然有备份,正文那个就可以做得低调一点。
把两个各司其职的东西理解成主备会导致错误决策,多触点归因模型怎么选那篇里也有同类误解。
实际关系是这样的:信头那层负责兜住那些已经决定要走的人,正文那层负责服务那些还在犹豫的人。它们面对的是两批人,不是同一批人的两条路。
一个具体的对照
假设一封邮件在某个客户端里被裁掉了尾巴。
同一个故障配不配一条退路,结局完全不同,页面上却只剩下四个字输入有误那篇讲的是表单侧的同一件事。
只有正文链接的情况:用户找不到退订,投诉率加一。有信头的情况:用户在发件人名字旁边看到退订,点一下,你的列表少一个人,投诉率不动。
同一个技术故障,两种结局的差别不在故障本身,在于你有没有留一条不经过那个故障点的路。
这个思路可以往外推
凡是用户用来终止一段关系的入口,都不应该依赖渲染。退订是一个,取消订阅是一个,撤回授权是一个,删除账号是一个。
用户旅程末端那些页面的重要性经常被低估,用户付完钱看到的那一页那篇拆了确认页的六个模块。
这几个入口的共同点是:用户在使用它们的时候情绪已经是负面的,容错度接近于零。一个找不到的取消按钮,换来的是一次退款申请或者一条差评,而不是一次重新考虑。
反过来的推论
那些用来促成转化的入口——加购、结算、领券——反而可以依赖渲染,因为用户在那个状态下愿意多找一下、多点一次。
转化类入口和终止类入口该分开对待,高转化电商网站的SEO加CRO双轴8模块那篇把两条线的分工画得比较清楚。
这条区分在排优先级的时候很有用:做兼容性测试的时候,先测终止类入口,再测转化类入口。直觉通常是反的,因为转化类入口更能带来看得见的收益。
把这条判据写成一句可检查的话
一个入口是否可靠,等于它经过了多少个可能出错的层。正文里的退订链接经过了HTML解析、CSS应用、图片加载、暗色模式转换、屏幕尺寸适配这五层;信头里那两行经过零层。
经过的层越多失败方式越多,一行响应头把嵌进来的地图和支付按钮一起变成了摆设那篇是个极端例子。
五比零。这不是“更保险一点”的差别,是两个数量级的差别。而实现成本上,信头那两行是在发送时拼一个字符串,比调一版页脚样式便宜得多。
为什么这么便宜的事还有人不做
三个原因,按出现频率排。第一,那套邮件系统是几年前搭的,当时只有老的那个信头,后来没人回头补。第二,用的是第三方模板工具,模板管的是正文,信头由发送侧决定,两边归不同的人。第三,压根不知道有这回事。
很多配置项没做只是因为没人知道它存在,Rank Math怎么设置对SEO最好那篇把逐项取舍摊开写了。
第三种最常见,也最容易解决。这也是本文把那两行的具体写法原样列出来的原因——很多时候缺的不是决心,是那两行到底该写成什么样。
顺手说一下那条隐藏内容的规则
官方明确写了不要用HTML和CSS隐藏邮件里的内容,隐藏内容可能导致邮件被判为垃圾邮件。这条规则本意是防钓鱼,但它和退订链接的可见性撞在了一起。
规则的字面和它想防的行为之间总有缝,从Panda到规模化内容滥用的诊断与修复清单那篇讲的是另一处缝。
一个用极浅的颜色、极小的字号做的退订链接,从技术上讲不算隐藏,但它和隐藏的效果一样。规则管得住写死的display属性,管不住一个对比度不足的色值——而后者在实操里常见得多。
对比度这件事有客观标准
无障碍规范给的正文文字对比度下限是4.5比1,大号文字是3比1。这两个数是可以用工具直接算的,不需要任何主观判断。
可访问性这一类判据大多能被算出来,桌面时代验过的那份RTL清单有一半不作数那篇讲的是另一组需要重验的规则。
把它写进邮件模板的检查项里,比任何一句“退订链接要显眼一点”都管用。一个能被算出来的判据,和一个需要商量的判据,在推动落地时的难度差得很远。
邮件被裁掉尾巴这件事有多常见
常见程度取决于邮件体积。图片多、模板复杂、带一大段商品推荐的营销邮件最容易触发;纯文字的交易通知几乎不会。
图片处理方式直接决定邮件体积,135字节的图标被压成560字节那篇量过几种格式的真实开销。
而营销邮件恰恰是最需要退订入口的那一类。这不是巧合:邮件越像营销邮件,它越可能被裁,收件人也越可能想退订。两个概率是正相关的。
减小邮件体积的几条
把内联样式改成尽量精简的写法、去掉编辑器生成的冗余标签、图片走外链而不是内嵌、商品推荐控制在合理的数量。这几条对邮件和对网页是一个道理。
精简HTML这件事有一批通用做法,WordPress免插件压缩HTML加速那篇讲了保留代码块时该注意什么。
但要说清楚:减小体积能降低被裁的概率,不能消除它。所以它是补充手段,不能替代信头那一层。这个关系跟前一篇里“瘦身不能替代前移”完全一样。
一个具体的数量级
行业里通常建议把邮件的HTML控制在100KB以内。这个数字没有官方来源,但各家邮件工具的提示大多围绕着它。
要看清一段样式到底占多少字节,格式化工具比肉眼靠谱,CSS格式化、压缩与前端性能的真实账那篇算过这笔账。
值得注意的是这个数是压缩前的、纯HTML的,不含图片。而一封用可视化编辑器拖出来的营销邮件,很容易在没有意识到的情况下超过它——编辑器为了保证跨客户端兼容,会生成大量嵌套表格和重复的内联样式。
一个可以拿去说服人的比喻
正文里的退订链接像是写在门上的字,信头里那两行像是门本身。字可能被涂掉、被贴住、被换成看不清的颜色,门不会。
而用户要的从来不是那几个字,是那扇门。把字写好是应该的,但先得确认门在。
一键退订的技术细节有哪些容易做错?
这一节把两个信头字段和它背后那个POST请求讲清楚,顺便列出保哥见过的几种典型错法。
要写的是这两行
第一行声明这个列表支持一键退订:List-Unsubscribe-Post,值固定写成List-Unsubscribe=One-Click。第二行给出退订地址:List-Unsubscribe,值是一个用尖括号包起来的网址。
确认一段结构化文本写没写对,丢进格式化工具最快,JSON格式化与JSON-LD调试那篇讲得很细。
两行缺一不可。只写第二行是老写法,它只是给出了一个退订入口;加上第一行才构成一键退订。这个区分很多现成的邮件系统里都没做对,因为第二行的历史比第一行长得多。
你的服务器会收到什么
一个POST请求,内容类型是表单编码,请求体就一行:List-Unsubscribe=One-Click。没有别的参数,没有认证,没有会话。
要看清一个地址的状态码与响应头,用接口测试工具最省事,API测试工具快速看清一个URL的状态码与响应头那篇讲了用法。
所以你的退订地址里必须自带足够的信息来确定退订谁——通常是一个一次性的、不可猜测的令牌。把用户ID直接放在网址里是个坏做法,因为那个网址会经过Gmail的服务器。
五种典型错法
| 错法 | 后果 |
|---|---|
| 只给mailto地址不给网址 | 不构成一键退订,且退订处理变成人工 |
| 退订地址需要登录 | 请求打不到你的处理逻辑 |
| 退订地址返回一个确认页 | 一键退订的语义是立即生效,不该再确认 |
| 只处理GET不处理POST | 请求收到了但没生效 |
| 令牌可以被猜出来 | 有人能批量退掉别人 |
一条路上任何一个环节做错都会让人走不完,独立站结账页放弃率为什么超70%那篇拆了九个成因。
第三种最容易被当成好意
返回一个“您确定要退订吗”的确认页,在网页上是标准做法,在这里是错的。用户已经在客户端上点过一次了,那一下就是他的确认。
善意的多一步经常是体验的减分项,电商网站UI/UX设计原则背后的认知心理学逻辑那篇解释了为什么。
一键退订这个名字里的“一键”不是形容它快,是在定义它的语义:一次交互完成,没有第二步。再加一步等于把这条路又变回了正文链接那条路。
官方文档指向的两份规范
List-Unsubscribe这个信头的定义在一份2002年的规范里,它当时的设计目标是给邮件列表提供一组管理用的信头,退订只是其中之一。一键退订那部分是2016年才补上的另一份规范,它增加的正是那个POST语义。
了解这段历史的实际用处是:你手上那套邮件系统如果是几年前搭的,它很可能实现了前者而没有后者,而这在功能测试里看不出来。
怎么自己验一遍
最直接的办法是给自己发一封,然后在邮件客户端里查看原始邮件,搜索List-Unsubscribe。两行都在,值都对,第一件事就算过了。
把两份东西摆在一起比是最朴素也最有效的验证法,渲染对比器揪出爬虫和用户看到的页面不一样那篇讲了做法。
第二件事是拿那个网址手工发一个POST请求过去,请求体写上那一行,看看返回什么、数据库里那条订阅记录有没有变。这一步不能省,因为信头写对了不代表后端接住了。
两天生效那条线怎么守
退订处理必须是同步的,或者至少是分钟级的异步。走每日同步、每周清洗、人工审核这几种,都会踩线。
定时任务的粒度决定了状态同步的时效,用cron把独立站运维自动化那篇给了完整的脚本示例。
更隐蔽的一种是多系统不同步:退订写进了邮件平台,但下一次群发的名单是从订单系统导出来的。这种情况下退订确实生效了,只是生效在一个不参与发信的地方。
还有一条容易忽略的
官方在订阅管理那一节里写了:对多次退信的收件人应当自动退订。这一条不是准入要求,但它同样影响投诉率——一个长期收不到的地址留在列表里,只会持续拉低你的送达数据。
列表清洗与复购之间的平衡不好拿捏,DTC品牌私域怎么从0起步那篇讲了邮件加社群的四段路线。
顺带一提,官方还建议定期发一封确认邮件,问收件人还想不想继续收。这个动作会让列表变小,也会让投诉率变好看,而这两件事在多数团队的考核里是矛盾的。
偏好中心是加分项不是替代品
让收件人查看自己订阅了哪些列表、单独退某一个或者全部退掉,官方明确说这是可以用的补充选项,但不能替代一键退订。
给用户一堆选项不等于给了他出路,连点五个筛选之后用户已经忘了自己选过什么那篇讲的是同一种设计失误。
这句“不能替代”值得记一下,因为偏好中心正是最常见的替代方案:把退订按钮换成“管理订阅偏好”,跳到一个有六个复选框的页面。用户的体验是他想停下来,你却给了他一份问卷。
令牌该怎么设计
三个要求:不可猜测、与收件人绑定、可以被撤销。不可猜测意味着不能是自增ID或者邮箱的哈希;与收件人绑定意味着一个令牌只能退一个人;可撤销意味着退订之后这个令牌应当失效。
凭据设计的通用原则在这里同样成立,SSH密钥、禁root、sudo与fail2ban实战那篇讲的是另一处凭据管理。
还有一个容易忽略的:令牌不该有太短的有效期。用户可能翻出三个月前的一封邮件来退订,那时候令牌已经过期的话,他会回到那个熟悉的替代动作上去。
那个网址会经过谁
一键退订的POST请求是由邮件服务商的服务器发出来的,不是用户的浏览器。所以你的日志里会看到一个来自数据中心的请求,没有浏览器指纹,没有引荐来源。
要看清一个地址被谁访问过,日志是唯一可靠的地方,每5次Googlebot抓取就有1次IP不属于谷歌那篇讲了怎么读。
这一点会影响两件事:你的防爬虫规则可能会拦掉它,你的埋点会记不到这次退订。前者是硬故障,后者会让你的退订统计少一大块。
防护规则拦掉退订请求的后果
用户在客户端上点了退订,Gmail发出请求,你的防火墙返回403,Gmail那边不会重试也不会告诉你。用户以为自己退了,下一封照样收到。
防护规则误伤是个老问题,robots加UA加WAF三层选型框架那篇给了怎么分层放行的思路。
然后他会去点举报,而且这一次比第一次坚决得多。所以退订地址应当在所有防护规则里单独放行,这一条建议保哥每次做邮件相关的排查都要提一遍。
怎么确认没被拦
看那个地址的访问日志,按状态码分组。正常情况下应当是清一色的200或者204,出现403、429、503就是被拦了。
按状态码分组看日志是最快的定位法,读懂Googlebot抓取与预算浪费那篇的读法可以直接套用。
如果日志里那个地址一次访问都没有,情况更糟——说明请求根本没到你的服务器,问题可能在CDN或者WAF那一层。零访问不是好消息,它意味着这条路从来没通过。
把两行信头加进去具体要改哪里
取决于你用什么发信。用第三方邮件平台的话,多数平台在列表设置里有一个开关,打开就行,值由平台生成。用自建系统的话,就是在拼装邮件头的地方多写两行。
交易类通知和营销类邮件在系统里往往走两条路,WooCommerce退款怎么退才不出错那篇讲的是交易侧那条。
需要注意的是交易类邮件不要加。订单确认、发货通知、密码重置这些不属于营销或订阅类邮件,给它们加一键退订会让用户误以为可以退掉交易通知。
怎么区分交易类和营销类
判据是这封邮件是不是由用户的某个具体动作触发的,并且内容只与那个动作有关。下单触发的订单确认是交易类;下单触发的“猜你喜欢”是营销类,哪怕它们在同一个流程里发出。
订单流程里每一步会触发哪些通知,Magento 2订单发票、发货与退款工作流实战那篇列得比较全。
混在一封里发是最麻烦的情况——订单确认下面挂一段商品推荐。这种邮件在法规和平台规则上的定性都比较模糊,稳妥做法是拆成两封。
拆成两封的代价
发送量翻倍,而发送量直接影响你在哪一档,也影响投诉率的分母。这里有个反直觉的点:分母变大其实对投诉率有利,因为交易类邮件几乎不会被举报。
发送节奏和会员权益通知混在一起是常见做法,DTC独立站会员忠诚度体系怎么搭那篇讲了这套通知该怎么排。
但别为了摊薄投诉率去多发交易类邮件,那是本末倒置。这里只是说明拆分的代价没有想象中大。
Google说自己不追踪打开率,这句话意味着什么?
这是官方文档里最短也最容易被跳过的一节,但它把很多团队的邮件报表整个否掉了一半。
原文只有三句
| 原文 | 它否定的东西 |
|---|---|
| Google不追踪打开率 | 打开率不是Gmail用来判断的信号 |
| Google无法验证第三方报告的打开率是否准确 | 你的邮件平台报的那个数没有权威背书 |
| 低打开率不一定准确反映投递或垃圾邮件分类问题 | 打开率掉了不等于投递出了问题 |
指标被误用的情况比想象的普遍,GA4核心指标解析的4个错误那篇挑了几个最容易出错的。
三句话是递进的:第一句说它不用这个指标,第二句说它不认你的这个指标,第三句说这个指标反映不了你想用它反映的那件事。
打开率是怎么算出来的
在邮件里放一张1像素的图片,图片地址带着这封邮件的标识。收件人的客户端去加载这张图,你的服务器收到请求,就记一次打开。
埋点这类东西的实现细节决定了数据长什么样,隐藏第三方统计图标的现代处理与合规那篇讲了它们的另一面。
这套机制有三个已知的失真来源:默认不加载图片的客户端会漏记;图片代理服务会在用户没打开的时候预取,导致多记;同一封邮件被多次渲染会重复记。而这三个方向的偏差大小,你一个都不知道。
为什么这算一种截断
打开率这条观测链的最后一环是一次图片请求,而那次请求发不发、什么时候发,不由收件人决定,由他的邮件客户端决定。
一个指标可信到什么程度取决于它怎么被采到,SEO数据分析从指标体系到异常诊断那篇给了一套判断方法。
和前面讲的退订链接是同一个形状:你以为你在观测用户的行为,实际上你观测的是渲染层的行为。渲染层在中间做了什么,你既看不见也管不着。
那该看什么
| 指标 | 来源 | 可信度 |
|---|---|---|
| 投诉率 | Postmaster Tools | Gmail自己算的,是判据本身 |
| 域名与IP声誉 | Postmaster Tools | 同上 |
| 认证通过率 | Postmaster Tools | 同上 |
| 退信率 | 你自己的发送日志 | 服务端事件,不经过渲染 |
| 点击率 | 你的跳转统计 | 需要主动动作,比打开率硬 |
| 下单归因 | 订单系统 | 最硬,但样本最小 |
看板该放哪几个指标是有讲究的,DTC私域社群5维指标看板那篇给了一套可以直接抄的结构。
这张表的排序逻辑是离渲染层越远越可信。投诉率是Gmail在服务端记的,退信是SMTP层的事件,点击需要用户真的按下去,下单需要他走完整个流程。
点击率也不是完全干净的
安全网关会预扫描邮件里的链接,那些扫描会产生点击记录。企业邮箱环境下这种情况尤其多,有时候一封邮件里所有链接会在同一秒被全部访问一遍。
区分真人和机器这件事在日志分析里有成熟做法,5000站爬虫伪造与抓取预算实战那篇讲了几种识别手段。
识别办法是看时间分布:真实点击会散在几个小时里,扫描产生的点击会挤在投递后的几秒内,而且往往一封邮件的所有链接同时中招。把这类记录剔掉之后的点击率才是可用的。
这件事对邮件自动化流的影响
很多自动化流的分支条件写的是“未打开则48小时后重发”。如果打开率本身是失真的,这个分支就在按一个不可靠的信号给用户重复发邮件。
用一个不可靠的信号做分支判断,等于把误差乘进了每一次执行,A/B测试样本量怎么算才能避免假胜利那篇讲的是同类问题。
而重复发邮件正是投诉率的第二大来源。一个基于坏信号的自动化规则,会持续地、系统性地把邮件发给那些不想要的人。这比一次误发严重得多,因为它不会停。
怎么改这类分支
把判据从“未打开”换成“未点击且未下单”,或者干脆换成“距上次任何互动超过N天”。这两个替代信号都需要用户主动做点什么,比一次图片加载可靠。
把指标按能不能驱动生意分层,把社媒指标拆成四层漏斗那篇的分层办法可以照搬到邮件上。
代价是符合条件的人会变多——因为点击的人本来就比打开的人少。所以换判据的同时必须把重发的门槛提高,否则你只是让同一个坏规则跑得更凶。
一个更保守的做法
保哥现在给客户的建议是:把打开率留在报表里当趋势参考,但不允许它出现在任何一条自动化规则的条件里,也不允许它出现在任何一份对外材料上。
一个指标能不能用来做决定,取决于它的噪声有多大,SEO实验设计与统计功效那篇讲了怎么估这个噪声。
看趋势可以,做决定不行。一个失真方向未知、失真幅度未知的指标,只在与自己的历史比较时还有一点信息量,横向比和绝对值都不成立。
为什么打开率这个指标这么难被放弃
因为它是唯一一个又大又快又好看的数。点击率是个位数,下单归因是千分之几,只有打开率能报出百分之三四十,而且发出去两小时就有数。
好看又及时的数最容易被写进周报,一条五年趋势线上有三处口径变更那篇讲了这类数怎么慢慢失真。
一个既大又及时的指标,天然会被写进周报第一行。而它一旦进了周报,就会有人为它负责,有人为它负责就会有人优化它,优化它的动作会进一步扭曲它。
怎么优化会扭曲它
最典型的一种是给邮件加一张必须加载的图片,或者把追踪像素放到更容易被预取的位置。这些做法确实会让打开率变好看,而且不违反任何规则。
被优化的指标会离它想代表的那件事越来越远,两套报表算出相反的结论而且两套都没算错那篇拆过一个类似案例。
但它改变的是那次图片请求发生的概率,不是收件人真的读了邮件的概率。优化完之后这个指标和它想代表的那件事之间,距离更远了。
一个可以立刻做的替代
把周报第一行换成投诉率与退订率这一对。理由是它们有明确的阈值、由收件方计算、而且方向相反——投诉率涨而退订率跌,本身就是一个信号。
把两个相关的数放在同一张表上是最便宜的改动,数据分析师与SEO对账清单的7个动作点那篇有一整套这样的安排。
前面那个案例正是这么被发现的:如果那两个数一直并排放在同一行上,两个月里任何一次周报都能看出问题。把它们分开放在两张表上,就没有人会去做那道减法。
还有一件事官方没写但值得注意
图片代理服务会缓存邮件里的图片,这意味着同一封邮件的追踪像素在第一次被请求之后,后续的打开可能根本不会再发请求。
缓存会改变请求发不发这件事,服务器把没改过的页面对爬虫重发了几百遍那篇讲的是缓存的另一面。
所以打开率不仅方向不确定,它的失真程度还会随着邮件被打开的次数变化。一封被反复翻出来看的邮件,和一封只被扫一眼的邮件,在这个指标上的表现可能是一样的。
把这套逻辑推到别的指标上
打开率不是唯一一个观测链会在渲染层断掉的指标。页面停留时间取决于浏览器什么时候发出离开事件,视频播放完成率取决于播放器的上报逻辑,广告曝光量取决于可见性判定的实现。
平台不给你的那部分数据往往正是关键,AI搜索的归因数据平台为什么不会给你那篇讲了哪两层今天就能自己测。
共同特征是:你以为在量用户的行为,实际上量的是某个中间层的行为,而那个中间层的规则由别人定、随时会改、改了不会通知你。
一个简单的分级
| 指标类型 | 依赖什么 | 可信度 |
|---|---|---|
| 服务端事件 | 你自己的系统记的 | 最高 |
| 用户主动动作 | 用户真的按了一下 | 较高 |
| 渲染层推断 | 某个客户端决定要不要上报 | 低 |
| 第三方估算 | 别人的模型 | 只能看趋势 |
这张表可以直接拿去给你的报表分层:前两类可以用来做决定,后两类只能用来提出问题。混着用的后果是你会为一个不存在的变化去改一个本来没问题的东西。
顺便说一下报表该怎么改
不用推倒重来,只做两件事:把打开率那一列挪到表格右侧并标一个注脚,把投诉率和退订率并排放到第一列和第二列。
这两个动作加起来不到一小时,不需要任何开发。而它改变的是每周有多少人会不经意地看到那对关键数字,这个变化比任何一次培训都持久。
一个男士理容订阅站是怎么把投诉率养上去的?
这一节是实打实的复盘。品类是男士理容与剃须,订阅制,刀片每月寄一次,另外卖剃须膏、须后水和一款电动修剪器,主力市场是北美和英国,团队11个人。
症状是从一个不相干的地方冒出来的
不是投诉率报警——他们当时压根没在看Postmaster Tools。是月度复盘会上,负责邮件的同事提了一句:这个月的打开率比上个月低了将近5个点,标题也换了几版,都没拉回来。
客服那一侧经常最早接触到问题,DTC出海客服0到1怎么搭那篇讲了工单该怎么分流才不埋没信号。
会上的结论是内容疲劳,决定下个月换一批素材。这个结论完全说得通,也完全错了。
真正在发生的事
他们两个月前给邮件模板做了一次改版。改版的目标是让页脚更干净——原来的页脚有六行小字,包括地址、隐私政策、退订链接和一段法律声明,视觉上很杂。
改版是这类问题最集中的时点,改版不掉SEO的完整防护清单那篇的检查项可以直接扩展到邮件模板上。
设计师的处理很合理:把这几项收进一行,用分隔符隔开,字号从12px降到10px,颜色从深灰改成浅灰。改完之后页脚确实清爽了。
那次改版顺手做了另一件事
为了让那一行在深色背景上也好看,他们给页脚容器写了一个背景色。而在支持暗色模式的客户端里,这个背景色被强制反色成了深色,浅灰的文字没有跟着反。
设计侧的一次调整可能牵动很远的地方,网页设计师SEO协作的7个动作点那篇讲了这类协作该怎么建立。
结果是:在暗色模式下,那一行退订链接和背景是同一个色系,几乎看不见。而这件事在他们所有人的测试邮箱里都不会出现,因为团队里没有人用暗色模式看邮件。
破局的过程
不是排查出来的。是一个客服同事在处理工单时提了一句:最近有几个人在工单里问怎么才能不再收到邮件。
工单里藏着大量还没被读出来的信号,客服SEO协作7动作账本从工单到帮助中心那篇讲了怎么把它们捞出来。
她觉得奇怪的点很朴素——退订链接明明就在邮件里,为什么要专门开工单来问。她随手把自己手机的邮件应用切到深色模式看了一眼那封邮件,然后把截图发进了群里。
发现它的是一个不负责邮件的人,用的是一个不属于任何排查流程的动作:她只是想复现用户描述的场景。
拆开之后的账
| 指标 | 改版前 | 改版后第二个月 |
|---|---|---|
| 投诉率 | 0.04% | 0.21% |
| 退订率 | 0.31% | 0.12% |
| 打开率 | 基准 | 下降4.8个百分点 |
| 工单里问怎么退订的 | 0条 | 两个月累计23条 |
改动前后的对照要成立,前提是口径没变,30个A/B测试方案那篇里有几个跟模板改版直接相关。
最有信息量的是第二行:退订率掉了。他们当时甚至把这个当成好消息,因为退订率在他们的周报里是一个越低越好的指标。
那两个数是一枚硬币的两面
退订率从0.31%掉到0.12%,投诉率从0.04%涨到0.21%。掉的0.19和涨的0.17几乎一样多。
两个看起来无关的数放在一起才有意义,调研数据里没有一个非会员那篇讲的是另一种被切开看的错觉。
那些本来会点退订的人没有消失,他们只是换了一个按钮。而这两个数分别放在两张不同的报表上,一个在邮件平台的仪表盘里,一个在一个没人登录的Postmaster Tools里。
改了什么
三件事,按上线顺序:加上那两行信头(半天)、把页脚退订链接的颜色改成跟正文同一个色阶并加下划线(两小时)、给邮件模板加一套暗色模式适配(三天)。
入口和出口该一起改,邮件弹窗怎么设计才不招人烦又能多收邮箱那篇讲的是入口那一侧的分寸。
第一件的效果最快:上线后第一周投诉率就掉回0.09%,因为那些看不见页脚链接的人现在能在发件人名字旁边找到入口了。
代价
退订率从0.12%回到0.38%,比改版前还高了0.07个百分点。这个数字很重要,必须写出来:把退订入口做得更容易找,确实会让更多人退订。
短期数字变差长期指标变好,这类取舍要提前说清楚,出海独立站的社会证明体系怎么搭那篇里也有几处同样的账。
三个月后的账:列表规模比不修的情况下小了约4%,但同期邮件带来的下单数没有下降。因为退掉的那批人本来就不会买——他们已经决定不想收了,留在列表里只是在积累一次未来的投诉。
他们后来做的一件事
在退订确认页上加了一道单选题,问为什么退订,可跳过,五个选项加一个其他。三个月收上来1400多条,最高的一项是“频率太高”,占41%。
在出口处设一问是最便宜的信息来源,满意度问卷那个92%只覆盖了7.4%的买家那篇把这个做法的完整逻辑讲透了。
于是把每周三封降成每周两封,同时给一个改成每月一封的选项。这件事的收益不在退订率上,在于他们第一次知道了退订的人是因为什么走的——而这个信息只能在出口处收集。
这个案例里最该学的不是修法
是那个客服同事的动作:她想复现用户描述的场景,所以把手机切到了深色模式。
复现用户描述的场景往往比读日志更快,同一根手指要负责翻页、握住手机和下单那篇的问题也是这么被发现的。
这个动作不属于任何一条排查流程,也不需要任何专业知识。它唯一的前提是有人愿意把用户的描述当成一件需要复现的事,而不是一句需要回复的话。
工单里那23条是最早的信号
改版之后第三周就出现了第一条,而问题是两个月后才被发现的。也就是说这个信号在系统里躺了将近一个半月,被当成了普通咨询处理掉。
用户说出来的话里经常已经包含了答案,她对着手背比了半天色号那篇讲的是没被听见的那一类需求。
不是客服失职。一条问怎么退订的工单,孤立地看确实就是一次普通咨询;它变成信号的前提是有人注意到这类工单从零变成了每周三四条。而工单系统里默认没有人在看这个变化率。
后来他们加了一条规则
把工单按意图分类,其中一类叫做“想终止但找不到入口”,涵盖退订、取消订阅、删除账号、关闭通知。这一类的数量一旦周环比翻倍就自动提醒。
这个规则半年里触发过两次,第二次是App推送设置改版之后。它的价值在于把一批本来分散在不同话题下的工单,按用户意图重新归了一次类。
为什么按意图归类比按话题归类有用
按话题归类的话,问退订的进“邮件”,问取消订阅的进“订阅管理”,问删除账号的进“账号问题”,三个数字分别都很小,谁也不会注意到。
按意图归类之后它们变成同一个数,而这个数一旦有波动,指向的一定是某个出口出了问题。归类方式不改变数据本身,只改变它能不能被看见。
这次复盘留下的两条固化
第一条:任何影响邮件模板的改动,上线前必须在深色模式下看一眼。写进了他们的发布检查清单,只有一行字,不需要工具。
把一件事固化成默认呈现比固化成动作可靠,新网站SEO目标管理的3里程碑加量化任务清单那篇讲的是同一种思路。
第二条:投诉率与退订率必须并排出现在同一张周报上。这一条比第一条更重要,因为它不依赖任何人记得去做什么。
为什么第二条更重要
检查清单靠人执行,执行者会疲劳、会离职、会在赶工期的时候跳过。报表不会——只要那两个数在同一行上,任何一个看周报的人都可能做那道减法。
什么被放在第一屏决定了什么会被看见,首页首屏的导航、主Banner到分类区怎么设计那篇讲的是页面上的同一个道理。
凡是能做成默认呈现的,就别做成需要执行的动作。这条经验在很多地方都成立,只是在这里格外明显:同一个问题,一个靠人记得去看深色模式,一个靠两个数字挨着放。
他们没做成的一件事
本来想给所有邮件模板做一套完整的客户端兼容性测试,接了一个测试服务,第一个月跑了十几封,第二个月就没人跑了。
价值和操作成本不在一个数量级的事做不长久,11个按性价比排序的速赢清单那篇的排序逻辑正是为了避开这类。
原因很实在:每次跑要等十几分钟,出来几十张截图,而其中真正有问题的那一两张需要人一张张翻。不是没价值,是价值和操作成本不在一个数量级上,最后被那两条一行字的固化替代掉了。
除了退订,还有哪些出口会被截断?
把判据推广开来:凡是用户用来终止一段关系的入口,都值得按同一套标准检查一遍。
先把出口列出来
| 出口 | 典型位置 | 失效之后用户会怎么做 |
|---|---|---|
| 邮件退订 | 邮件页脚与信头 | 点举报垃圾邮件 |
| 短信退订 | 短信正文末尾 | 向运营商投诉或拉黑号码 |
| 推送关闭 | App设置页 | 直接关掉系统级通知权限 |
| 订阅取消 | 账户页 | 找银行拒付 |
| 账号删除 | 账户设置深处 | 投诉到监管或平台 |
| 授权撤回 | 隐私设置 | 提交正式的数据删除请求 |
一条流程里被忽略的那个角色最容易出事,买家勾了这是礼物可你的链路只认得买家一个人那篇是个典型。
最后一列是关键。每一行的替代动作都比原动作代价大得多,而且都不可逆。银行拒付会留下记录,系统级通知权限一旦被关几乎不可能要回来。
短信这条线更硬
短信没有信头层可用,退订完全依赖正文里那几个字,而短信正文有长度限制,超长会被拆条。一条被拆开的短信,退订说明很可能落在第二条上,而第二条不一定会被读到。
字符数和字节数在多语言场景下经常对不上,900个表情的字符数、字节数与跨设备真相那篇量过这件事。
实操上的做法是把退订说明放在第一条能容纳的长度之内,而不是习惯性地放在末尾。这一条跟前一篇讲的把关键内容往前排是同一个道理。
推送关闭那一层的陷阱
App内的推送开关如果藏得太深,用户会直接去系统设置里关掉整个应用的通知权限。这两个动作的区别是:前者你还能发交易类通知(发货、退款),后者你什么都发不了。
App里的默认配置和网页侧经常不一致,移动网页上79%的站放了提交按钮你的App里只有10%那篇量过这个差距。
把推送开关按类型拆开、放在设置页第一屏,损失的是营销推送的到达;藏起来,损失的是所有推送的到达。这笔账几乎不需要算。
订阅取消那一层的代价最大
一个找不到取消入口的订阅用户,最后往往会去发卡行发起拒付。拒付率是支付通道的核心风控指标,累积到一定程度会影响你的收单资格。
这条链和邮件那条完全同构:一个页面层面的可用性问题,最后落在一个决定你能不能继续做生意的账户指标上。中间同样没有任何环节会预警。
怎么统一检查
用同一个问题过一遍:这个入口在最差的渲染条件下还找得到吗。最差的渲染条件包括暗色模式、图片不加载、样式被剥离、屏幕最小、字体放大到最大、只用键盘。
最差渲染条件这类测试有一套现成的清单,从响应式到Core Web Vitals的3类站点改造对比那篇给了对照。
六种条件,每种花不了两分钟。先测终止类入口,测完再说别的。
一条反直觉的经验
把终止类入口做得更容易找,短期指标一定会变差:退订率会涨、取消率会涨、通知开启率会掉。这些数字通常都在某个人的考核里。
短期数字变差的改动最难推动,出海独立站产品到底该定什么价那篇里的定价调整也面临同样的阻力。
所以推动这件事的时候,最好提前把对照指标准备好:退订率涨的同时投诉率会掉,取消率涨的同时拒付率会掉,而后面那两个才是决定生死的。把两组数放在同一张表上,这件事才推得动。
还有一类出口容易被完全遗漏
用户已经不在你的系统里,但你还在发。比如账号注销之后邮件列表没同步,比如退款完成之后自动化流没停,比如退订生效了但另一个系统里的名单没更新。
多系统的数据不同步是个结构性问题,客户数据平台CDP到底是什么那篇讲了什么阶段该上、怎么选。
这类情况用户是完全没有出口的——他连一个可以点的按钮都没有。他唯一能做的就是举报,而且他会做得非常坚决。
怎么找出这一类
翻一遍所有会触发对外发送的系统,看它们各自的收件人名单是从哪里取的。只要有两个以上的取数来源,就一定存在不同步。
画一张连线图就能发现结构上的断点,独立站架构搭错了谷歌爬虫根本找不到你的产品页那篇用的是同一种方法。
这个检查不需要任何工具,画一张图就行:左边列出所有发送渠道,右边列出所有名单来源,连线;只要有一条线连到的不是同一个退订状态字段,那条线就是漏洞。
把这件事写进上线检查
新增一个发送渠道、接入一个新的营销工具、上线一条新的自动化流,这三件事之后都要重新画一次那张图。
新工具接进来的时候最容易漏掉数据流向,DTC品牌AI工具栈怎么搭那篇的12款测评里也提过接入时该问什么。
理由是这类系统的接入通常很快——装个应用、连个接口,半天就能跑起来。而它带进来的那份名单从哪来、退订状态跟谁同步,往往在接入的那一刻没有人问过。
把出口画在同一张图上
做完前面那张连线图之后,还有一张更有用的图:把每个出口和它失效之后用户会去做的那件事画成箭头,箭头指向的都是一个你不想去的地方。
一次不合适的推荐会连累整个推荐位的可信度,购物车里推错一次配件那篇讲的是信任被消耗的另一条链。
画完你会发现一个共同点:所有替代动作的终点,都是一个由第三方掌握的、你没有申辩机会的记录。投诉率在Gmail那边,拒付率在发卡行那边,通知权限在操作系统那边。
这解释了为什么这类问题特别贵
因为修复它需要的不只是改代码,还需要等那个第三方的记录慢慢恢复。投诉率是滚动窗口统计,改完要两到四周才见效;域名声誉一旦掉下去,恢复期以月计。
恢复周期由别人决定这件事在收录上也一样,提交了为什么还不收录那篇讲的是另一个你等不起的队列。
你的修复速度不由你决定,由那个记录的更新周期决定。这跟站内的问题完全不同——站内的问题改完刷新一下就好了。
所以优先级排法要变
常规的排法是按影响面乘以严重程度。对这类问题得加一个乘数:恢复周期。
| 问题类型 | 修复后见效 | 该排在哪 |
|---|---|---|
| 页面显示错误 | 立刻 | 按影响面排 |
| 转化路径断点 | 下一批流量 | 按影响面排 |
| 投诉率相关 | 两到四周 | 提前一档 |
| 域名声誉相关 | 一到三个月 | 提前两档 |
| 支付通道风控 | 不确定,可能不可逆 | 最高优先级 |
最后一行值得单独说
支付通道的风控是唯一一个可能完全不可逆的。拒付率超标导致的通道关闭,换一家重新开户的成本远远高于所有前面几项之和。
平台侧的规则变化可能直接决定你还能不能做,Meta广告iOS 14归因失真怎么救那篇复盘过一次这样的冲击。
而它的起点,可能只是订阅取消按钮藏得深了一点。这条链上的第一环和最后一环之间,隔着一整个业务的连续性。
顺带说一下短信那条线的字数账
纯英文短信单条160个字符,含中文的短信单条70个字符。超过就拆条,而拆条之后每一条都单独计费、单独投递、单独可能被拦。
多语言场景下每加一门语言都要多一整份数据,站上加一门语言是加一套模板那篇讲了这份额外成本。
把退订说明放在开头的代价是占掉宝贵的前几十个字符,收益是它一定会被投递到。这笔账在中文短信里尤其紧张,70个字符里拿出8个写退订说明,等于少了一成多的正文空间。
那有没有折中办法
有。把退订说明压缩成最短的可理解形式,放在第一条的末尾而不是整封的末尾。这样它既在第一条里,又不占开头的位置。
把关键信息放在哪个位置是内容设计的核心问题,把内容当产品来设计那篇讲了这套思路。
关键是要意识到“末尾”这个位置在多条短信里是个陷阱:你以为的末尾是整封的末尾,投递单位的末尾是每一条的末尾。这跟前一篇里字节截断的道理一模一样,只是单位从字节换成了条。
还有一个没有出口的场景
用户换了邮箱、换了手机号、注销了账号,而你的系统里那条记录还在。他不会来找你退订,因为他已经收不到了;那些邮件会一直发到一个没人看的地址,直到退信。
这类地址不会产生投诉,但会持续拉低你的送达率,而送达率是收件方判断你发信质量的输入之一。官方建议对多次退信的收件人自动退订,正是为了这一类。
实操上把阈值设成连续三次硬退信就自动移除,这个规则一年清掉的量通常比你想象的多。清掉之后所有比例类指标都会变好看,而这一次的变好看是真的。
这份检查清单怎么落到发送流程里?
诊断讲完了,这一节给可执行的部分。仍然按“做完能不能一劳永逸”排序。
六件自查动作
第一件带早停:给自己发一封上周发过的群发邮件,查看原始邮件,搜索List-Unsubscribe。两分钟。两行都在、值都对的话,你已经躲过了本文说的最大那个坑,后面五件的紧迫性大幅下降。
带早停的清单比一口气做完的清单更容易被执行,谷歌SEO技术清单的5大核心方向那篇也是这么排的。
第二件:登录Postmaster Tools看投诉率。十分钟,包括第一次验证域名的时间。这一步不改任何东西,但它决定了后面所有动作的优先级。
第三件:把手机邮件应用切到深色模式,看一眼你最近发的那封。三分钟。这个动作的性价比高得离谱,因为团队里通常没有人做过。
第四件:手工往你的退订地址发一个POST请求,确认后端真的接住了。半小时。信头写对和后端处理对是两件事。
第五件:画一张发送渠道与名单来源的连线图。半天。只要有两条线连到不同的退订状态字段,就找到了一个漏洞。
第六件:把所有自动化流里以打开率为条件的分支翻出来。一天。这一件不紧急,但它是唯一一个能持续制造问题的地方。
卡点挂在哪里
前面六件都是一次性的。要让这件事不复发,得有一道东西挡在发送动作前面。
把检查交给程序而不是交给记性,把sitemap、排名和清缓存交给定时任务那篇给了具体写法。
保哥用的做法是在发送前加一道闸门:群发任务提交之后、真正开始投递之前,程序自己检查这封邮件的信头里有没有那两行、正文里有没有一个锚文本包含退订字样的链接。任何一项缺失就不许发。
| 检查项 | 判据 | 不通过时 |
|---|---|---|
| List-Unsubscribe-Post信头 | 值等于List-Unsubscribe=One-Click | 阻断发送 |
| List-Unsubscribe信头 | 存在且是一个https地址 | 阻断发送 |
| 正文退订链接 | 锚文本含退订字样且不是图片 | 阻断发送 |
| 退订链接的文字颜色 | 与背景色对比度不低于4.5比1 | 警告并要求确认 |
为什么是闸门而不是别的形式
因为这件事的失败是不可逆的。邮件一旦发出去就收不回来,投诉一旦产生就记在了档案里。凡是不可逆的动作,卡点必须挡在动作前面,事后留痕对它没有意义。
事前拦截和事后排查的成本差得很远,Screaming Frog全站审计的12类问题排查清单那篇讲的是事后那一套。
这跟上一篇讲的构建断言是同一个逻辑,但严格程度更高:构建失败可以重跑,群发失败只能等下一次。
最后那一项为什么只警告不阻断
对比度这个判据有误报。深色背景配浅色文字同样可以达标,而机械地比较两个色值会漏掉背景图、渐变和暗色模式下的反色。
提示和命令是两回事,混淆了就会有人绕开,canonical标签是提示不是命令那篇列了8种误用。
一个会误报的检查如果设成阻断,第三次误报之后就会被人绕过去。设成警告加确认,它就一直能活着。这个取舍在做任何自动检查的时候都成立。
怎么跟人说这件事
说“页脚的退订链接看不清”效果有限,因为负责设计的同事手上有一版看得很清楚的稿子,在他的环境里那个链接确实没问题。
跨职能沟通有一套通用的开场方式,法务SEO协作7动作点那篇里那几句可以直接照搬。
保哥用的说法是:这两个月投诉率从0.04%涨到了0.21%,同期退订率从0.31%掉到0.12%,这两个数加起来几乎没变。我在深色模式下看了一眼页脚,截图在这里。我想先加上那两行信头,加完再看一次这两个数。
两个数、一张截图、一个提议。没有一个字说页脚设计得不好,只是把一件事的两个侧面摆在了同一张纸上。
护住所有人的第二句
这次改版本身是对的,页脚确实更干净了;问题在于我们从来没有一个环节会去看深色模式下长什么样。把焦点从人挪到“缺少一个检查环节”上,添一个检查环节是没人需要反对的事。
把焦点从人挪到缺少的那个环节上,前端工程师SEO协作的7个动作点那篇整理过这类协作的说法。
四条边界
第一条:这套做法只解决“能不能找到”,不解决“想不想收”。一个退订入口做得再好,也救不了一个内容本身没人要的列表。投诉率高的第一大原因始终是发得太多太不相关。
第二条:投诉率是滞后指标。改完之后它不会立刻回落,因为它是一个滚动窗口的统计。前面那个案例第一周就见效属于运气好,正常要两到四周。
第三条:本文的数字来自2026年8月的官方文档,规则一直在动。2024年2月那一版之后已经有过调整,之后还会有。可以长期用的是那条判据——终止类入口不能依赖渲染,不是任何一条具体规定。
第四条,也是最容易被忽略的:把退订做得容易之后,你的列表会变小,而列表规模在很多团队里是一个被单独考核的数字。如果不提前把这件事说清楚,第一个月的数据一出来,这套改动就会被要求回滚。
最后一句
这件事的检查成本是两分钟,代价是整个发件域名的投递能力。符合这两个条件的事情很少,遇到一件就先做掉,不用排进季度计划。
这套做法和上一件事的关系
本文说的是邮件里的出口,前面还有一篇说的是HTML文档里的关键内容。两者的形状完全一样:一个东西存在,但在某个层被截断了,而截断不产生任何错误信号。
网页那一侧的截断有现成的检查工具,抓取体积检查器与Googlebot上限实测那篇讲了怎么用。
解法也一样:把重要的东西放到那个不会被截断的层里去。在HTML里是往文档前面排,在邮件里是往信头里放。两处的成本都很低,两处的后果都很重。
还有第三种同形状的问题
短信被拆条之后退订说明落在第二条上,推送通知被系统折叠之后关键操作按钮不出现,App内弹窗在小屏上关闭按钮跑到屏幕外。
这三个都是同一个模式的不同现场。共同判据只有一条:这个东西的可见性,取决于一个你控制不了的层做了什么。只要答案是肯定的,就得给它准备第二条路。
怎么找出这类问题
问自己一个问题:这条信息从我这里出发,到用户眼睛为止,中间经过了几个我说了不算的环节。
搞清楚一条信息经过了哪几个层,搜索引擎抓取和渲染DOM分几步那篇把网页那条链拆得很细。
邮件经过的是邮件客户端,短信经过的是运营商和短信应用,推送经过的是操作系统,网页经过的是浏览器和搜索引擎的渲染服务。经过的环节越多,你越需要一条不经过它们的备用路径。
本文自己的边界再说一遍
这套方法解决的是“能不能找到”,不解决“想不想收”。一个内容本身没人要的列表,退订入口做得再好也救不了;它只是让那些要走的人走得体面一点,而不是留下来。
投诉率高的第一大原因始终是发得太多太不相关,本文说的这一切都排在它后面。如果你的投诉率已经很高,先去看发送频率和分群,再回来看这一篇。
一句话总结这三篇的共同点
网页里被截断的是字节,邮件里被截断的是显示,短信里被截断的是条数。三个现场的单位不一样,机制完全一样:系统在某个位置停下来,停下来之后的东西对下游而言不存在,而两端的记录都显示这件事完成了。
能对抗它的动作也只有两种:把重要的东西挪到截断点之前,或者把它挪到一个不会被截断的层里去。前者是排序问题,后者是分层问题,两者都不需要多花钱。
最后留一个可以马上做的动作
打开你最近发出去的那封群发邮件,查看原始内容,搜一下List-Unsubscribe。整个动作两分钟,而它回答的是一个足以决定你邮件业务能不能继续的问题。
如果搜不到,今天就把那两行加上;如果搜得到但只有一行,把另一行也补上。这是本文里唯一一件不需要跟任何人商量、不需要排期、不需要预算的事。
常见问题解答
正文里已经有退订链接了,还需要写信头吗?
需要,而且这不是二选一。Gmail官方原文用的是并列句:营销类与订阅类邮件必须支持一键退订,并且在邮件正文里包含一个清晰可见的退订链接。要两层的理由不是多一份保险,是这两层的失效方式完全不重叠——正文那层要经过渲染,会被裁剪、被暗色模式吞掉、被样式剥离;信头那层不参与渲染,它唯一的失效方式就是你没写。
每天发不到5000封,是不是就不用管一键退订?
字面上是,实操上不建议。5000这条线按发件域名算,一次大促群发就能把你推进那一档,而且之后一直按大批量发件人的标准要求。另外这份要求管的是发到Gmail个人账号的邮件,但Google Workspace走同一套反垃圾体系,其他主流邮箱服务商这两年也陆续对齐了。把它当成行业底线来做,不用去算自己在哪一档。
退订率涨了怎么跟老板交代?
提前把对照指标准备好。把退订入口做得容易找,退订率一定会涨,这是必然的;同时投诉率会掉,而投诉率是决定你整个域名能不能投递的那个数。保哥经手的案例里,退订率从0.12%回到0.38%,投诉率从0.21%掉到0.09%,三个月后列表小了约4%而邮件带来的下单数没降——因为退掉的那批人本来就不会买。
为什么一键退订不能弹一个确认页?
因为一键这个词定义的是语义不是速度:一次交互完成,没有第二步。用户已经在邮件客户端上点过一次了,那一下就是他的确认。再加一步等于把这条路又变回了正文链接那条路,前面所有的努力白费。技术上表现为你的地址收到的是一个POST请求,请求体只有一行,它期待的是立即生效而不是返回一个页面。
Google说不追踪打开率,我的邮件报表还能看什么?
按离渲染层由远到近排:投诉率、域名与IP声誉、认证通过率这三个来自Postmaster Tools,是Gmail自己算的;退信率来自你的发送日志,是SMTP层事件;点击率需要用户主动按下去,比打开率硬但要剔掉安全网关的预扫描;下单归因最硬但样本最小。打开率可以留着看趋势,但不该出现在任何一条自动化规则的条件里。
怎么判断点击是真人还是安全网关扫的?
看时间分布。真实点击会散在投递后的几个小时甚至几天里;扫描产生的点击往往挤在投递后的几秒内,而且一封邮件里所有链接会在同一秒被全部访问一遍。把符合后一种特征的记录剔掉之后的点击率才是可用的。这类扫描在企业邮箱环境下特别多,如果你的客户以B2B为主,不剔干净会把点击率整个抬高一截。
偏好中心能不能替代退订按钮?
不能,官方文档明确写了这类选项可以作为补充但不能替代一键退订。偏好中心恰恰是最常见的替代方案:把退订按钮换成管理订阅偏好,跳到一个有六个复选框的页面。用户想要的是停下来,你给了他一份问卷。正确做法是两者并存,退订放在最显眼的位置,降频和分类选项放在它旁边作为替代品。
退订之后多久必须生效?
两天内。这条写在订阅管理那一节里,不在准入要求清单上,但它是投诉率的直接来源之一——一个已经点过退订还在收到邮件的人,下一次一定去点举报。实操上意味着退订处理不能走人工审核,也不能挂在每周跑一次的同步任务上。更隐蔽的一种踩线是多系统不同步:退订写进了邮件平台,但群发名单是从订单系统导出来的。
权威参考资料
本文标题:《一键退订必须写两层,少一层Gmail就把你整个域名限流》
本文链接:https://zhangwenbao.com/one-click-unsubscribe-header-body-two-layers.html
版权声明:本文原创,转载与引用请注明作者与原文链接。许可协议: CC BY 4.0
← 上一篇
AI内容披露怎么写?不做什么的清单比做什么的更可核查下一篇 →
没有了