Comment QAiry exploite les data views de SFMC

‍

Dans Salesforce Marketing Cloud, l'historique d'engagement ne se trouve pas là où la plupart des équipes le cherchent.

Il réside dans les data views : des tables système qui conservent les envois, les ouvertures, les clics, les bounces, les désabonnements et les statuts d'abonnés de votre compte.

Ce sont les données les plus utiles de la plateforme, et elles n'apparaissent presque nulle part dans l'interface.

‍

Impossible de parcourir une data view comme on parcourt une data extension. On y accède en écrivant du SQL dans une Query Activity, depuis Automation Studio.

Cette seule contrainte explique pourquoi tant de demandes de reporting finissent dans la file d'attente d'une équipe technique.

‍

Voyons ce que sont ces tables, les règles que Salesforce documente à leur sujet, et la manière dont QAiry les interroge quand vous formulez une demande en langage naturel.

‍

Ce que sont réellement les data views

‍

Des tables système, pas des data extensions

Une data extension vous appartient : vous la créez, vous la nommez, vous décidez de son contenu.

Une data view appartient à Salesforce. Elle se remplit automatiquement au fil de vos envois et son schéma est figé.

Salesforce en documente plus d'une vingtaine, couvrant l'email, le SMS, les journeys, les automations et les partages sociaux.

‍

La conséquence est concrète : une data view ne se corrige pas. Si une colonne n'existe pas, aucun paramétrage ne la fera apparaître.

En revanche, vous pouvez connaître assez bien la forme de chacune pour cesser de lui demander ce qu'elle ne renverra jamais.

‍

La convention du underscore

Toutes les data views système commencent par un underscore. En segmentation, on manipule surtout _Sent, _Open, _Click, _Bounce, _Unsubscribe, _Job, _Subscribers, _ListSubscribers, _Journey et _JourneyActivity.

Les autres répondent à des besoins plus spécifiques : _Complaint pour les plaintes, _FTAF pour le transfert à un ami, _SMSMessageTracking pour MobileConnect, _AutomationInstance pour la santé des automations.

‍

Savoir quelle vue répond à quelle question représente la moitié du travail. L'autre moitié consiste à savoir ce qui ne s'y trouve pas.

‍

La fenêtre de six mois que l'on oublie

‍

Ce que Salesforce conserve vraiment

Salesforce présente les data views comme donnant accès à six mois maximum d'informations sur les abonnés et les journeys.

Pour plusieurs vues, la limite est annoncée noir sur blanc : les données d'ouverture, de clic, de bounce, de plainte et de transfert à un ami sont conservées six mois.

Une vue est bien plus courte encore. _ReconcilableDispositionView ne garde que sept jours.

‍

Salesforce précise par ailleurs que certaines vues permettent de remonter au-delà de six mois, tout en avertissant qu'une requête renvoyant un volume important met plus de temps et peut peser sur les performances de la plateforme.

‍

Pourquoi cela modifie la question posée

Une demande du type tous ceux qui n'ont jamais ouvert un de nos emails paraît simple et reste, en réalité, hors de portée des seules data views.

Ce que vous pouvez obtenir, c'est tous ceux qui n'ont pas ouvert depuis six mois. Un autre segment, d'un autre volume.

‍

Les équipes qui passent à côté de cette nuance construisent des audiences de réactivation sur une base erronée, puis s'étonnent de voir les chiffres bouger chaque trimestre.

‍

Les pièges classiques des requêtes sur data views

‍

Fuseau horaire et arrondis

Les données de suivi des clics et des ouvertures sont affichées en Central Standard Time, n'appliquent pas l'heure d'été et sont arrondies à la seconde.

Si vos fenêtres de campagne sont définies en heure locale, une clause WHERE posée naïvement sur EventDate décale silencieusement les bornes d'une journée.

‍

Le périmètre des business units

Plusieurs vues ne se comportent pas de la même façon selon l'endroit où vous les interrogez.

• _BusinessUnitUnsubscribes s'exécute uniquement sur le compte parent, pas sur les business units enfants.
• _Subscribers ne renvoie de résultats qu'au niveau entreprise et n'inclut pas les attributs d'abonné.
• Quand un triggered send n'ajoute pas les abonnés à une liste, les vues au niveau entreprise excluent ces envois, ouvertures, clics, désabonnements, bounces et transferts.

‍

