Distorsions du suivi et de la mesure

Toutes les pratiques de délivrabilité fondées sur l’engagement (politiques de mise en sommeil, segments de chauffe construits sur les « ouvreurs récents », valeurs de référence du taux d’ouverture) reposent sur deux mécanismes de suivi que les fonctions de confidentialité et les scanners de sécurité faussent désormais systématiquement. Cet article explique le fonctionnement du suivi, recense chaque source de distorsion et indique les indicateurs auxquels un opérateur peut encore se fier.

Provenance : les trois articles du centre d’aide de Litmus cités ont été déplacés vers une base de connaissances Validity (knowledge.validity.com) qui ne fonctionne qu’en JavaScript et ne peut pas être récupérée de façon statique ; le contenu ci-dessous provient d’instantanés de la Wayback Machine des pages d’origine de help.litmus.com (captures du 2024-09-16, du 2024-12-11 et du 2025-02-13 ; dates de « dernière mise à jour » indiquées dans les pages : d’août 2023 à novembre 2024).

Le fonctionnement du suivi

Le suivi des ouvertures : le pixel 1×1

Le suivi des ouvertures insère une image transparente de 1×1 (le « pixel de suivi ») dans le corps HTML, avec une URL unique par destinataire sur le domaine de suivi de l’expéditeur ou de l’ESP. Lorsque le client de messagerie affiche le message et télécharge les images distantes, la requête du pixel atteint le serveur de suivi, qui enregistre une « ouverture » avec l’IP à l’origine de la requête, l’user-agent et l’horodatage. Litmus décrit ses propres statistiques de la même façon : « Email Analytics utilise un pixel de suivi 1x1, comme la plupart des ESP pour fournir les indicateurs de taux d’ouverture. Chaque fois que ce pixel est chargé, nous détectons une ouverture » (Email Analytics uses a 1x1 tracking pixel, similar to how most ESPs provide open rate metrics. Every time this pixel is loaded, we detect an open).

Conséquences structurelles, avant même de tenir compte des fonctions de confidentialité :

• Pas de chargement d’image → aucune ouverture enregistrée. Les clients dont les images sont désactivées, l’affichage en texte brut ou les clients texte seul produisent des faux négatifs. Un « taux d’ouverture » est en réalité un taux de chargement du pixel.
• Chaque chargement d’image → une ouverture enregistrée, y compris lorsque l’expéditeur prévisualise la campagne dans l’ESP ou un navigateur, lorsque le message est publié sur un site web ou sur les réseaux sociaux, ou lorsqu’un code de suivi est réutilisé d’un modèle à l’autre (autant de défaillances documentées par Litmus).
• Total ou unique : les requêtes brutes sur le pixel sont les ouvertures totales ; les ESP dédoublonnent en ouvertures uniques par destinataire, car ils détiennent la correspondance avec les abonnés.
• Les ESP filtrent déjà les chargements manifestement automatiques : Litmus note que certains fournisseurs « écartent tous les [chargements de pixel] qui semblent être des doublons, par exemple si plus de 4 requêtes sont enregistrées en moins d’une seconde… pour contrer les ouvertures par proxy qu’utilisent certains fournisseurs de messagerie pour accélérer le chargement des emails » (discard any [pixel loads] that appear to be multiples, for example if more than 4 hits are recorded in less than one second… to counteract proxy opens that some inbox providers use to speed email loading).

Le suivi des clics : les liens de redirection réécrits

Le suivi des clics réécrit chaque href du message pour le faire pointer vers le domaine de redirection (de suivi) de l’expéditeur ou de l’ESP, avec un identifiant encodé ; le serveur de redirection enregistre la requête et renvoie une redirection HTTP vers la destination d’origine. Comme le dit Litmus, les destinataires « sont redirigés vers un serveur web spécial hébergé par votre ESP, qui prend note de la "requête" puis les envoie à destination » (are redirected to a special web server hosted by your ESP that makes a note of the ’hit’ and then sends them on their way). Seule la plateforme d’envoi peut le faire (elle doit réécrire les liens au moment de l’envoi), c’est pourquoi les outils purement analytiques comme Litmus ne proposent pas de suivi des clics.

