Data Streams : connecter vos sources de données à Data Cloud

Un Data Stream est le point d'entrée de toute donnée dans Data Cloud. C'est la brique qui définit quelle source externe ou interne est ingérée, avec quelle fréquence, et sous quel format brut avant tout mapping vers le modèle sémantique. Bien concevoir ses Data Streams conditionne la fiabilité de tout le reste du pipeline : Identity Resolution, Calculated Insights et Segments ne peuvent pas compenser des données mal ingérées à la source.

Les grandes familles de connecteurs

Depuis Data Cloud > Data Streams > New, vous choisissez une catégorie de source. Les principales sont :

• Salesforce CRM : ingestion native des objets standards et custom de votre org Sales/Service Cloud (Contact, Lead, Opportunity, objets custom), sans ETL intermédiaire.
• Ingestion API : API REST/streaming pour pousser des événements depuis un système tiers ou une application maison (comportement web, événements IoT, transactions).
• Cloud Storage : ingestion de fichiers CSV/Parquet/JSON déposés sur Amazon S3, Google Cloud Storage ou Azure Blob Storage.
• Connecteurs data warehouse (Zero Copy) : Snowflake, Databricks, Amazon Redshift, Google BigQuery, via des partages Zero Copy qui évitent la duplication physique des données.
• Mobile SDK / Web SDK : capture d'événements en temps réel depuis un site web ou une app mobile (clics, pages vues, ajouts au panier).
• Marketing Cloud Next et autres clouds Salesforce, pour rapatrier des données d'engagement.

Créer un Data Stream depuis le CRM Salesforce

C'est le cas le plus fréquent en début de projet. Depuis Data Cloud > Data Streams > New > Salesforce CRM, vous sélectionnez la connexion à l'org source (souvent l'org courant), puis l'objet à ingérer (par exemple Contact). Deux paramètres sont critiques :

• Category : indique si l'objet représente un Profile, un Engagement ou un Other. Ce choix influence le comportement par défaut lors du mapping DMO et les capacités de rétention.
• Refresh Type : Full Refresh (tout est réingéré à chaque cycle), Incremental (seuls les enregistrements modifiés depuis le dernier run) ou Continuous (quasi temps réel pour les objets à fort volume de changement).

En pratique, privilégiez l'Incremental dès que le volume dépasse quelques dizaines de milliers de lignes : un Full Refresh permanent consomme inutilement des ressources de traitement et allonge les délais de fraîcheur des données.

Ingestion par fichier ou API

Pour une source qui n'a pas de connecteur natif, deux options : déposer des fichiers dans un bucket cloud connecté (utile pour des exports batch depuis un ERP par exemple), ou utiliser l'Ingestion API pour un flux applicatif. Dans les deux cas, vous devez d'abord définir un schéma d'ingestion (les champs attendus et leurs types) avant de pouvoir créer le Data Stream correspondant. Ce schéma sert de contrat : toute donnée qui n'y correspond pas sera rejetée ou tronquée silencieusement, d'où l'importance de valider un échantillon avant la mise en production.

Fréquence de rafraîchissement et fenêtres de traitement

Chaque Data Stream a un Refresh Schedule configurable (toutes les 15 minutes au minimum pour certains types de sources, jusqu'à une fois par jour). Ce choix a un impact direct sur la fraîcheur des Calculated Insights et des Segments en aval : un segment activé chaque nuit n'a pas besoin d'un stream toutes les 15 minutes, alors qu'un cas d'usage de personnalisation en temps réel sur un site web en a besoin.

1. Identifiez le SLA métier réel (à quelle vitesse la donnée doit-elle être disponible pour être utile ?).
2. Alignez la fréquence du Data Stream sur ce SLA, pas sur le maximum technique possible.
3. Surveillez la consommation de crédits associée : une fréquence trop agressive sur un stream à fort volume peut faire exploser la consommation.

Un Data Stream mal catégorisé (par exemple un objet d'engagement classé en Profile) peut casser le comportement de l'Identity Resolution en aval. Vérifiez toujours la Category avant de lancer le premier mapping, car la corriger après coup implique souvent de recréer le stream.

Suivi et diagnostic

La page Data Cloud > Data Streams affiche pour chaque stream le statut du dernier run, le nombre de lignes traitées et les éventuelles erreurs. En cas d'échec récurrent, les causes les plus fréquentes sont : un changement de schéma côté source non répercuté (ajout/suppression de champ), une expiration de la connexion (token OAuth expiré côté connecteur externe), ou un dépassement de quota de l'API source. Pour du debug fin, le Data Cloud Ingestion API Log (accessible via Setup) donne le détail ligne par ligne des rejets, ce qui est indispensable pour diagnostiquer un problème de format de données plutôt que de deviner à l'aveugle.