Interactions et analytique

Lorsqu'un destinataire vote dans un sondage, soumet un formulaire ou touche une notation, cette interaction est enregistrée par les endpoints hébergés de MailInApp et attribuée à votre projet — en temps réel.

Comment les interactions circulent

Les blocs interactifs atteignent les endpoints d'enregistrement de deux façons, en accord avec la philosophie de repli :

Liens (universel). Chaque option d'un sondage ou d'une notation est un simple lien. Le toucher ouvre une page hébergée légère qui confirme l'action et l'enregistre. Ce chemin fonctionne dans 100 % des clients de messagerie.
Soumissions de formulaire dans l'email (amélioration). Dans les clients qui le prennent en charge (Gmail web/Android, Yahoo), les formulaires et sondages peuvent être soumis directement depuis l'email en utilisant l'encodage de formulaire HTML standard — sans changement de page. Après la soumission, les destinataires sont redirigés vers la page que vous choisissez.

Les deux chemins acceptent les mêmes données, donc les résultats se retrouvent au même endroit, quel que soit le client utilisé par le destinataire.

Le clic « Acheter maintenant » d'un bloc produit est l'unique exception : il ne peut absolument pas être enregistré via cet endpoint, car un achat ne peut se conclure que sur la page de paiement hébergée par Stripe elle-même. Il finit tout de même par apparaître ici comme un événement purchase — avec le montant, la devise et la quantité — mais seulement une fois que le webhook de Stripe confirme que le paiement a réellement été validé, jamais sur le seul clic de l'acheteur.

Protégé contre les robots et les scanners

Les outils de sécurité d'entreprise préchargent chaque lien de chaque email qu'ils analysent. Si un simple clic sur un lien suffisait à enregistrer un vote, les résultats de votre sondage seraient pleins de robots. MailInApp n'enregistre rien sur une simple requête GET : les actions basées sur des liens nécessitent l'action de confirmation explicite du destinataire, et les interactions de la vue en direct sont enregistrées via des soumissions de formulaire. Voir Liens de vue en direct.

Parce que les endpoints sont publics par nécessité (une boîte de réception ne peut pas s'authentifier), chaque charge utile est validée côté serveur, et les soumissions personnalisées sont attribuées via les mêmes jetons signés qui protègent les liens de vue en direct — un jeton falsifié ou ne correspondant pas est rejeté.

Deux couches supplémentaires garantissent l'intégrité des résultats :

Déduplication par destinataire. Le vote, la notation, la révélation ou la soumission de formulaire d'un destinataire compte une seule fois — recliquer sur son propre lien (un double tap précipité, un rechargement de page raté) est sans effet, et non une seconde ligne. Les vues répétées d'une diapositive de carrousel ne sont délibérément pas dédupliquées, car les répétitions y sont un signal d'engagement significatif plutôt qu'un double comptage.
Limitation des flux anonymes. L'identifiant campaignId d'une campagne est clairement visible dans le code source HTML de l'email lui-même, donc rien n'empêche un script de soumettre des votes arbitraires sans aucun jeton de destinataire. Les soumissions non attribuées sont plafonnées par adresse IP, par campagne, par minute. C'est un filet de sécurité au mieux, pas une identité précise — des réseaux d'entreprise ou de webmail partagés peuvent placer de nombreux destinataires réels derrière une seule IP — le plafond reste donc assez généreux pour ne pas bloquer une salve légitime d'ouvertures.

Ce qui est enregistré

Chaque événement d'interaction capture :

le projet (la campagne) auquel il appartient,
le bloc qui l'a produit (quel sondage, quel formulaire),
la valeur (l'option choisie, les champs soumis, le nombre d'étoiles),
la ligne du destinataire, lorsque l'email a été personnalisé avec une source de données — pour que vous puissiez voir qui a répondu, pas seulement combien,
un horodatage.

Cycle de vie de l'enquête

Un projet peut recevoir une date de clôture et/ou un plafond de réponses (défini à côté de ses paramètres d'envoi). Une fois l'un ou l'autre atteint, les endpoints d'enregistrement arrêtent d'accepter de nouveaux événements pour ce projet — la vue en direct remplace les blocs interactifs par un avis de clôture au lieu de générer une erreur — tandis que tout ce qui a été collecté avant la clôture reste exactement tel qu'enregistré. Voir Réponses et webhooks.

Suivi des clics

Les liens simples (un bouton, une image liée, une icône sociale) ne sont pas un sondage ni une notation, mais ils restent intéressants à connaître. Lorsqu'un email a été envoyé avec un lien de destinataire personnalisé, MailInApp fait passer ces clics simples par une redirection suivie en chemin vers leur véritable destination. Le clic est enregistré, puis le destinataire arrive sur l'URL que vous avez définie, sans étape supplémentaire et sans délai. Les emails sans contexte de destinataire (par exemple un envoi libre via l'API transactionnelle) renvoient directement vers la destination, puisqu'il n'y a rien à quoi attribuer un clic.

À la différence des votes et des notations, les clics ne sont jamais dédupliqués — un destinataire cliquant cinq fois sur le même bouton compte pour cinq clics, car les clics répétés sont ici un signal d'engagement significatif, pas un double comptage. Les résultats se regroupent dans une carte de chaleur des clics par bloc — voir Réponses et webhooks.

Profondeur de défilement

La page de vue en direct hébergée rapporte aussi jusqu'où un destinataire a défilé (25 %, 50 %, 75 %, 100 % de la page) pendant sa lecture. C'est l'unique endroit dans MailInApp qui exécute un petit script. L'email envoyé lui-même reste à 100 % sans script, comme il le doit, mais la vue en direct est déjà une page web hébergée ordinaire, donc un écouteur de défilement à cet endroit ne compromet rien. Les jalons se regroupent dans un entonnoir de profondeur de défilement ; voir Réponses et webhooks.

Suivi des ouvertures

Chaque email envoyé depuis le tableau de bord porte aussi un petit pixel de suivi des ouvertures invisible, afin que vous disposiez d'un signal pour « ouvert mais pas d'engagement » par opposition à « jamais ouvert », en plus des interactions explicites. Il est affiché dans la vue Réponses comme un indicateur Ouvert distinct (horodatage de la première ouverture) par destinataire, plutôt que mélangé à la liste des interactions.

C'est un minimum au mieux, pas une mesure précise : la Protection de la confidentialité du courrier d'Apple (Mail Privacy Protection) et le proxy d'images de Gmail préchargent ou mettent en cache les images indépendamment du fait que le destinataire ait réellement ouvert le message, donc les ouvertures peuvent être sous-comptées ou de faux positifs. Considérez-le comme un signal directionnel, pas comme une source de vérité.

Où vivent les résultats

Les données d'interaction sont collectées par projet et vous reviennent de trois façons :

Réponses par destinataire — la vue Réponses du tableau de bord regroupe chaque interaction par destinataire, jointe à votre source de données afin que vous voyiez qui a répondu, pas seulement combien. Voir Réponses et webhooks.
Webhooks — chaque interaction peut être poussée vers votre propre endpoint dès son arrivée, signée afin que vous puissiez vérifier qu'elle provient bien de MailInApp. Également couvert dans Réponses et webhooks.
Résultats en direct pour les destinataires — les blocs sondage peuvent afficher des résultats en direct aux destinataires sur leur page de résultats hébergée.

Remarque sur la confidentialité : MailInApp enregistre les interactions que les destinataires effectuent délibérément — votes, soumissions, notations — ainsi que le pixel de suivi des ouvertures décrit ci-dessus. Les endpoints sont conçus pour ne journaliser aucun autre suivi accessoire sur de simples récupérations de lien.