Le domaine de suivi porte lui-même une réputation : les listes de blocage d’URL et les filtres de contenu évaluent le domaine de redirection présent dans le corps du message, si bien qu’un domaine de suivi partagé répartit la réputation entre tous les expéditeurs qui l’utilisent (voir Contenu et design au service de la délivrabilité).

Source de distorsion 1 : Apple Mail Privacy Protection (MPP)

Introduite avec iOS 15 et macOS Monterey (2021). Disponible dans Apple Mail sur iOS, iPadOS, visionOS, macOS et iCloud.com, elle s’applique à toute boîte aux lettres lue avec les clients Apple Mail, pas seulement aux adresses @icloud.com.

Ce qu’en dit la documentation d’Apple elle-même

D’après la page juridique et de confidentialité d’Apple :

• Le contenu distant est téléchargé « en arrière-plan par défaut, que vous interagissiez ou non avec l’email ». Le pixel se déclenche lors du préchargement côté réception, pas lorsqu’un humain consulte le message.
• Les téléchargements passent par deux relais distincts : « Le premier connaît votre adresse IP, mais pas le contenu de Mail provenant de tiers que vous recevez. Le second connaît le contenu distant de Mail que vous recevez, mais pas votre adresse IP » (The first knows your IP address, but not any third-party Mail content you receive. The second knows the remote Mail content you receive, but not your IP address). L’expéditeur voit donc une IP de proxy d’Apple, pas celle du destinataire.
• Objectif déclaré : empêcher les expéditeurs de savoir « quand et combien de fois vous avez ouvert leur email, si vous avez transféré l’email, votre adresse IP (Internet Protocol) et d’autres données » (when and how many times you opened their email, whether you forwarded the email, your Internet Protocol (IP) address, and other data).

D’après le guide d’assistance de Mail sur macOS (Mail > Settings > Privacy) :

• Avec Protect Mail Activity activé : « votre adresse IP est masquée aux expéditeurs et le contenu distant est téléchargé de façon privée en arrière-plan lorsque vous recevez un message (et non lorsque vous le consultez) » (your IP address is hidden from senders and remote content is privately downloaded in the background when you receive a message (instead of when you view it)).
• Lorsqu’elle est désactivée, deux options indépendantes apparaissent : Hide IP Address (masquage de l’IP sans préchargement) et Block All Remote Content (aucun chargement distant ; l’utilisateur voit un bandeau et peut charger le contenu manuellement).
• Selon la page juridique, Hide IP Address « masquera toujours votre adresse IP » (will still mask your IP address) même lorsque MPP est désactivé.

La fonction est proposée au premier lancement et s’applique sauf refus ; en pratique, son adoption par les utilisateurs d’Apple Mail est quasi universelle. Chemins des réglages : iOS/iPadOS/visionOS Settings > Apps > Mail > Privacy Protection ; Mac Mail > Settings > Privacy ; iCloud.com Settings > Privacy & Security.

Ce que cela fait aux données de l’expéditeur

Réserves à connaître pour un opérateur : le préchargement n’est pas parfaitement garanti pour chaque message (les appareils doivent être alimentés et connectés pour l’activité en arrière-plan), si bien que les ouvertures MPP représentent près de 100 % du volume livré à ce segment, sans l’atteindre exactement. Repérez les ouvertures MPP dans les données d’événements grâce à l’user-agent du proxy d’Apple et aux plages d’IP appartenant à Apple sur les requêtes du pixel.

MPP ne touche pas aux clics : un clic provient toujours d’une vraie action de l’utilisateur (même si l’IP de la visite de la page de destination qui suit peut être masquée par iCloud Private Relay pour les utilisateurs de Safari, l’événement de clic lui-même est authentique).

Source de distorsion 2 : Microsoft Safe Links (côté clics)

