Quels sont les détails techniques de ce qui se passe ici ?

Lorsqu'un utilisateur reçoit un email chez son fournisseur de messagerie, l'une des applications Mail d'Apple précharge le message sans que l'utilisateur n'interagisse avec le message. Ce préchargement ne se produit souvent pas immédiatement et survient principalement lorsque le téléphone de l'utilisateur est branché et connecté en wifi. Une fois le message préchargé, le client de messagerie précharge et met en cache toutes les images à l'aide du service proxy d'Apple. Ce préchargement des images déclenche des pixels d'image, ce qui entraîne une fausse ouverture.

Quelle est la différence entre quelque chose ouvert derrière un proxy et préchargé ?

Descriptions pour les différents types d'ouvertures dans ce nouveau monde :

Ouvertures “régulières” : Ce sont les e-mails qui sont ouverts par votre destinataire prévu, et l'ouverture reflète avec précision à la fois qu'ils ont ouvert le courrier, ainsi que l'appareil qu'ils ont utilisé pour voir le courrier et l'IP à partir de laquelle ils y ont accédé.

Ouvertures proxys : Ce sont des e-mails où l'ouverture de l'image se fait via un proxy de confidentialité. L'ouverture a toujours été initiée par votre destinataire, mais les informations concernant l'appareil et l'IP/lieu associées à l'ouverture vous sont cachées.

Ouvertures préchargées : Ce sont un type spécial et nouveau d'ouverture où l'appareil de l'utilisateur ouvre l'e-mail et récupère (et met en cache) l'image sans qu'il prenne aucune action. Pour les ouvertures préchargées, il est impossible de savoir si le destinataire a vraiment regardé votre courrier ou si son appareil l'a simplement récupéré sans qu'il ne le regarde jamais.

Avec toutes ces classifications, il est important de savoir qu'une petite partie des e-mails (indépendamment des types ci-dessus) sont ouverts et inspectés par des services de sécurité et peuvent déclencher des "fausses ouvertures". Ce n'est pas courant, mais quand on dit qu'une ouverture peut être « fiable », cela signifie vraiment qu'on peut se fier à elle avec une grande confiance.

Un utilisateur doit-il utiliser activement Mail.app pour que l'e-mail soit impacté par MPP ?

Considérons un scénario courant : un utilisateur configure son compte de messagerie dans Apple Mail.app, l'application mobile Gmail et utilise également régulièrement l'application web Gmail. Même si l'utilisateur ouvre rarement (ou jamais) son e-mail dans Apple Mail.app, Mail Privacy Protection préchargera toujours les images parce que le compte de messagerie a été configuré dans Mail.app d'Apple. Dans ce cas, un expéditeur verra des ouvertures du proxy d'images d'Apple et du proxy d'images de Gmail.

Est-ce qu'Apple précharge toutes les images maintenant ?

Cela n'est observé que lorsque l'utilisateur est en wifi et que son appareil est branché.

À quelle vitesse se déroule le préchargement ?

Selon nos amis de Movable Ink, 85 % des utilisateurs d'Apple Mail qui ont cliqué sur un lien ont vu le contenu rendu moins d'une minute avant l'ouverture.

Dans l'ensemble, étant donné la manière dont MPP précharge les images, nous observons des événements d'ouverture se produire entre quelques minutes à plusieurs heures plus tard. Cependant, étant donné la limitation que MPP ne précharge que lorsqu'il est en wifi et branché, l'impact réel sur l'optimisation du temps d'ouverture a été plus limité que craint initialement. Il sera important de continuer à surveiller cela car cela pourrait changer à tout moment dans le futur.

MPP affectera-t-il les pixels de suivi web qui suivent le comportement web ?

Sauf si l'utilisateur a bloqué le suivi via son navigateur, le suivi web fonctionnera normalement. MPP n'affectera pas le suivi web.

Comment identifier les destinataires qui ont activé MPP ? Que dois-je rechercher ?

Actuellement, la chaîne user-agent que les serveurs proxy d'Apple envoient lors de la demande d'images est Mozilla/5.0. Quant à la manière dont Bird gérera cela spécifiquement, côté expédition, nous ajouterons un champ aux Webhooks et à l'API des événements pour indiquer qu'une ouverture a été préchargée.

Ces ouvertures seront toujours incluses car elles peuvent être un signal précieux qu'une adresse e-mail est valide. (En particulier, elles indiquent que l'adresse e-mail est liée à un appareil Apple allumé, donc elle est presque certainement associée à un être humain « réel ».) Néanmoins, le nouveau drapeau facilitera la visualisation que ces ouvertures sont différentes des vrais événements d'engagement et doivent être traitées différemment. Cette capacité sera disponible dans quelques semaines. Nous intégrerons également cette distinction dans notre interface de rapport Analytique et notre API des métriques au quatrième trimestre.

Quelle chaîne user-agent me dit que MPP est activé ?

Selon Google, une chaîne user-agent de navigateur aide à identifier quel navigateur est utilisé, quelle version, et sur quel système d'exploitation. Actuellement, la chaîne user-agent que les serveurs proxy d'Apple envoient lors de la demande d'images est Mozilla/5.0. Bien qu'il n'y ait pas d'indication directe que cela appartient aux proxies d'images d'Apple, nos tests indiquent que la chaîne identifie avec précision les requêtes provenant des proxies d'images d'Apple. Cela peut, à son tour, permettre aux expéditeurs de filtrer les ouvertures proxy d'Apple de leurs métriques ou de les segmenter différemment. On ne sait pas si Apple changera cela à l'avenir. En tant que tel, il sera important pour les expéditeurs de surveiller les changements de cette chaîne et de s'ajuster en conséquence.

