Gmail précharge des images, ce qui entraîne des ouvertures légèrement gonflées

Les récents changements concernant la protection de la vie privée de Mail d'Apple nous ont amenés à nous demander : où d'autre se produit la précharge ? Bien que les ouvertures fausses ne soient pas une grande surprise, nous avons des détails supplémentaires sur l'ensemble limité de circonstances dans lesquelles Gmail précharge des images dans les e-mails envoyés aux utilisateurs de Gmail. 

Les préouvertures Gmail se produisent dans les circonstances suivantes :

1. Un destinataire Gmail est connecté et a une session active ouverte dans l'application Gmail (que ce soit l'application web ou mobile).

2. Un e-mail est envoyé au destinataire Gmail pendant que sa session est active/ouverte.

3. Gmail précharge toutes les images immédiatement avant que l'interface utilisateur n'affiche l'e-mail.

4. Cette précharge d'image s'ajoute à (et diffère de) Google Image Cache ouvertures, qui se produit lorsque l'utilisateur ouvre l'e-mail.

La précharge d'images ne se produit que lorsque l'utilisateur est connecté à l'application Gmail, provient d'une adresse IP de Google et est demandé à l'aide de la chaîne de l'agent utilisateur suivante :

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

En examinant des milliards d'événements d'ouverture, nous pouvons affirmer avec confiance que ces ouvertures sont de fausses ouvertures et ne signalent pas un véritable événement d'ouverture par un utilisateur. Ces événements d'ouverture sont indépendants et distincts des événements d'ouverture déclenchés par Google Image Cache.

Impacts de la précharge Gmail

Quelles sont les implications des fausses ouvertures sur Gmail ? Heureusement, elles sont mineures et loin d'atteindre l'échelle de Apple Mail Privacy Protection. 

En examinant plus de 9,8 milliards d'événements d'ouverture de destinataires Gmail en décembre 2021, pour la plupart des expéditeurs, nous avons constaté que les fausses ouvertures représentaient entre 1 et 6 % des événements d'ouverture. Ce que cela signifie, c'est que votre taux d'ouverture peut être gonflé jusqu'à 2 points de pourcentage. Par exemple : Si vous avez actuellement un taux d'ouverture global de 20 % sur Gmail, votre taux d'ouverture correct serait plus proche de 18 %.  

Votre taux de fausses ouvertures spécifique peut être significativement supérieur ou inférieur à ce que nous rapportons ci-dessus. Parce que les fausses ouvertures sont déclenchées en fonction du moment où les utilisateurs utilisent l'application Gmail, le comportement et les cas d'utilisation de votre audience spécifique sont les principaux facteurs qui détermineront votre niveau d'impact par rapport à cette anomalie.  

Comment détecter et ignorer les ouvertures préchargées de Gmail

Pour les expéditeurs de SparkPost, nous avons tout prévu. Nous avons déjà mis à jour notre API d'événements et nos webhooks d'événements pour identifier automatiquement ces événements de précharge Gmail à l'aide du nouveau is_prefetched drapeau. Nous travaillons également activement à ajouter la capacité de distinguer les ouvertures préchargées et proxy dans notre interface de rapport Analytics et notre API Metrics. Restez à l'écoute pour les futures mises à jour concernant les améliorations de l'interface de rapport.

Pour les autres, la détection des ouvertures préchargées de Gmail est encore relativement simple. Pour chaque événement d'ouverture, vous voudrez ignorer (ou taguer de manière unique) tout événement d'ouverture qui correspond à la chaîne d'agent utilisateur suivante :

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

Nous avons pu confirmer que cette chaîne est unique au bot de précharge de Google. 

Analyse détaillée de la précharge Gmail

Comme détaillé ci-dessus, la précharge Gmail ne se produit que dans un ensemble limité de circonstances. La précharge ne se produit pas avec d'autres clients de messagerie. Au lieu de cela, ce comportement est spécifique au moment où un utilisateur Gmail a ouvert l'application Gmail dans son navigateur web ou utilise activement l'application mobile. Notre meilleure estimation est qu'il s'agit d'un scan de sécurité avant de montrer l'e-mail à l'utilisateur dans son navigateur.

Les en-têtes de demande complets pour la demande d'image sont détaillés ci-dessous. Quelques éléments que vous remarquerez :

• Le référent est défini sur http://mail.google.com. Fait intéressant, même si l'utilisateur est sur https://, Gmail définit toujours le référent sur le protocole http:// lors de la demande. 

• La demande provient des serveurs de Gmail et non du navigateur de l'utilisateur. L'IP du client se résout toujours sur un espace IP appartenant à Google.

• Contrairement à Google Image Cache, la chaîne d'agent utilisateur n'identifie pas que la demande provient de l'un des bots de Google. Au lieu de cela, la chaîne d'agent utilisateur ressemble à une véritable demande d'image d'utilisateur. Cependant, nous avons confirmé que cette chaîne d'agent utilisateur identifie le bot de précharge Google.

• La demande d'ouverture se produit dans les secondes suivant la livraison de l'e-mail. De plus, la demande se produit avant que l'e-mail n'apparaisse dans l'interface Gmail de l'utilisateur. Ce comportement nous amène à croire que la demande est à des fins de sécurité.

• La précharge semble n'avoir lieu qu'une fois par fil de conversation d'e-mail Gmail non lu. Dans nos tests approfondis, une fois qu'un message a été lu par l'utilisateur, tout futur e-mail entrant dans ce groupe de conversation n'a pas initié de demande de précharge.

• Cette précharge est distincte de Google Image Cache. Nos tests indiquent qu'une fois l'image préchargée, une demande distincte de Google Image Cache est effectuée lorsque l'utilisateur ouvre l'e-mail.

• Si un utilisateur a l'application mobile Gmail ouverte, la précharge continuera à se produire pendant une courte période, même après la fermeture de l'application mobile.

Voici un exemple de ce à quoi les en-têtes de demande ressembleront lorsque qu'une image est demandée à partir du Google Prefetch Bot :

  en-têtes : {

    host: ‘{redacted}.m.pipedream.net’,

    ‘x-amzn-trace-id’: ‘Root={redacted}’,

    ‘accept-language’: ‘fr-FR’,

    referer: ‘http://mail.google.com/’,

    accept: ‘image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8’,

    from: ”,

    ‘user-agent’: ‘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’,

    ‘accept-encoding’: ‘gzip, deflate, br’

   },

   body: {},

   inferred_body_type: ‘FORM’,

   method: ‘GET’,

   url: ‘https://{redacted}.m.pipedream.net/header-1641a1.gif’,

   client_ip: ‘66.249.92.1’,

   query: {}

Comme c'est le cas avec la protection de la vie privée de Mail d'Apple, les expéditeurs doivent traiter tous les événements d'ouverture avec soin. Les ouvertures ne sont qu'un, et souvent pas le meilleur, des nombreux indicateurs d'engagement que les expéditeurs doivent surveiller et inclure lors de déterminations sur l'engagement des utilisateurs.