
最近的Apple Mail Privacy Protection变更让我们想知道——类似的情况还会在哪出现呢?虽然虚假打开的情况并不令人惊讶,但我们有更多细节说明Gmail用户在接收的电子邮件中Gmail预取图像的有限情况。
Business in a box.
探索我们的解决方案。
与我们的销售团队交谈
Gmail 正在预取图像,导致打开次数略微增加
Apple Mail 隐私保护的最近更改让我们想知道——还有哪些地方在进行预取?虽然 假 打开 并不令人惊讶,但我们有关于 Gmail 在发送给 Gmail 用户的电子邮件中预取图像的情况的更多详细信息。
Gmail 预取打开在以下情况下发生:
Gmail 收件人已登录并且对 Gmail 应用程序(无论是网络还是移动应用程序)有一个活动的会话打开。
在会话活动/打开期间向 Gmail 收件人发送电子邮件。
Gmail 会在用户界面显示电子邮件之前立即预取所有图像。
此图像预取与 Google Image Cache 打开不同,它发生在用户打开电子邮件时。
只有当用户登录到 Gmail 应用程序时才会发生图像预取,图像来自 Google IP 地址,并使用以下用户代理字符串进行请求:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246 Mozilla/5.0
在调查了数十亿次开放事件后,我们可以自信地说,这些打开是虚假打开,不表示实际的用户打开事件。这些打开事件是独立的,并且与由 Google Image Cache 触发的用户发起的打开事件不同。
Gmail Prefetch Impacts
如何检测和忽略 Gmail 预取打开
对于 SparkPost 的发件人,我们已为您提供支持。我们已更新了事件 API 和事件 webhooks,以使用新引入的is_prefetched标志自动识别这些 Gmail 预取事件。我们还在积极努力在我们的分析报告 UI 和指标 API 中添加区分预取和代理打开的功能。请继续关注有关报告 UI 增强的未来更新。
对于其他人,检测 Gmail 预取打开仍然相对简单。对于每个打开事件,您将需要忽略(或唯一标记)任何符合以下用户代理字符串的打开事件:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246 Mozilla/5.0
我们已经能够确认此字符串是 Google 的 Prefetch Bot 所独有的。
Gmail Prefetch 详细分析
如上所述,Gmail 的预取仅在有限的情况下发生。其他邮件客户端不会发生预取。这种行为仅在 Gmail 用户在网页浏览器中打开 Gmail 应用或积极使用移动应用时出现。 我们最佳的猜测是这是在用户浏览器中显示电子邮件之前进行的安全扫描。
下方详细列出了图像请求的完整请求标头。您将注意到几件事情:
引用来源(referer)被设置为 http://mail.google.com。有趣的是,即使用户在 https:// 上,Gmail 仍然在发出请求时将引用来源设置为 http:// 协议。
请求来自 Gmail 的服务器,而不是用户的浏览器。客户端 IP 始终解析为 Google 拥有的 IP 空间。
与 Google 图像缓存不同,用户代理字符串没有标识请求来自 Google 的机器人之一。相反,用户代理字符串看似一个实际的用户图像请求。但是,我们已确认此用户代理字符串确实标识了 Google 预取机器人。
打开请求发生在邮件传递后的几秒钟内。此外,该请求发生在电子邮件出现在用户的 Gmail 界面之前。这种行为使我们相信请求是出于安全目的。
预取似乎仅发生在未读的 Gmail 邮件线程中。经过广泛测试后,一旦用户阅读了消息,任何进入该线程组的未来邮件都不会启动预取请求。
此预取与 Google 图像缓存分开。我们的测试表明,即使在图像被预取之后,当用户打开电子邮件时,仍会发出单独的 Google 图像缓存请求。
如果用户打开了 Gmail 移动应用,即使在关闭移动应用后,预取仍会在短时间内继续发生。
以下是从 Google 预取机器人请求图像时请求标头的示例:
正如 Apple 的邮件隐私保护情况下的情况一样,发件人应谨慎对待所有打开事件。打开只是发件人应该监控和包括在对用户参与度进行判断时需要考虑的众多参与指标之一,通常不是最好的一个。