Apple masque-t-il les adresses IP ?

Les IP de suivi des clics ne seront obscurcies que si les gens optent pour Apple Private Relay (un produit distinct et faisant partie d'iCloud+, également uniquement publié en version bêta – cela a été revu par Apple).

Les clics uniques resteront précis de toute façon car Bird suit les clics de manière unique par e-mail envoyé (chaque lien dans chaque courrier pour chaque destinataire est identifié de manière unique).

MPP fonctionne-t-il toujours si le message tombe dans le dossier spam ?

Jusqu'à présent, nous n'avons pas vu MPP précharger des images pour les e-mails livrés dans le dossier spam.

Le proxy Mail d'Apple respectera-t-il les en-têtes de mise en cache des images ?

Non, MPP ne respecte pas les en-têtes de cache d'image. Les images sont mises en cache pendant une période de 2 à 3 jours. Si aucun en-tête de cache d'image n'est appliqué, les images semblent être mises en cache indéfiniment.

Apple signalera-t-il plusieurs ouvertures s'ils préchargent l'e-mail puis que l'utilisateur l'ouvre réellement ?

Non. L'image sera mise en cache pendant un certain temps et les ouvertures supplémentaires dans cette fenêtre ne seront pas signalées.

Apple applique-t-il la protection de la vie privée des courriers uniquement au pixel classique 1x1, ou bloque-t-il le chargement de toutes les images (comme Outlook vers 2005) ? Étant donné qu'une grande partie d'autre contenu sera des images, y a-t-il un moyen de contourner cela en ajoutant des données de suivi aux autres contenus de l'email ?

Apple ne bloque pas les pixels mais ses appareils préchargent et mettent en cache de manière agressive toutes les images dans les e-mails. Vous obtiendrez donc une ouverture qu'importe si l'utilisateur a réellement ouvert le courrier.

Peut-on supposer en toute sécurité que les adresses e-mail renvoyées continueront à signaler des bounces et ne signaleront pas des ouvertures ?

Oui.

Nous sommes préoccupés par l'impact sur nos contrôles de pièges à spam (par exemple, les pièges à spam signalant l'engagement). Pouvez-vous partager une perspective sur le potentiel de pièges à spam vierges pour signaler des ouvertures compte tenu de la réponse à la question ci-dessus (c'est-à-dire, est-ce que l'opérateur de piège à spam devrait synchroniser sa boîte aux lettres surveillée dans l'application iOS pour qu'une ouverture se produise) ?

Oui, un opérateur de piège devrait avoir un client Apple Mail attaché à la boîte de réception en question, ce qui semble hautement improbable. Un grand opérateur de piège nous a dit qu'Apple n'était pas impliqué dans leur processus de surveillance. Le plus grand risque dans l'industrie est que les gens abandonnent les non-engagements comme moyen de filtrer leurs listes.

J'ai entendu des rumeurs selon lesquelles Apple ne précharge que lorsque le téléphone est en wifi et branché. Avez-vous remarqué cela ?

Nous avons vu que nos premières théories étaient confirmées : le préchargement ne se produit que lorsque l'utilisateur est en wifi et que son téléphone est branché sur une alimentation. À ce jour, il n'y a pas d'indication qu'Apple prévoit de changer ce comportement.

Existe-t-il un hack ou une solution technique pour surmonter les impacts de MPP ?

L'histoire a montré que toute solution technique pour contourner les fonctionnalités liées à la confidentialité est souvent de courte durée, nuit à votre réputation et est rapidement fermée. Bien que les premiers tests indiquent qu'il existe certains contournements pour le préchargement d'images d'Apple, nous pensons que les expéditeurs ne devraient pas compter sur ou utiliser ces contournements.

Les limitations suivantes de Mail Privacy Protection ont été observées lors des premiers tests bêta : Les utilisateurs de Mail Privacy Protection ont explicitement indiqué qu'ils ne souhaitaient pas que les fournisseurs les suivent via les ouvertures d'e-mails. Utiliser ce type de contournement trahit cette confiance de l'utilisateur, est une mauvaise pratique et nuit finalement à la réputation de votre marque.

• Le préchargement se produit principalement lorsque l'utilisateur est en wifi et branché. Les premiers tests indiquent que le préchargement ne se produit que lorsque l'utilisateur est en wifi et que son téléphone est branché sur une source d'alimentation. Ce comportement est un peu inattendu et sera intéressant à observer à mesure qu'Apple passe à la disponibilité générale pour iOS15. En pratique, cela signifie que les événements d'ouverture sont encore plus aléatoires qu'on le pensait initialement. Il semble que les événements d'ouverture peuvent se produire lorsque l'utilisateur ouvre réellement le message ou quand il ne l'ouvre pas mais est sur le wifi et le téléphone charge – ou toute autre combinaison d'événements que Apple décide. Tout cela pointe vers la même conclusion : le suivi des ouvertures sur les appareils Apple ne peut être considéré comme fiable.

• Les événements d'ouvertures initiés par l'utilisateur sont déclenchés lorsque l'image est chargée via un CSS externe.

• Les tests indiquent également que les événements d'ouvertures initiés par l'utilisateur sont déclenchés lorsque l'image est chargée via un fichier CSS externe. Bien qu'en surface cela puisse sembler être une bonne nouvelle, nous recommandons fortement de ne pas utiliser cette approche. Il est extrêmement probable qu'Apple, comme HEY l'a déjà fait, ferme cette faille. Mais il y a une raison plus fondamentale de ne pas utiliser cette approche : les utilisateurs qui ont opté pour ce service de préchargement l'ont explicitement choisi pour que les fournisseurs ne les suivent pas via les ouvertures d'e-mails.