Data Views Marketing Cloud : le guide SQL avec exemples

Le Tracking d’Email Studio et les rapports standards d’Analytics Builder répondent aux questions courantes. Mais tôt ou tard, on vous demandera un chiffre qu’aucun rapport ne donne : « les abonnés qui ont cliqué sur trois emails ou plus ce trimestre », « le détail SMTP de tous les hard bounces de la semaine », « la performance de chaque email d’un journey, version par version ». C’est là que les Data Views entrent en jeu.

Les Data Views sont des tables système, maintenues par Marketing Cloud Engagement, qui enregistrent chaque envoi, ouverture, clic, bounce ou désinscription, abonné par abonné. On ne les voit pas dans l’interface : on les interroge en SQL depuis Automation Studio, et le résultat est stocké dans une data extension (Data Views). Leur nom commence toujours par un tiret bas : _Sent, _Open, _Click, _Bounce, _Journey…

Pourquoi les utiliser ? Parce qu’elles descendent au niveau de l’abonné et de l’événement, là où les rapports standards s’arrêtent à des agrégats. Parce qu’on peut les croiser avec vos propres données (achats, préférences, segments). Et parce que le résultat, une data extension, sert directement à cibler un envoi ou à alimenter un journey.

Dans ce guide, vous verrez comment les interroger, lesquelles utiliser, comment les relier entre elles, et vous repartirez avec des requêtes SQL prêtes à copier.

Comment ça marche : une requête, une data extension, une automation

Interroger une Data View demande trois éléments (SQL Queries for Marketing Cloud Engagement) :

1. Une data extension cible, créée à l’avance, avec des champs qui correspondent aux colonnes que votre requête va renvoyer (même nom, type compatible, longueur suffisante).
2. Une activité SQL Query dans Automation Studio, qui contient la requête SELECT et pointe vers cette data extension.
3. Un lancement : soit ponctuel, avec le bouton Run Once directement depuis l’activité, sans aucune automation ; soit régulier, en plaçant l’activité dans une automation planifiée.

Le résultat de chaque exécution est écrit dans la data extension cible, et le journal d’activité garde une trace de chaque passage (Build a SQL Query Activity).

Trois façons d’écrire le résultat

Mode	Ce qu’il fait	Quand l’utiliser
Overwrite	Vide la data extension puis la remplit avec le nouveau résultat	Le choix par défaut pour un rapport : chaque exécution donne une photo à jour. C’est aussi le mode le plus performant dans la plupart des cas
Append	Ajoute les lignes à la fin, sans toucher aux lignes existantes	Pour construire un historique ou un journal d’événements, par exemple conserver les clics au-delà des six mois
Update	Met à jour les lignes qui correspondent à la clé primaire et ajoute les nouvelles	Pour tenir à jour une table par abonné, par exemple la date du dernier clic

Les recommandations de performance viennent de la documentation Salesforce (Optimizing a SQL Query Activity).

Tester vos requêtes avec Query Studio

Avant d’automatiser une requête, il faut la tester. Créer une data extension, une activité, lancer, puis aller voir le résultat : c’est long pour un simple essai. C’est là qu’intervient Query Studio for Marketing Cloud, une application gratuite de Salesforce Labs disponible sur l’AppExchange (Query Studio for Marketing Cloud). On écrit la requête, on clique sur Run, et le résultat s’affiche directement sous l’éditeur, avec le temps d’exécution.

Ce qu’il faut savoir avant de l’utiliser :

• Installation : depuis le menu AppExchange de Marketing Cloud. Après l’installation, déconnectez-vous puis reconnectez-vous pour voir apparaître l’application (sfmarketing.cloud).
• Ce qu’il crée en coulisses : chaque exécution génère une data extension temporaire dans un dossier QueryStudioResults, supprimée automatiquement au bout de 24 heures, et chaque utilisateur dispose d’une activité SQL Query nommée « interactivequery » dans Automation Studio (sfmarketing.cloud). Ne soyez pas surpris de les voir apparaître.
• Garder le résultat : le lien Export in Contact Builder, au-dessus des résultats, permet de conserver les données.
• Support : c’est une application Salesforce Labs, que le support Salesforce ne prend pas en charge : les questions sont renvoyées vers la communauté Trailblazer (Support for Query Studio for Marketing Cloud).

Toutes les requêtes de cet article ont été testées dans Query Studio sur un compte de démonstration : vous trouverez une capture du résultat sous chacune d’elles.

Les Data Views à connaître

