Distorsions du suivi et de la mesure

Si votre politique de mise en sommeil, vos segments de chauffe d’« ouvreurs récents » ou vos valeurs de référence de taux d’ouverture dépendent des données d’engagement, ils dépendent de deux mécanismes de suivi que les fonctions de confidentialité et les scanners de sécurité faussent désormais systématiquement. Voici comment fonctionnent le suivi des ouvertures et celui des clics, ce qui fausse chacun d’eux, et les indicateurs auxquels vous pouvez encore vous fier.

Note sur les sources : 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 se charge qu’avec JavaScript et ne peut pas être récupérée sous forme de pages statiques. 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 ; les pages indiquent des dates de « dernière mise à jour » 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. Son URL est propre à chaque destinataire et pointe vers le domaine de suivi de l’expéditeur ou de l’ESP. Quand 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’adresse IP à l’origine de la requête, l’user-agent et un 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. »

Certaines conséquences découlent de la conception elle-même, avant même qu’une fonction de confidentialité n’entre en jeu :

• Si aucune image ne se charge, aucune ouverture n’est 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 enregistre une ouverture. Cela inclut l’expéditeur qui prévisualise la campagne dans l’ESP ou dans un navigateur, le message publié sur un site web ou sur les réseaux sociaux, et un code de suivi réutilisé d’un modèle à l’autre (autant de défaillances documentées par Litmus).
• Ouvertures totales et uniques : les requêtes brutes sur le pixel sont les ouvertures totales. Les ESP dédoublonnent pour compter les ouvertures uniques de chaque destinataire, car ils savent à quel abonné appartient chaque requête.
• Les ESP filtrent déjà les chargements manifestement faits par des machines. 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 ».

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

Le suivi des clics réécrit chaque href du message pour qu’il pointe 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. Selon les termes de 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, car les liens doivent être réécrits au moment de l’envoi. C’est pourquoi les outils qui ne fournissent que des statistiques, comme Litmus, ne proposent pas de suivi des clics.

Le domaine de suivi a sa propre 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)

MPP a été introduite avec iOS 15 et macOS Monterey (2021). Elle est disponible dans Apple Mail sur iOS, iPadOS, visionOS et macOS, et sur iCloud.com. Elle s’applique à toute boîte de réception lue dans 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 est téléchargé à l’avance, à l’arrivée du message, et non quand une personne le consulte.
• 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 l’adresse IP d’un proxy d’Apple, et non celle du destinataire.
• Son objectif déclaré est d’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)).
• Quand il est désactivé, deux options indépendantes apparaissent : Hide IP Address (l’adresse IP est masquée, mais le contenu n’est pas téléchargé à l’avance) et Block All Remote Content (rien de distant ne se charge ; 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 quand MPP elle-même est désactivée.

La fonction est proposée à la première ouverture de Mail et reste activée sauf si l’utilisateur la désactive. En pratique, presque tous les utilisateurs d’Apple Mail l’ont activée. Les réglages se trouvent dans Settings > Apps > Mail > Privacy Protection sur iOS, iPadOS et visionOS, dans Mail > Settings > Privacy sur le Mac, et dans Settings > Privacy & Security sur iCloud.com.

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

Les opérateurs doivent connaître une réserve : le téléchargement anticipé n’est pas garanti pour chaque message, car les appareils doivent être branchés ou connectés à un réseau pour l’activité en arrière-plan. Les ouvertures MPP représentent donc près de 100 % du volume livré à ces destinataires, sans l’atteindre exactement. Vous pouvez repérer les ouvertures MPP dans les données d’événements grâce à l’user-agent du proxy d’Apple et aux plages d’adresses IP d’Apple sur les requêtes du pixel.

MPP ne touche pas aux clics. Un clic provient toujours d’une vraie action de l’utilisateur. L’adresse IP de la visite de la page de destination qui suit peut être masquée par iCloud Private Relay pour les utilisateurs de Safari, mais 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 les visite sans qu’aucune personne ne clique.

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

• La couverture est activée par défaut. Il n’existe pas d’objet de stratégie Safe Links par défaut, mais 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 et 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 quand 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 et détonation : l’option « Apply real-time URL scanning for suspicious links and links that point to files » (ScanUrls) analyse le 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’aucune personne 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 du corps inchangées, et les clients Outlook pris en charge appellent Safe Links quand l’utilisateur clique. Dans ce mode, les liens de l’expéditeur ne semblent pas 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. 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), sauf si elles sont 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’utilisateur d’accéder au lien (AllowClickThrough $false). Un vrai clic sur un domaine de suivi signalé à tort n’atteint alors jamais l’expéditeur. Ce chemin produit des faux négatifs de clics, en plus des faux positifs de la détonation.

C’est sur les listes B2B (clients Microsoft 365) que les expéditeurs voient le plus ces 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é

D’autres produits suivent le modèle de Safe Links. 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 » ou sandboxing). Cela inclut 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 requêtes GET, donc un désabonnement qui agit sur un GET est déclenché par des robots.
• Réécrire les liens par leurs propres redirecteurs (par exemple urldefense.com, la protection des liens de Mimecast), ce qui ajoute une seconde 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 » par des scanners depuis des adresses IP de centres de données.

Les comportements qui distinguent les clics de scanners des clics humains :

