对于 ESP（Email Service Provider）来说，邮件打开率长期以来都是最重要的用户行为指标之一。传统实现非常简单：在邮件 HTML 中插入一个 1×1 像素的远程图片，用户打开邮件时，邮件客户端加载这张图片，ESP 的服务器收到 HTTP 请求，就可以认为邮件发生了一次“打开”。

典型实现如下：

<img src="https://track.example.com/t/{message_id}.gif" />

用户打开邮件后，客户端请求这个隐藏的 1 像素图片，ESP 就会收到这个请求，再根据 message_id、请求时间、IP、User-Agent 等信息记录一次 Open Event。对于早期邮件营销系统而言，这种方式成本低、实现简单，而且能够进一步统计打开率、首次打开时间、打开次数等指标。

但这种模式有一个天然缺陷：它实际上追踪的是“远程资源被请求”，而不是“用户阅读了邮件”。

一、主流 ESP 过去是如何实现 Open Tracking 的？

传统邮件追踪通常由三部分组成。

第一部分是 Tracking Pixel。ESP 在邮件 HTML 中插入唯一图片 URL，通过 message_id 或随机 Token 区分不同邮件和收件人。
第二部分是 Tracking Gateway。邮件客户端请求图片时，流量进入 ESP 的 Tracking Server，系统记录 IP、User-Agent、时间、邮件 ID、收件人 ID 等信息，并返回一个透明 GIF。
第三部分是 Event Pipeline。Tracking Server 将 HTTP 请求转换为 open 事件，再进入消息队列、数据库以及统计系统，最终形成 Campaign Open Rate、Unique Open Rate 等指标。

因此，传统模型实际上是：

Email Delivered
       ↓
User opens email
       ↓
Mail Client loads image
       ↓
ESP Tracking Server
       ↓
open_event
       ↓
Open Rate

这个模型成立的前提是：邮件客户端只有在用户真正打开邮件时才加载远程图片。
问题恰恰出在这里。

二、Mailbox Provider 开始改变游戏规则

传统追踪像素不仅可以判断用户是否打开邮件，还可能通过请求时间、IP 地址、设备信息等推断用户的活动时间、网络环境和大致位置。

近年来，主流 Mailbox Provider 和邮件客户端越来越重视用户隐私保护。Apple Mail 的 Mail Privacy Protection 就是典型案例：远程邮件内容可能由 Apple 的基础设施提前获取，而不是等用户真正打开邮件之后再请求。Gmail 等服务也广泛使用图片代理机制。这样一来，ESP 看到的 HTTP 请求可能来自邮箱服务的代理服务器，而不是用户设备。

这么调整的核心目的，是降低邮件内容加载过程中暴露给发送方的用户信息。

总之，这意味着传统方案中，追踪像素请求 = Open 的逻辑失效，这类隐私保护机制，会产生大量“机器加载”，如果 ESP 继续把这些请求全部计算为 Open，就会导致打开率越来越失真。

当然，ESP 也可以继续与这套机制对抗，正所谓“道高一尺，魔高一丈”。但这种对抗本质上是在试图绕过用户主动选择的隐私保护机制，无论从合规要求，还是从保护用户隐私权益的长期趋势来看，都并不合适。

即使技术上能够通过更加隐蔽的请求、设备指纹等手段重新获取部分信号，Mailbox Provider 也会持续升级代理、缓存和反追踪策略，最终形成一场没有终点的技术军备竞赛。对 ESP 而言，这不仅意味着持续增加研发和运维成本，也可能带来合规风险、用户信任问题以及数据准确性下降。

因此，与其不断寻找绕过隐私保护的办法，不如接受邮件行为可观测性下降这一现实，将技术重点转向 Click、Reply、Conversion 等用户主动行为，并通过多种信号建立更加可靠的 Engagement 模型。

三、应该对 Open Tracking 做必要调整

邮件发送的时候追踪链接中编码了一些基础信息

在现有 open_event 的基础上增加请求来源和流量识别信息。

{
    "event": "open",
    "user_id": 1,
    "message_id": "msg_123",
    "sender_addr": "foo@example.com",
    "recipient_id": "bar@example.com",

    "ip": "111.111.111.111",
    "ip_info": {
        "country": "",
        "province": "",
        "city": "",
        "isp": "",
        "timezone": ""
    },

    "ua": "...",
    "ua_info": {
        "ua_type": "",
        "ua_version": "",
        "system_type": "",
        "system_version": "",
        "device_type": "",
        "device_model": "",
        "device_fingerprint": ""
    },

    "source": "apple_mpp"
}

打开事件只表示一个客观事实：邮件中的远程资源发生了一次请求，不等同于“用户打开了邮件”。

其中 source 可以记录 ESP 对请求来源的识别结果，例如：

• Apple MPP
• Gmail Image Proxy
• Security Scanner
• Antivirus
• Corporate Gateway
• Prefetch
• Unknown Bot

Provider Fingerprint 和 Traffic Classifier 对原始数据进行分析，综合以下信息判断请求来源：

• IP 地址、网段及 ASN
• User-Agent
• HTTP Headers
• 请求时间
• 请求频率
• Provider 特征
• 历史请求模式

经过识别后，ESP 可以将大量已知机器请求从用户行为统计中剥离出来，得到一个 Human-like Open Rate（类人工打开率）。
需要注意的是，Human-like 并不等于真实打开。它只是排除了已识别的机器流量后，表现出类似人工访问特征的内容加载请求，因此仍然属于一种估计指标。

四、从“打开率”转向“参与度”

当 Open Tracking 逐渐失去准确性之后，ESP 不应该继续把所有注意力集中在“如何恢复准确的 Open Event”，而应该逐渐转向更广义的 Engagement。

邮件参与行为可以包括：

• content_load_event：ESP 记录的追踪像素等远程资源加载事件
• machine_event：ESP 根据请求特征识别出的机器加载事件
• click_event：ESP 记录的邮件链接点击事件

• reply_event：ESP 记录的邮件回复事件

• 点击邮件中的按钮或者链接之后，用户还可能在客户自己的业务系统中产生更多行为，例如：

  • website_session：进入客户网站并产生访问会话
  • form_submit：提交表单
  • download：下载文件
  • conversion：完成留资、注册、购买等业务转化

  PS：这些业务事件通常掌握在客户自己的系统中，并不是 ESP 默认能够获取的。如果 ESP 提供 Landing Page、自动化营销、Web SDK 或 Conversion API 等能力，客户可以将这些事件回传给 ESP，从而建立完整的邮件行为归因链。

其中最典型的仍然是 Click Tracking。与邮件客户端或邮箱服务自动加载图片不同，正常情况下 Click 代表收件人进行了主动操作，因此它比单纯的 Tracking Pixel 请求更有价值。当然，安全扫描器也可能自动访问邮件中的链接，因此 Click 同样需要进行机器流量识别。