Salesforce documente de nombreuses Data Views, pour l’email, le SMS, le push, les journeys et même les automations (Data Views). Pour le reporting email, une dizaine suffit.

Les événements d’envoi et d’engagement

Data View	Ce qu’elle contient	Colonnes les plus utiles
_Sent	Une ligne par email envoyé à un abonné	JobID, ListID, BatchID, SubscriberKey, EventDate, Domain
_Open	Une ligne par ouverture	JobID, SubscriberKey, EventDate, IsUnique
_Click	Une ligne par clic	JobID, SubscriberKey, EventDate, URL, LinkName, IsUnique
_Bounce	Une ligne par bounce	JobID, SubscriberKey, EventDate, BounceCategory, BounceSubcategory, SMTPCode, SMTPBounceReason
_Unsubscribe	Les désinscriptions liées à un envoi	JobID, SubscriberKey, EventDate
_Complaint	Les plaintes pour spam	JobID, SubscriberKey, EventDate, Domain, IsUnique

Le contexte : envois, abonnés, journeys

Data View	Ce qu’elle contient	Colonnes les plus utiles
_Job	Une ligne par envoi (job)	JobID, EmailName, EmailSubject, FromName, SchedTime, DeliveredTime
_Subscribers	Les abonnés et leur statut	SubscriberKey, EmailAddress, Status, DateUnsubscribed, DateHeld
_Journey	Les journeys et leurs versions	VersionID, JourneyName, VersionNumber, JourneyStatus
_JourneyActivity	Les activités de chaque version de journey	VersionID, ActivityName, ActivityType, JourneyActivityObjectID
_BusinessUnitUnsubscribes	Les désinscriptions par business unit, au niveau Enterprise	SubscriberKey, BusinessUnitID, UnsubDateUTC

Deux Data Views plus récentes méritent aussi un coup d’œil si vous administrez le compte : _AutomationInstance et _AutomationActivityInstance, qui permettent de repérer les automations et les activités qui échouent souvent ou tournent trop longtemps (Data Views).

Relier les Data Views entre elles : les clés de jointure

Une Data View seule répond rarement à la question. La vraie puissance vient des jointures : relier un clic à l’envoi qui l’a provoqué, à l’email concerné, puis au journey qui l’a envoyé.

[embed: node/d06452cb-31a9]

[IMAGE] Fichier : data-views-cles-de-jointure.png · ALT : « Schéma des clés de jointure entre les Data Views _Sent, _Open, _Click, _Bounce, _Job, _Subscribers, _JourneyActivity et _Journey » (à exporter depuis ce schéma)

Trois règles couvrent la plupart des cas :

• Pour relier un événement à un envoi précis, joignez sur JobID, ListID, BatchID et SubscriberKey. JobID seul ne suffit pas : un même job peut contenir plusieurs lots (batches), notamment pour les envois déclenchés.
• Pour récupérer le nom ou l’objet de l’email, joignez _Job sur JobID.
• Pour rattacher un email à son journey, le champ TriggererSendDefinitionObjectID des Data Views _Sent, _Open, _Click et _Bounce correspond au champ JourneyActivityObjectID de _JourneyActivity (Data View: Journey Activity). On remonte ensuite à _Journey par VersionID, ce qui donne le nom du journey et sa version.

Six requêtes SQL prêtes à l’emploi

Chaque requête ci-dessous indique la data extension cible à créer. Remplacez les valeurs en exemple (JobID, nombre de jours) par les vôtres. Pensez à créer les champs texte assez longs : un SMTPBounceReason ou une URL dépassent vite 255 caractères.

[FICHIER À TÉLÉCHARGER] requetes-sql-data-views-marketing-cloud.sql · Texte du lien : « Télécharger toutes les requêtes (fichier SQL) »

1. Les abonnés qui n’ont pas ouvert un envoi

Pour une relance aux non-ouvreurs. La jointure à gauche garde tous les envois, et on ne conserve que ceux sans ouverture.

SELECT s.SubscriberKey, MIN(s.EventDate) AS SentDate
FROM _Sent s
LEFT JOIN _Open o
  ON o.JobID = s.JobID
  AND o.ListID = s.ListID
  AND o.BatchID = s.BatchID
  AND o.SubscriberKey = s.SubscriberKey
WHERE s.JobID = 123456
  AND o.SubscriberKey IS NULL
GROUP BY s.SubscriberKey

Data extension cible : SubscriberKey (texte, clé primaire), SentDate (date). Mode : Overwrite.

