Mécanismes de sécurisation et limitations guardrails

Tables maximales : le magasin de données relationnelles prend en charge un maximum de 200 tables (schémas).

Taille de schéma : pour les campagnes orchestrées, la taille totale d’un schéma ne doit pas dépasser 100 Go.

Volume des mises à jour quotidiennes : les mises à jour quotidiennes d’un schéma doivent être limitées à moins de 20 % du nombre total d’enregistrements afin de maintenir les performances et la stabilité.

Modèle de données relationnel : les données relationnelles constituent le modèle principal pris en charge pour l’ingestion, la modélisation des données et les cas d’usage de segmentation.

Champ d’identité : les schémas utilisés pour le ciblage doivent contenir au moins un champ d’identité de type String, mappé à un espace de noms d’identité défini.

Attributs par schéma : le nombre moyen d’attributs par schéma ne doit pas dépasser 50 colonnes afin de maintenir la facilité de gestion et les performances.

Activation des profils : les schémas relationnels ne peuvent pas être activés pour les profils Adobe Experience Platform. Seuls les schémas XDM standard sont pris en charge pour les profils Adobe Experience Platform. Les schémas relationnels peuvent être activés pour les campagnes orchestrées ou les campagnes d’action. En savoir plus

Ingestion relationnelle et de profil : l’ingestion de données de profil et relationnelles est requise.

Sources Capture des modifications de données : toute ingestion doit se faire via des sources Capture des modifications de données :

• Sources basées sur des fichiers : le champ _change_request_type est requis. Les valeurs prises en charge sont u (upsert) ou d (delete). Ces valeurs doivent être u et d en minuscules, et non U et D en majuscules.

• Sources basées sur le cloud : l’enregistrement des tables doit être activé.

Enregistrements complets uniquement : les mises à jour partielles des enregistrements ne sont pas autorisées, chaque ligne doit être fournie en tant qu’enregistrement complet.

Fréquence d’ingestion par lots : l’ingestion par lots pour l’orchestration de campagne est limitée à une fois toutes les 15 minutes.

Latence d’ingestion : latence d’ingestion dans le stockage relationnel, varie généralement de 15 minutes à 2 heures, selon ce qui suit :

• Le volume des données

• La concurrence du système

• Le type d’opération (par ex. les insertions sont plus rapides que les mises à jour)

Relation entre le flux de données et le jeu de données : la relation entre le flux de données et le jeu de données est 1-1. Une seule source peut alimenter un jeu de données à un moment donné. Pour changer de source, supprimez le flux de données existant et créez-en un autre avec la nouvelle source.

Descripteur de version : tous les schémas, y compris les tables de faits, doivent inclure un descripteur de version pour garantir une gestion et une traçabilité appropriés des versions.

Clé primaire : chaque table doit comporter une clé primaire définie afin de garantir l’intégrité des données et les opérations en aval.

Nom de table permanent : le table_name affecté lors de la création du jeu de données est permanent et est utilisé dans toutes les fonctionnalités de segmentation et de personnalisation.

Groupes de champs : les groupes de champs ne sont pas pris en charge dans le cadre actuel de modélisation des données.

Clés primaires composites : la prise en charge des clés primaires composites avec les flux de chargement de fichier n’est pas disponible pour le moment.

Attributs scalaires uniquement : seuls les attributs scalaires sont pris en charge dans les définitions d’audience ; les mappages et les tableaux ne sont pas autorisés.

Données relationnelles pour la segmentation : les activités de segmentation reposent principalement sur des données relationnelles. Bien que les données de profil puissent être incluses, l’utilisation de jeux de données de profil volumineux peut avoir un impact sur les performances.

Limites d’attribut de profil : des limites sont appliquées au nombre d’attributs de profil pouvant être utilisés dans les audiences par lots et en streaming afin de maintenir l’efficacité du système.

Énumérations : les énumérations sont entièrement prises en charge.

Lectures d’audiences non mises en cache : les lectures d’audiences ne sont pas mises en cache. Chaque exécution de campagne déclenche une évaluation complète de l’audience à partir des données sous-jacentes.

Optimisation d’audiences : l’optimisation est fortement recommandée lors de l’utilisation de définitions d’audience volumineuses ou complexes afin de garantir les performances.

Audiences enregistrées

• Audiences enregistrées statiques : les activités d’audiences enregistrées sont statiques. Elles reflètent les données disponibles au moment de l’exécution de la campagne.

Aucun ajout à Audience enregistrée : l’ajout à une activité Audience enregistrée n’est pas pris en charge. Toute modification nécessite un remplacement complet de l’audience.

Nombre maximum d’activités de canal : une campagne orchestrée prend en charge un maximum de 10 activités de canal (e-mail, SMS, notification push ou courrier). Seules les activités de canal sont prises en compte dans cette limite. Les activités de ciblage, de gestion des données et de contrôle de flux ne sont pas comptabilisées (par exemple, Création d’audience, Chargement de fichier, Attente, Partage, Enrichissement, Réconciliation, Branchement, Fin ou Test).

Si vous dépassez la limite lors de l’enregistrement ou de la publication, l’opération échoue. Pour respecter la limite, réduisez le nombre d’activités de canal ou partagez la diffusion des messages entre plusieurs campagnes orchestrées.

Nombre maximum d’activités dans la zone de travail : le nombre d’activités dans une zone de travail de campagne orchestrée est limité à 500. Cette limite s’applique à tous les types d’activité sur la zone de travail. Elle est différente du nombre maximum d’activités de canal lors de la publication. Pour faciliter la maintenance et assurer de bonnes performances, ne dépassez pas 100 activités par workflow.