Safe Links est la protection des URL de Microsoft Defender for Office 365. Elle compte pour les expéditeurs parce qu’elle réécrit leurs liens et génère des visites non humaines de ces liens.

Fonctionnement, d’après la documentation de Microsoft sur les stratégies Safe Links :

• La couverture est activée par défaut : même s’il n’existe pas d’objet de stratégie Safe Links par défaut, la stratégie de sécurité prédéfinie Built-in protection « fournit la protection Safe Links à tous les destinataires par défaut » (provides Safe Links protection to all recipients by default) dans toute organisation disposant d’une licence Defender for Office 365 (Plan 1/2, inclus dans Microsoft 365 E5 et diverses offres pour entreprises). Les stratégies prédéfinies Standard/Strict et les stratégies personnalisées s’y ajoutent ; les modifications de stratégie mettent jusqu’à 6 heures à s’appliquer.
• Réécriture des URL : le réglage par défaut pour les emails est « Safe Links checks a list of known, malicious links when users click links in email. URLs are rewritten by default » (Safe Links vérifie une liste de liens malveillants connus lorsque les utilisateurs cliquent sur des liens dans un email ; les URL sont réécrites par défaut) : les liens du message livré pointent vers *.safelinks.protection.outlook.com avec l’URL d’origine encodée en paramètre, ce qui permet une vérification au moment du clic. Chaque clic passe par Microsoft avant d’atteindre la redirection de suivi de l’expéditeur.
• Analyse en temps réel / détonation : l’option « Apply real-time URL scanning for suspicious links and links that point to files » (ScanUrls) déclenche l’analyse du contenu lié, et « Wait for URL scanning to complete before delivering the message » (DeliverMessageAfterScan, activation recommandée) retient la livraison jusqu’à la fin des analyses. Ces analyses visitent les URL de l’expéditeur depuis l’infrastructure de Microsoft : chaque visite d’un lien de suivi réécrit est enregistrée par l’ESP comme un « clic » qu’aucun humain n’a fait, généralement quelques secondes après la livraison.
• Mode API uniquement : « Do not rewrite URLs, do checks via SafeLinks API only » laisse les URL intactes dans le corps ; les clients Outlook pris en charge appellent alors Safe Links au moment du clic. Dans ce mode, les liens de l’expéditeur ne sont pas visiblement réécrits, mais les vérifications au moment du clic ont toujours lieu.
• Listes d’URL à ne pas réécrire : les administrateurs peuvent exempter des URL (DoNotRewriteUrls) de la réécriture pendant le flux de messagerie, mais Microsoft précise que les URL exemptées « peuvent encore être bloquées au moment du clic » (might still be blocked at time of click) si elles ne sont pas aussi autorisées dans la Tenant Allow/Block List.
• Télémétrie des clics : « Track user clicks » (TrackUserClicks) est activé par défaut ; les pages d’avertissement sur les URL bloquées peuvent empêcher complètement l’accès au lien (AllowClickThrough $false), si bien qu’un vrai clic d’utilisateur sur un domaine de suivi signalé à tort n’atteint jamais l’expéditeur : un chemin de clic faux négatif qui s’ajoute aux faux positifs de la détonation.

C’est sur les listes B2B (clients Microsoft 365) que les expéditeurs en voient le plus les effets. Les destinataires d’entreprise soumis à la stratégie prédéfinie Strict produisent les visites de liens avant livraison les plus agressives.

Source de distorsion 3 : les autres passerelles et scanners de sécurité

Le schéma de Safe Links se généralise. Les passerelles de messagerie sécurisées (Proofpoint, Mimecast, Barracuda, Cisco IronPort, la protection avancée de Google Workspace et de nombreux antivirus) ont couramment pour habitude de :