2. Les clics des 30 derniers jours, avec le nom de l’email et le lien

SELECT c.SubscriberKey, j.EmailName, c.URL, c.EventDate AS ClickDate
FROM _Click c
INNER JOIN _Job j ON j.JobID = c.JobID
WHERE c.IsUnique = 1
  AND c.EventDate >= DATEADD(DAY, -30, GETDATE())

Data extension cible : SubscriberKey, EmailName, URL (texte long), ClickDate, sans clé primaire (un abonné peut cliquer sur plusieurs emails). Mode : Overwrite.

3. Le détail des hard bounces de la semaine

C’est la requête à lancer quand le Tracking ou les rapports ne suffisent plus pour comprendre un problème de délivrabilité : elle renvoie le code SMTP et le message exact du serveur de réception.

SELECT b.SubscriberKey, b.JobID, b.EventDate,
  b.BounceCategory, b.BounceSubcategory,
  b.SMTPCode, b.SMTPBounceReason
FROM _Bounce b
WHERE b.BounceCategory = 'Hard bounce'
  AND b.EventDate >= DATEADD(DAY, -7, GETDATE())

Data extension cible : les sept champs, SMTPBounceReason en texte long (4 000 caractères). Mode : Overwrite. Pour les autres types, remplacez la catégorie par ‘Soft bounce’, ‘Block bounce’ ou ‘Technical/Other bounce’.

4. La performance des emails de journey, version par version

La requête la plus appréciée en rendez-vous client : un tableau par journey, version et email, avec les envois, les ouvertures et les clics.

SELECT jn.JourneyName, jn.VersionNumber, ja.ActivityName,
  COUNT(*) AS Sends,
  COUNT(o.SubscriberKey) AS Opened,
  COUNT(c.SubscriberKey) AS Clicked
FROM _Sent s
INNER JOIN _JourneyActivity ja
  ON ja.JourneyActivityObjectID = s.TriggererSendDefinitionObjectID
INNER JOIN _Journey jn ON jn.VersionID = ja.VersionID
LEFT JOIN (SELECT DISTINCT JobID, ListID, BatchID, SubscriberKey FROM _Open) o
  ON o.JobID = s.JobID AND o.ListID = s.ListID
  AND o.BatchID = s.BatchID AND o.SubscriberKey = s.SubscriberKey
LEFT JOIN (SELECT DISTINCT JobID, ListID, BatchID, SubscriberKey FROM _Click) c
  ON c.JobID = s.JobID AND c.ListID = s.ListID
  AND c.BatchID = s.BatchID AND c.SubscriberKey = s.SubscriberKey
GROUP BY jn.JourneyName, jn.VersionNumber, ja.ActivityName

Data extension cible : JourneyName, VersionNumber (nombre), ActivityName, Sends, Opened, Clicked (nombres). Mode : Overwrite. Les sous-requêtes SELECT DISTINCT évitent de compter deux fois un abonné qui a ouvert ou cliqué plusieurs fois.

5. Les désinscriptions de la semaine, avec l’email qui les a provoquées

SELECT u.SubscriberKey, sub.EmailAddress,
  u.EventDate AS UnsubscribeDate, j.EmailName
FROM _Unsubscribe u
INNER JOIN _Subscribers sub ON sub.SubscriberKey = u.SubscriberKey
LEFT JOIN _Job j ON j.JobID = u.JobID
WHERE u.EventDate >= DATEADD(DAY, -7, GETDATE())

Data extension cible : SubscriberKey, EmailAddress, UnsubscribeDate, EmailName, sans clé primaire. Mode : Overwrite.

6. Les abonnés inactifs : au moins cinq emails reçus, aucune ouverture

La base d’une campagne de réactivation, sur les six mois disponibles.

SELECT s.SubscriberKey, COUNT(*) AS EmailsReceived
FROM _Sent s
LEFT JOIN (SELECT DISTINCT SubscriberKey FROM _Open) o
  ON o.SubscriberKey = s.SubscriberKey
WHERE o.SubscriberKey IS NULL
GROUP BY s.SubscriberKey
HAVING COUNT(*) >= 5

Data extension cible : SubscriberKey (clé primaire), EmailsReceived (nombre). Mode : Overwrite. Sur un gros compte, cette requête parcourt six mois d’envois : si elle dépasse le délai maximal, découpez-la (voir les pièges plus bas).

Mettre en place l’automation pas à pas