Pour filtrer les clics de robots en pratique, évaluez chaque événement selon plusieurs de ces heuristiques plutôt qu’une seule. Certains scanners ne cliquent que sur une sélection aléatoire de liens, et certaines adresses IP de sortie d’entreprise servent à la fois aux scanners et aux personnes. Ne déclenchez jamais une action irréversible, comme un désabonnement, une modification des préférences ou un achat en un clic, sur une simple requête GET.

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

Gmail réécrit toutes les URL d’images par 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. Les effets, confirmés par la page de Litmus sur les limites de ses statistiques :

• L’adresse IP et la géolocalisation sont masquées. Les requêtes du pixel proviennent des adresses IP du proxy de Google, et 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, si bien que les réouvertures sont sous-comptées. Litmus les appelle « image cache opens » et les exclut de ses 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 que les deux ne peuvent pas être distingués (« Yahoo/AOL Mail via Yahoo/AOL’s Image Cache »).
• Contrairement à Apple MPP, le proxy de Gmail a historiquement téléchargé les images au moment de la consultation, si bien qu’une ouverture par le proxy de Gmail indique toujours qu’une personne a ouvert le message. Il fausse qui l’a ouvert, où et sur quel appareil, mais pas le fait qu’il ait été ouvert. (Gmail a parfois téléchargé à l’avance les images de certains messages, donc considérez les ouvertures Gmail comme majoritairement humaines, mais sans garantie.)

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

Litmus documente les limites de son propre Email Analytics. Cette documentation est une base utile et honnête de ce que les statistiques fondées sur un pixel peuvent et ne peuvent pas affirmer :

• Il ne peut pas suivre les destinataires dont les images sont désactivées ni les clients texte seul. Ses statistiques sont « un moyen de ventiler votre taux d’ouverture » (a way to break down your open rate), autrement dit un éclairage sur les destinataires qui ont ouvert, et sur eux seuls.
• Plus aucune donnée fiable sur le transfert ou l’impression ne subsiste pour aucun fournisseur de messagerie (Litmus les a 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) chargent le contenu de façon asynchrone et continuent 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 qui ne peuvent pas être suivis 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 avec 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 retiré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 téléchargement anticipé de MPP.

Conséquences opérationnelles

Les indicateurs auxquels vous pouvez encore vous fier

Le taux d’ouverture global garde un usage légitime : une baisse soudaine signale toujours un problème de livraison. Même les ouvertures par téléchargement anticipé exigent que le message atteigne la boîte de réception, si bien que, pour les destinataires chez Apple, les ouvertures MPP servent en pratique de mesure du placement en boîte de réception.

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

La règle classique, « placer en suppression après N mois sans ouverture », échoue désormais dans les deux sens. Les utilisateurs de MPP semblent engagés en permanence, si bien qu’ils ne sont jamais mis en sommeil et que la liste se dégrade. Les utilisateurs dont les images sont désactivées semblent inactifs en permanence, si bien que des lecteurs engagés sont retirés. Revoyez la politique ainsi (cela prolonge Hygiène de base de données et politiques de mise en sommeil) :

1. Regroupez les destinataires selon la fiabilité de leurs ouvertures, grâce à l’user-agent et à l’adresse IP des requêtes du pixel : ouvertures par le proxy de MPP, ouvertures depuis les caches des fournisseurs, et 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 période d’observation en conséquence, car les clics sont plus rares que les ouvertures. Une règle de 90 jours fondée sur les ouvertures peut devenir une règle de 180–365 jours fondée sur les clics et les conversions.
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 la vérification par l’activité hors email (visites du site web, achats). C’est désormais le signal principal, et non un recours.
5. Ne laissez pas les clics de robots déclencher un réengagement, pour qu’une détonation par Safe Links ne « sauve » pas une adresse morte. De la même façon, ne comptez jamais le GET d’un scanner sur le lien de confirmation d’une campagne de reconquête comme un consentement.

La même correction s’applique aux segments de chauffe. Les segments « les plus engagés » constitués pour la chauffe d’IP devraient être classés selon la date des derniers clics ou conversions des destinataires, et non selon les ouvertures, sans quoi ils se rempliront d’utilisateurs Apple non engagés.

Optimiser l’heure d’envoi et le contenu

• Les modèles qui optimisent l’heure d’envoi et sont entraînés sur les horodatages des ouvertures sont pollués par les calendriers de téléchargement anticipé. Entraînez-les uniquement sur les horodatages des clics.
• Le contenu dynamique (comptes à rebours, images personnalisées selon la localisation) est rendu quand Apple le télécharge à l’avance ou quand le proxy de Google le télécharge. Concevez le contenu pour que la version rendue au moment du téléchargement anticipé reste acceptable.
• Les tests A/B jugés sur les ouvertures mesurent surtout du bruit pour les destinataires chez Apple. Jugez les tests de ligne d’objet sur les clics et les conversions, ou limitez la lecture des ouvertures aux ouvertures qui ne sont pas passées par un proxy.

Voir aussi

• Indicateurs et valeurs de référence de la délivrabilité, avec les seuils que ces réserves nuancent
• Hygiène de base de données et politiques de mise en sommeil
• List-Unsubscribe et désabonnement en un clic, y compris la raison pour laquelle le désabonnement en un clic utilise POST
• Contenu et design au service de la délivrabilité, y compris la réputation des domaines de suivi
• Le modèle de livraison en sept étapes