• Visiter chaque lien d’un message au moment de la livraison ou peu après pour vérifier les destinations (« détonation des liens » / sandboxing), y compris le lien de désabonnement ; c’est pourquoi le désabonnement en un clic de la RFC 8058 utilise POST plutôt que GET (voir List-Unsubscribe et désabonnement en un clic) : les scanners envoient des GET, donc un désabonnement déclenché par un GET est activé par des robots.
• Réécrire les liens via leurs propres redirecteurs (par exemple urldefense.com, la protection des liens de Mimecast), ce qui ajoute un second saut de redirection devant la redirection de suivi de l’ESP.
• Télécharger le pixel de suivi pendant l’analyse du contenu, ce qui produit des « ouvertures » de scanner depuis des IP de centres de données.

Signatures comportementales qui distinguent les clics de scanner des clics humains :

Filtrage opérationnel des clics de robots : évaluez les événements selon plusieurs de ces heuristiques plutôt qu’une seule (certains scanners ne cliquent que sur un sous-ensemble aléatoire de liens, et certaines IP de sortie d’entreprise servent à la fois les scanners et les humains). Ne déclenchez jamais d’action irréversible (désabonnement, modification des préférences, achat en un clic) sur un simple GET.

Source de distorsion 4 : les proxys d’images de Gmail (et de Yahoo/AOL)

Gmail réécrit toutes les URL d’images via son proxy d’images (googleusercontent.com) : le client du destinataire télécharge les images depuis le cache de Google, et le proxy de Google les télécharge depuis le serveur de l’expéditeur. Effets, confirmés par la page de Litmus sur les limites de ses statistiques :

• IP et géolocalisation masquées : les requêtes du pixel proviennent d’IP de proxy de Google ; les détails de l’appareil se réduisent à la chaîne user-agent du proxy.
• La mise en cache supprime les ouvertures répétées : une fois l’image en cache, les consultations suivantes peuvent être servies sans nouveau téléchargement depuis l’expéditeur, ce qui sous-estime les réouvertures. Litmus les appelle « image cache opens » et les exclut des rapports d’engagement (temps de lecture), car « l’engagement est aussi masqué par les processus des fournisseurs » (engagement is also masked by the providers’ processes).
• Yahoo et AOL exploitent un proxy et un cache équivalents ; Litmus note que depuis août 2018, « Yahoo! Mail et AOL sont traités par les mêmes serveurs dorsaux » (both Yahoo! Mail and AOL are processed by the same backend servers) et sont impossibles à distinguer (« Yahoo/AOL Mail via Yahoo/AOL’s Image Cache »).
• Contrairement à Apple MPP, la requête du proxy de Gmail a historiquement lieu au moment de la consultation : une ouverture Gmail via le proxy indique donc toujours une ouverture humaine ; elle fausse qui, où et quel appareil, pas le fait qu’elle ait eu lieu. (Gmail a parfois préchargé les images de certains messages ; considérez les ouvertures Gmail comme humaines en tendance, mais pas de façon garantie.)

Ce que les éditeurs de statistiques reconnaissent eux-mêmes (Litmus)

La documentation de Litmus sur les limites de son Email Analytics offre une base honnête et utile de ce que les statistiques par pixel peuvent et ne peuvent pas affirmer :

• Aucun suivi des destinataires dont les images sont désactivées ni des clients texte seul ; les statistiques sont « un moyen de ventiler votre taux d’ouverture » (a way to break down your open rate), c’est-à-dire un éclairage sur les seuls ouvreurs.
• Plus aucune donnée fiable de transfert ou d’impression pour aucun fournisseur de messagerie (abandonnées pour des raisons de confidentialité et d’exactitude).
• Apple MPP et les caches d’images des fournisseurs font l’objet de réserves spécifiques ; les ouvertures concernées sont isolées ou exclues des rapports d’engagement.
• Les webmails (Gmail, Outlook.com, Yahoo, AOL) utilisent un chargement asynchrone qui continue de télécharger après que le lecteur est passé à autre chose, si bien que le suivi du temps de lecture et de l’engagement est exclu pour tous les webmails ; les clients impossibles à suivre exportent un temps de lecture de -1.
• L’identification des clients est grossière : toutes les versions modernes d’Outlook pour Windows (2016+) « renvoient les mêmes identifiants » (return the same identifiers) ; Outlook pour Mac affiche via WebKit et apparaît comme Apple Mail ; Lotus Notes ne peut pas être suivi.
• Les requêtes sur le pixel issues des aperçus dans l’ESP, des pages de campagne partagées ou publiées et des codes de suivi réutilisés comptent toutes comme des ouvertures, sauf si elles sont purgées avant l’envoi.