Ce dernier point piège en permanence les grandes organisations. La donnée n'a pas disparu : elle se trouve dans la business unit émettrice, et non chez le parent.

‍

Attendre d'une vue des champs qu'elle ne porte pas

Troisième erreur récurrente : supposer qu'une vue contient l'attribut sur lequel vous souhaitez filtrer.

Ce n'est souvent pas le cas. _Subscribers vous donne les enregistrements d'abonnés et leurs statuts, mais pas les attributs d'abonné.

‍

Dans les comptes Enterprise 2.0, les attributs de profil disposent de leur propre emplacement : en créer un ajoute une colonne à _EnterpriseAttribute, et les requêtes peuvent y remonter ces colonnes en complément de celles qui sont documentées.

Autrement dit, un segment fondé sur un champ de profil personnalisé n'est pas une requête mono-vue. C'est une jointure, et le savoir dès le départ vous épargne un après-midi.

‍

Comment QAiry lit cette couche de données

‍

Relier une demande à la bonne vue

QAiry part de la demande, pas du schéma. Vous décrivez l'audience voulue avec vos propres mots.

La résolution suit : une question d'engagement va chercher _Open et _Click, une question de délivrabilité _Bounce, un historique d'envoi _Sent et _Job, une appartenance à une liste _ListSubscribers.

‍

Lorsque la demande traverse plusieurs vues, QAiry construit les jointures au lieu de vous laisser les deviner.

‍

Le choix des clés de jointure

Les enregistrements d'engagement portent les identifiants générés par SFMC au moment de l'envoi : job, batch, liste et abonné.

QAiry joint sur SubscriberKey et JobID plutôt que sur l'adresse email, car une jointure par adresse se casse dès qu'un contact apparaît deux fois.

‍

Les colonnes sont également listées explicitement. Salesforce recommande de nommer les champs attendus au lieu d'utiliser SELECT *, et ce conseil compte davantage sur les data views qu'ailleurs.

‍

Un SQL lisible, pas une boîte noire

Le SQL produit par QAiry reste lisible. Vous voyez les vues retenues, les clés de jointure et les bornes de dates appliquées.

Ce point compte, car la personne qui valide la requête est rarement celle qui a formulé la demande.

‍

Un relecteur vérifie en quelques secondes que la fenêtre de rétention est respectée et que le périmètre de business unit est correct. C'est nettement plus rapide que de rétro-analyser une requête écrite à la main le trimestre précédent.

‍

Comment QAiry respecte les limites techniques de SFMC

‍

Écrire en visant le plafond de trente minutes

Une Query Activity s'interrompt au bout de trente minutes. Salesforce va plus loin : si une requête dépasse régulièrement dix minutes, la transformation devrait se faire ailleurs, par exemple dans Data Cloud.

QAiry écrit en tenant compte de ce plafond : plages de dates bornées, filtres réellement exploitables par un index, et aucune extraction de trente jours d'historique quand la question n'en demande que vingt-quatre heures.

‍

Découper plutôt que tout empiler

La recommandation de Salesforce pour les traitements lourds consiste à découper une requête à jointures multiples en requêtes plus petites, à écrire les résultats intermédiaires dans des tables de travail, puis à les réunir en fin de parcours.

QAiry produit cette structure quand le besoin le justifie, plutôt qu'une requête unique qui échoue après vingt-neuf minutes.

‍

Côté automation, la logique est la même : une requête par étape, et des planifications décalées pour éviter d'entrer en concurrence avec les traitements de 8 h 00.

‍

Ce que cela change au quotidien

‍

La couche data views ne devient pas plus simple. Elle devient prise en charge.

Un marketeur formule un segment en une phrase. Ce qui revient est du SQL qui tient compte de la fenêtre de rétention, du décalage horaire, du périmètre des business units et de la limite d'exécution.

‍

La personne qui écrivait ces requêtes reste celle qui les relit. Elle cesse simplement d'être le passage obligé de chaque demande.

‍

Découvrez QAiry en action

‍

Les data views sont la zone de SFMC où une petite erreur coûte cher et se repère mal, ce qui en fait un bon test pour juger si du SQL généré est réellement exploitable en production.

Vous pouvez voir QAiry traiter une vraie requête sur data views sur qairy.com/fr/product-demos, ou l'essayer sur votre propre compte via qairy.com/fr/try-it-free.