Une équipe e-commerce prépare une campagne de réactivation. Le brief tient en une ligne : tous les abonnés qui n'ont ni ouvert ni cliqué depuis neuf mois. Un intégrateur écrit la requête sur _Open et _Click avec une fenêtre de 270 jours, la teste sur quelques abonnés connus, et la cible part en validation.
Le marketing attendait cent vingt mille personnes. La requête en renvoie quarante-huit mille. En contrôlant un échantillon, l'équipe trouve des clients inactifs depuis sept mois seulement, et ne retrouve aucun des gros dormants connus pour ne plus rien lire depuis deux ans, tous équipés d'un iPhone.
La requête ne contient pas d'erreur de syntaxe. Elle repose sur trois hypothèses fausses : que les data views remontent à neuf mois, qu'une ouverture prouve une lecture, et qu'un clic prouve un humain.
Les data views système sont la seule source SQL des envois, ouvertures, clics, bounces et désabonnements de Marketing Cloud Engagement. Elles alimentent les exclusions, les scores d'engagement et une bonne partie des tableaux de bord. L'interface ne rappelle jamais leurs limites.
| Data view | Contenu | Profondeur et portée |
|---|---|---|
_Sent | Emails envoyés | Six derniers mois. Les lignes peuvent mettre plusieurs minutes à apparaître. |
_Open, _Click | Ouvertures et clics, avec l'URL pour les clics | Six mois |
_Bounce, _Unsubscribe, _Complaint | Bounces, désabonnements liés à un envoi, plaintes | Six mois |
_Job | Envois : nom et objet de l'email, dates planifiée et effective | Business unit courante |
_Subscribers | All Subscribers et statut | Niveau entreprise, ENT._Subscribers depuis une business unit enfant |
_BusinessUnitUnsubscribes | Désabonnements par business unit | Interrogeable depuis le compte parent seulement |
Deux précisions de portée méritent d'être notées. Les data views d'événements ne sont pas disponibles au niveau entreprise : chaque business unit lit ses propres envois, ouvertures et clics. À l'inverse, _BusinessUnitUnsubscribes ne se lit que depuis le compte parent, ce qui oblige à recopier son contenu dans une data extension partagée pour que les business units enfants puissent l'exploiter.
⚠️ Une fenêtre trop large ne provoque aucune erreur. Une condition écrite sur douze mois s'exécute normalement et renvoie six mois de données. L'indicateur « sur douze mois » est faux, et la population « inactive depuis douze mois » contient des gens inactifs depuis six. Bornez la fenêtre à la rétention réelle, ou lisez une table d'historique que vous alimentez vous-même.
Un événement se rattache à un envoi précis par JobID, ListID, BatchID et SubscriberID. C'est la jointure que Salesforce utilise dans son propre exemple de filtrage des clics. La SubscriberKey est présente partout et sert à rejoindre vos data extensions, mais elle ne suffit pas à relier une ouverture à l'envoi qui l'a produite.
La joindre seule produit un produit cartésien silencieux : chaque ouverture de l'abonné se rattache à chacun des envois qu'il a reçus. Avec vingt envois et dix ouvertures sur six mois, un seul abonné pèse deux cents lignes, et le taux d'ouverture par campagne devient illisible.
SELECT
s.JobID,
COUNT(*) AS NbOuvertures
FROM _Sent AS s
INNER JOIN _Open AS o
ON o.JobID = s.JobID
AND o.ListID = s.ListID
AND o.BatchID = s.BatchID
AND o.SubscriberID = s.SubscriberID
WHERE o.IsUnique = 1
GROUP BY s.JobIDLe filtre sur IsUnique compte une seule fois un abonné qui ouvre cinq fois le même email. Ces data views contiennent chaque occurrence, pas seulement la première : sans ce filtre, ni COUNT(DISTINCT SubscriberKey), un taux d'ouverture peut dépasser 100 %.
Dernier point de vigilance sur les dates : les data views stockent leurs horodatages en heure standard du centre des États-Unis, sans changement d'heure, soit UTC moins six heures toute l'année. Un clic horodaté à 3 h dans _Click correspond à 10 h à Paris en hiver et à 11 h en été.
💡 Comparer deux dates du même fuseau ne demande aucune conversion. Tant que vous filtrez EventDate par rapport à une date calculée sur le serveur, tout va bien. La conversion devient obligatoire dès qu'une borne vient du calendrier français, par exemple « hier » ou « depuis minuit ».
Une ouverture est le chargement d'une image de suivi. Un clic est le passage par une URL de redirection. Aucun des deux ne dit qui a déclenché l'événement, et Salesforce l'écrit sans détour : ses systèmes de suivi n'ont aucun moyen de savoir si une ouverture ou un clic est humaine ou automatique.
Deux mécanismes faussent les chiffres. Apple Mail Privacy Protection, quand l'utilisateur l'active, charge le contenu distant des messages en arrière-plan, sans que le message soit lu : l'ouverture est enregistrée peu après la réception. Les antivirus et les passerelles de messagerie, très présents chez les clients professionnels, suivent les liens pour les analyser avant la remise : le clic est enregistré sans ouverture, souvent dans la minute qui suit l'envoi.
Salesforce propose, dans un article de sa base de connaissances, d'écarter les clics survenus moins de 100 secondes après l'envoi, en précisant que le seuil est à ajuster. Pour choisir quel signal utiliser, cette grille suffit dans la plupart des cas.
| Question métier | Signal à utiliser | Signal à éviter |
|---|---|---|
| Le contenu intéresse-t-il ? | Clics filtrés, taux de clic par envoi | Taux d'ouverture brut |
| L'abonné est-il encore actif ? | Clics filtrés, achats, visites, sur une fenêtre documentée | Ouvertures seules |
| Peut-on arrêter d'écrire à quelqu'un ? | Absence de clic et d'achat, après un nombre minimal d'envois reçus | Absence d'ouverture |
| Le test A/B sur l'objet est-il gagné ? | Clics ou conversions | Ouvertures, gonflées de façon inégale selon les messageries |
| La délivrabilité se dégrade-t-elle ? | _Bounce et _Complaint | Baisse des ouvertures |
Côté RGPD, choisir « inactif depuis six mois » comme critère de fin de sollicitation est défendable. Appliquer ce critère avec des ouvertures automatiques revient à ne jamais l'appliquer aux utilisateurs d'Apple Mail.
La reprise se fait en deux requêtes. La première compte les envois reçus sur la fenêtre réellement disponible, parce qu'un abonné qui n'a rien reçu depuis six mois n'est pas inactif : il est hors champ.
SELECT
s.SubscriberKey,
COUNT(*) AS NbEnvois
FROM _Sent AS s
WHERE s.EventDate >= DATEADD(day, -180, GETDATE())
GROUP BY s.SubscriberKeyLa seconde rattache chaque clic à son envoi par les quatre clés et écarte ceux qui suivent l'envoi de trop près.
SELECT
s.SubscriberKey,
MAX(c.EventDate) AS DernierClic
FROM _Sent AS s
INNER JOIN _Click AS c
ON c.JobID = s.JobID
AND c.ListID = s.ListID
AND c.BatchID = s.BatchID
AND c.SubscriberID = s.SubscriberID
WHERE s.EventDate >= DATEADD(day, -180, GETDATE())
AND DATEDIFF(second, s.EventDate, c.EventDate) >= 100
GROUP BY s.SubscriberKeyLe filtre sur _Sent limite le volume lu, et le GROUP BY garantit une seule ligne par clé, condition indispensable pour écrire dans une data extension dont la clé primaire est la SubscriberKey. Un clic humain très rapide sera écarté à tort : c'est le prix du filtre, acceptable pour une cible de réactivation. Mesurez le seuil sur vos propres envois avant de reprendre celui de Salesforce.
La cible finale se lit alors sur ces deux colonnes : au moins six envois reçus, aucun clic filtré. Gardez la dernière ouverture comme information de contexte pour le marketing, jamais comme critère d'exclusion. Rien dans les data views n'expose l'agent utilisateur ou l'origine technique d'une ouverture, donc rien ne permet d'isoler proprement celles qui sont automatiques.
_Sent correspond aux logs de diffusion, _Open et _Click aux logs de tracking. La différence tient à la profondeur. Dans Adobe Campaign, le workflow de nettoyage purge ces logs selon des durées réglées à l'installation, que votre équipe peut allonger si la base tient la charge. Dans Marketing Cloud, les six mois ne se négocient pas : au-delà, vous historisez vous-même dans vos propres data extensions.
Autre différence utile au quotidien : les événements ne portent pas de lien direct vers un destinataire en base. Vous récupérez des identifiants, SubscriberID et SubscriberKey, et c'est à vous de les joindre à vos tables. Le premier sert à relier l'événement à son envoi, le second à relier l'événement à votre référentiel. Les confondre est l'erreur la plus fréquente sur les premières requêtes.
Avant d'écrire une fenêtre dans une requête, vérifiez qu'elle tient dans la rétention. Avant de déclarer quelqu'un inactif, vérifiez qu'il a reçu quelque chose. Et avant de bâtir un score sur les ouvertures, souvenez-vous que chez une partie de vos abonnés, c'est un logiciel qui les produit.
Les data views d'événements conservent six mois de données : _Sent, _Open, _Click, _Bounce, _Unsubscribe et _Complaint. Une fenêtre plus large ne provoque aucune erreur : une condition écrite sur douze mois s'exécute normalement et renvoie six mois de données. Il faut donc borner la fenêtre à la rétention réelle, ou lire une table d'historique que vous alimentez vous-même.
Un événement se rattache à un envoi précis par JobID, ListID, BatchID et SubscriberID. La SubscriberKey est présente partout et sert à rejoindre vos data extensions, mais elle ne suffit pas. La joindre seule produit un produit cartésien silencieux : chaque ouverture de l'abonné se rattache à chacun des envois qu'il a reçus.
Parce que ces data views contiennent chaque occurrence, et pas seulement la première. Un abonné qui ouvre cinq fois le même email produit cinq lignes dans _Open. Le filtre IsUnique = 1, ou un COUNT(DISTINCT SubscriberKey), ramène le compte à une seule occurrence par abonné.
Les data views stockent leurs horodatages en heure standard du centre des États-Unis, sans changement d'heure, soit UTC moins six heures toute l'année. Un clic horodaté à 3 h dans _Click correspond à 10 h à Paris en hiver et à 11 h en été. Comparer deux dates du même fuseau ne demande aucune conversion ; elle devient obligatoire dès qu'une borne vient du calendrier français.
Non. Une ouverture est le chargement d'une image de suivi, et les systèmes de suivi n'ont aucun moyen de savoir si elle est humaine ou automatique. Apple Mail Privacy Protection charge le contenu distant en arrière-plan sans que le message soit lu, et rien dans les data views n'expose l'origine technique d'une ouverture. Utilisez les clics filtrés, et gardez la dernière ouverture comme information de contexte, jamais comme critère d'exclusion.
Je peux auditer vos requêtes sur les data views, vos fenêtres de calcul et vos scores d'inactivité, et vous rendre un diagnostic écrit avec les corrections à appliquer.
Me décrire votre contexte →