Si un éditeur spécialisé dans les statistiques documente autant de bruit, l’indicateur d’ouverture brut d’un ESP en comporte au moins autant, plus l’inflation liée au préchargement de MPP.

Conséquences opérationnelles

Les indicateurs qui restent fiables

Le taux d’ouverture agrégé garde un usage légitime : une baisse soudaine signale toujours un problème de livraison (même les ouvertures par préchargement exigent que le message ait atteint la boîte : les ouvertures MPP sont en pratique un indicateur indirect du placement en boîte de réception pour le segment Apple).

Adapter les politiques de mise en sommeil aux ouvertures gonflées par MPP

La règle classique « supprimer après N mois sans ouverture » est désormais faussée dans les deux sens : les utilisateurs de MPP semblent engagés en permanence (jamais mis en sommeil, la liste pourrit), tandis que les utilisateurs aux images désactivées semblent inactifs en permanence (des lecteurs engagés sont purgés). Refonte (qui prolonge Hygiène de base de données et politiques de mise en sommeil) :

1. Segmentez les destinataires selon la fiabilité de leurs ouvertures grâce à l’user-agent et à l’IP du pixel : ouvertures via le proxy de MPP, ouvertures via le cache d’un fournisseur, ouvertures directes.
2. Pour les destinataires concernés par MPP, définissez l’inactivité par les clics, les conversions, les connexions au site et les achats, jamais par les ouvertures. Allongez la fenêtre d’observation en conséquence (les clics sont plus rares que les ouvertures ; une règle de 90 jours sans ouverture peut devenir une règle de 180 à 365 jours sans clic ni conversion).
3. Pour les destinataires dont les ouvertures directes sont fiables, les ouvertures peuvent encore compter, avec un poids inférieur à celui des clics.
4. Conservez l’étape de validation hors email (activité sur le site ou achats) : c’est désormais le signal principal, pas un recours.
5. Excluez les clics filtrés comme robots des déclencheurs de réengagement, pour qu’une détonation par Safe Links ne « sauve » pas une adresse morte ; inversement, ne comptez jamais un GET de scanner sur le lien de confirmation d’une campagne de reconquête comme un consentement.

La même correction s’applique à la segmentation de la chauffe : les segments « les plus engagés » constitués pour la chauffe d’IP devraient être classés selon la récence des clics et des conversions, pas des ouvertures, sans quoi ils seront gonflés d’utilisateurs Apple non engagés.

Optimisation de l’heure d’envoi et du contenu

• Les modèles d’optimisation de l’heure d’envoi entraînés sur les horodatages des ouvertures sont pollués par les calendriers de préchargement ; entraînez-les uniquement sur les horodatages des clics.
• Le contenu dynamique (comptes à rebours, images personnalisées selon la localisation) est rendu au moment du préchargement d’Apple ou de la requête du proxy de Google : concevez-le pour que le rendu au moment du préchargement reste acceptable.
• Les tests A/B jugés sur les ouvertures mesurent surtout du bruit pour le segment Apple ; jugez les tests de ligne d’objet sur les clics et les conversions, ou limitez la lecture fondée sur les ouvertures aux ouvertures qui ne passent pas par un proxy.

Voir aussi

• Indicateurs et valeurs de référence de la délivrabilité : les seuils que ces réserves nuancent
• Hygiène de base de données et politiques de mise en sommeil : la procédure de mise en sommeil adaptée ci-dessus
• List-Unsubscribe et désabonnement en un clic : pourquoi le désabonnement en un clic repose sur POST (les GET des scanners)
• Contenu et design au service de la délivrabilité : la réputation du domaine de suivi
• Le modèle de livraison en sept étapes : la place de la mesure dans la boucle d’une campagne