Prenons un exemple réel : une copie simplifiée de la Data View _Bounce, avec uniquement les colonnes utiles, dans une data extension que l’on peut ensuite consulter, filtrer et exporter.

Étape 1 : créer la data extension cible

Dans Contact Builder (ou Email Studio > Subscribers > Data Extensions), créez une data extension standard, non utilisée pour l’envoi (Used for Sending : No). Voici les champs de notre exemple :

Champ	Type	Longueur	Ce qu’il contient
AccountID	Number		L’identifiant (MID) de la business unit
JobID	Number		L’envoi concerné
SubscriberKey	Text	254	L’abonné
EventDate	Date		La date du bounce, en heure CST
Domain	Text	128	Le domaine de l’adresse email
BounceCategoryID	Number		Le code de la catégorie
BounceCategory	Text	50	Hard bounce, Soft bounce, Block bounce…
BounceSubcategoryID	Number		Le code de la sous-catégorie
BounceSubcategory	Text	50	User Unknown, Domain Unknown, Blocked…
SMTPCode	Number		Le code SMTP, par exemple 550
SMTPBounceReason	Text	4000	Le message complet du serveur de réception

Tous les champs acceptent les valeurs vides et il n’y a pas de clé primaire : un même abonné peut avoir plusieurs bounces.

Étape 2 : créer l’activité SQL Query

Dans Automation Studio, onglet Activities, cliquez sur Create Activity puis choisissez SQL Query (Build a SQL Query Activity).

L’assistant compte quatre étapes.

Properties : le nom, la clé externe (générée automatiquement si vous la laissez vide), le dossier et une description.

Query : collez la requête, puis cliquez sur Validate Syntax.

SELECT
    AccountID,
    JobID,
    SubscriberKey,
    EventDate,
    Domain,
    BounceCategoryID,
    BounceCategory,
    BounceSubcategoryID,
    BounceSubcategory,
    SMTPCode,
    LEFT(SMTPBounceReason, 4000) AS SMTPBounceReason
FROM _Bounce

La fonction LEFT(SMTPBounceReason, 4000) coupe le message à la longueur du champ cible : une valeur plus longue que le champ ferait échouer la requête.

Target Data Extension : choisissez la data extension créée à l’étape 1 et le mode d’écriture. Ici, Overwrite : chaque exécution remplace le contenu par les six derniers mois de bounces.

Summary : vérifiez l’ensemble. Avec Overwrite, un bandeau rappelle que toutes les données existantes seront remplacées. Cliquez sur Finish.

Étape 3 : lancer la requête, avec ou sans automation

Pas besoin d’automation pour exécuter une activité SQL Query : depuis sa page dans Activities, le bouton Run Once la lance immédiatement, et l’onglet Action Log affiche le résultat de chaque exécution (Build a SQL Query Activity).

Pour un rafraîchissement régulier, placez l’activité dans une automation. Choisissez le démarrage (Schedule pour un planning, File Drop à l’arrivée d’un fichier), glissez l’activité SQL Query dans une étape, puis ajoutez si besoin une activité Data Extract et une activité File Transfer pour exporter le résultat vers votre SFTP. Préférez une heure décalée, comme 7 h 30 plutôt que 7 h pile : la plupart des automations sont planifiées à l’heure pleine (Optimizing a SQL Query Activity).

Étape 4 : vérifier le résultat

Ouvrez la data extension, onglet Records. Chaque bounce apparaît avec sa catégorie, sa sous-catégorie, le code SMTP et le message exact du serveur : de quoi comprendre en un coup d’œil s’il s’agit d’adresses inexistantes, de domaines invalides ou d’un blocage.

Les pièges à connaître

Six mois d’historique, pas deux ans

La plupart des Data Views d’engagement ne conservent que six mois de données (Data Views). La politique de rétention à 730 jours qui s’applique au Tracking et aux rapports ne change rien ici. Si vous avez besoin d’un historique plus long, construisez-le vous-même : une requête en mode Append qui copie chaque jour les événements de la veille dans votre propre data extension.

Les dates sont en heure de Chicago, sans heure d’été

Les dates des Data Views sont stockées en Central Standard Time (UTC-6), sans passage à l’heure d’été (Data Views). Pour un lecteur en France, il faut ajouter sept heures en hiver et huit en été. Un clic à 23 h 30 à Paris apparaît donc la veille : attention aux rapports par jour.

Au niveau Enterprise, les événements ne sont pas là

