Comment SparkPost suit les ouvertures

Quand le suivi d'ouverture est actif, Bird (ex SparkPost) injecte un pixel transparent dans la partie HTML du message; le chargement de ce pixel par le client de messagerie enregistre un evenement email.opened. La documentation precise que le suivi n'est effectif que si trois conditions sont reunies ensemble: le drapeau de l'envoi est a true, le reglage du domaine d'envoi est active, et le CNAME de tracking est verifie.

Procédure

  1. Interface Bird: ouvrir le tableau de bord, puis le menu Email > Domains (page Domains, lien documente vers bird.com/dashboard/w/email/domains).
  2. Sur le domaine d'envoi concerne, desactiver le reglage de suivi d'ouverture. Le libelle exact de l'interrupteur dans l'interface est non documenté dans la documentation Bird.
  3. Tenir compte de la portee: la documentation rattache ce reglage au domaine d'envoi, pas au contact. Il ne permet donc pas de distinguer les contacts consentants des autres. Aucun reglage equivalent au niveau campagne ou scenario automatise n'est documenté.
  4. Envoi par API: dans POST /v1/email/messages, passer track_opens a false (le champ vaut true par defaut). La documentation indique qu'un false au niveau de l'envoi supprime toujours le suivi pour ce message.
  5. Envoi par SMTP: ajouter l'en-tete X-MSYS-API: { "options" : { "open_tracking" : false, "click_tracking" : false } }. Attention, ce point n'est pas sur la page Bird citee mais sur developers.sparkpost.com/api/smtp, ou l'exemple donne montre la mise a true.
  6. Reglage par destinataire: via l'API Transmissions SparkPost, ajouter un objet options a chaque destinataire inline avec open_tracking a false; ces valeurs par destinataire priment sur les options de la transmission, mais sont ignorees avec une liste de destinataires stockee.

Et le suivi de clic ?

Oui, separement du suivi d'ouverture. Champ track_clicks dans POST /v1/email/messages (defaut true, comme track_opens). Champ click_tracking dans l'en-tete X-MSYS-API en SMTP. Champ click_tracking dans l'objet options par destinataire de l'API Transmissions (defaut true au niveau transmission). Les interrupteurs de la page Domains distinguent eux aussi ouverture et clic. A noter: le suivi de clic reecrit les liens via un domaine de tracking, il ne depend donc pas du pixel.

Ce que ce réglage ne fait pas

  • Dans l'interface, le reglage est au niveau du domaine d'envoi, pas du contact : pour conditionner le pixel au consentement contact par contact, il faut passer par l'API (objet options par destinataire inline), donc par un developpeur.
  • Les surcharges de suivi par destinataire sont ignorees lorsque l'envoi utilise une liste de destinataires stockee.
  • Les libelles exacts des interrupteurs sur la page Domains ne sont pas donnes par la documentation : non documente.
  • L'etat effectif resulte d'une combinaison de trois conditions (drapeau d'envoi, reglage de domaine, CNAME verifie) : un drapeau a false suffit a supprimer le pixel, mais un true seul ne suffit pas a l'activer.
  • Les reglages de domaine sont desactives par defaut alors que track_opens et track_clicks valent true par defaut, ce qui rend l'etat effectif difficile a lire.
  • Dans l'API Transmissions, si options.open_tracking n'est pas positionnee, c'est la valeur de l'option de compte rest_tracking_default qui s'applique. Le defaut a true concerne track_opens sur POST /v1/email/messages, pas options.open_tracking des Transmissions.
  • En SMTP, le suivi d'ouverture et de clic est desactive par defaut, sauf pour les comptes Enterprise ou il est activesactive par defaut ; un defaut peut aussi etre pose dans les reglages du compte relais SMTP.
  • Aucun reglage de suivi au niveau d'une campagne ou d'un scenario automatise n'est documente dans l'interface marketing Bird.
  • Les ouvertures prechargees par Apple Mail Privacy Protection ou le proxy d'images Gmail sont marquees is_prefetched : cela concerne le comptage, pas la desactivation du pixel.
  • L'API Transmissions relevee ici est l'API SparkPost historique ; la documentation Bird actuelle documente POST /v1/email/messages. La coexistence des deux et leur disponibilite selon les comptes est non documentee dans les pages consultees. Ce document decrit des reglages techniques, il ne constitue pas une appreciation de conformite.

Ce que SparkPost ne peut pas décider à votre place

La plateforme ne connaît ni votre finalité juridique, ni la qualité du consentement que vous avez recueilli, ni ce que vous avez annoncé à vos abonnés. Vérifiez le HTML réellement reçu et les réglages de votre compte. Un marqueur présent ne prouve pas l'enregistrement d'une ouverture côté serveur ; aucun marqueur reconnu ne prouve pas une absence de suivi.

Analyser un email SparkPostPréparer les textes