Les Data Views interrogées depuis le compte Enterprise n’incluent ni les envois, ni les ouvertures, ni les clics, ni les désinscriptions, ni les bounces : il faut exécuter la requête dans la business unit qui a envoyé l’email (Data Views). À l’inverse, _BusinessUnitUnsubscribes ne fonctionne que sur le compte parent. Et _JourneyActivity ne contient que les activités créées dans la business unit où vous lancez la requête (Mateusz Dąbrowski).

Une requête s’arrête au bout de 30 minutes

Toute activité SQL Query est interrompue après 30 minutes, et Salesforce conseille de changer d’outil si une requête dépasse régulièrement 10 minutes (Optimizing a SQL Query Activity). Pour rester sous la limite :

• sélectionnez uniquement les colonnes utiles, jamais SELECT * ;
• filtrez sur une période courte avec EventDate ;
• découpez une grosse requête à plusieurs jointures en petites requêtes qui écrivent dans des tables intermédiaires ;
• une seule requête par étape d’automation, et des horaires décalés par rapport aux heures pleines.

Les chiffres ne correspondent pas exactement au Tracking

Les Data Views enregistrent chaque événement brut : ouvertures automatiques d’Apple Mail Privacy Protection, clics de robots de sécurité, ouvertures et clics d’un email transféré attribués à l’abonné d’origine. Utilisez le champ IsUnique ou des SELECT DISTINCT pour compter des personnes plutôt que des événements, et gardez en tête que les abonnés en Do Not Track n’ont aucune ouverture ni aucun clic enregistré.

Quel outil utiliser ensuite ?

Votre besoin	L’outil adapté
Voir rapidement les résultats d’un envoi	Tracking dans Email Studio
Un rapport prêt à l’emploi, planifié par email	Rapports standards d’Analytics Builder
Envoyer les données brutes vers un entrepôt de données, au-delà de six mois	Tracking Extract [à lier] (Tracking Extract)
Des tableaux de bord visuels sur deux ans, sans SQL	Intelligence Reports for Engagement [à lier]
Des traitements trop lourds pour une requête de 30 minutes	Data 360 (anciennement Data Cloud), que Salesforce recommande pour les transformations volumineuses

FAQ : les Data Views de Marketing Cloud Engagement

Qu’est-ce qu’une Data View dans Marketing Cloud ?

Une table système gérée par Marketing Cloud Engagement, qui enregistre les envois, ouvertures, clics, bounces, désinscriptions ou encore les journeys. On l’interroge en SQL depuis une activité SQL Query d’Automation Studio, et le résultat est écrit dans une data extension.

Combien de temps les Data Views conservent-elles les données ?

Six mois pour la plupart des Data Views d’engagement comme _Sent, _Open, _Click ou _Bounce. Pour garder un historique plus long, copiez régulièrement les données dans votre propre data extension en mode Append, ou exportez-les avec un Tracking Extract.

Pourquoi ma requête sur _Sent ne renvoie rien depuis le compte parent ?

Parce que les Data Views d’engagement interrogées au niveau Enterprise ne contiennent pas les envois, ouvertures, clics, désinscriptions et bounces. Exécutez la requête dans la business unit qui a envoyé les emails.

Comment relier un email à son journey en SQL ?

Joignez le champ TriggererSendDefinitionObjectID de _Sent (ou _Open, _Click, _Bounce) au champ JourneyActivityObjectID de _JourneyActivity, puis _JourneyActivity à _Journey sur VersionID.

Dans quel fuseau horaire sont les dates des Data Views ?

En Central Standard Time (UTC-6), sans heure d’été. Depuis la France, ajoutez sept heures en hiver et huit heures en été.

Pourquoi ma requête SQL échoue-t-elle au bout de 30 minutes ?

C’est la durée maximale d’une activité SQL Query. Réduisez la période analysée, sélectionnez uniquement les colonnes nécessaires ou découpez la requête en plusieurs étapes.

Sources : documentation Salesforce

Toutes les informations de cet article ont été vérifiées dans la documentation Salesforce en septembre 2026. Les requêtes sont des exemples à adapter et à tester sur votre compte.

• Data Views
• Data View: Journey Activity
• Build a SQL Query Activity
• Optimizing a SQL Query Activity
• Query Activity: Add/Update, Recommendations for scale
• Trailhead : SQL Queries for Marketing Cloud Engagement
• Tracking Extract
• Pour aller plus loin sur les Data Views : Mateusz Dąbrowski, SFMC System Data Views