Composants de collecte de données data-collection-components
Les composants de collecte de données comprennent les serveurs de collecte de données, l’API du DIL, les transferts de données de serveur à serveur entrants et les fichiers journaux.
L’Audience Manager contient les composants de collecte de données suivants :
Serveurs de collecte de données (DCS) et serveurs de cache de profils (PCS) dcs-pcs
Le serveur de collecte de données et le système de collecte de données fonctionnent ensemble et fournissent séparément des services liés à la réalisation de caractéristiques, à la segmentation de l’audience et au stockage des données.
Data Collection Servers (DCS)Fonction
Dans Audience Manager, le DCS :
- Reçoit et évalue les données de caractéristique d’un appel d’événement. Cela inclut les informations utilisées pour la segmentation en temps réel et les données transmises à des intervalles planifiés par des transferts serveur à serveur.
- Segmente les utilisateurs en fonction de leurs caractéristiques réalisées et des règles de qualification que vous créez avec le créateur de segments.
- Crée et gère des identifiants d’appareil et des identifiants de profil authentifiés. Cela inclut les identifiants tels que les identifiants de fournisseur de données, les identifiants utilisateur, les identifiants déclarés, les codes d’intégration, etc.
- Vérifie le PCS pour détecter les caractéristiques supplémentaires qu’un utilisateur a déjà réalisées avant un appel d’événement en temps réel. Cela permet au serveur de collecte de données de qualifier les utilisateurs en fonction de données en temps réel et de données historiques.
- Écrit les fichiers journaux et les envoie aux systèmes d’analyse pour stockage et traitement.
DCSGère La Demande ParGlobal Server Load Balancing (GSLB)
DCS est un système géographiquement réparti et dont la charge est équilibrée. Cela signifie que Audience Manager peut diriger les requêtes vers et depuis un centre de données régional en fonction de l’emplacement géographique d’un visiteur du site. Cette stratégie permet d’améliorer les temps de réponse, car une réponse DCS est envoyée directement à un centre de données qui contient des informations sur ce visiteur. GSLB rend notre système efficace, car les données pertinentes sont mises en cache dans les serveurs les plus proches de l’utilisateur.
Dans un appel d’événement, la position géographique est capturée dans une paire clé-valeur renvoyée dans un plus grand ensemble de données JSON. Cette paire clé-valeur est le paramètre "dcs_region": region ID .
En tant que client, vous interagissez avec le DCS indirectement via notre code de collecte de données. Vous pouvez également travailler directement avec DCS par le biais d’un ensemble d’API. Voir Méthodes et code de l’API du serveur de collecte de données (DCS).
Profile Cache Servers (PCS)
PCS est une base de données volumineuse (en gros, un énorme cookie côté serveur). Il stocke les données reçues pour les utilisateurs actifs provenant des transferts serveur à serveur et du DCS. Les données PCS se composent d’identifiants d’appareil, d’identifiants de profil authentifiés et de leurs caractéristiques associées. Lorsque DCS reçoit un appel en temps réel, il recherche dans PCS d’autres caractéristiques auxquelles un utilisateur peut appartenir ou auxquelles il peut se qualifier. Et, si une caractéristique est ajoutée ultérieurement à un segment, ces identifiants de caractéristique sont ajoutés au PCS et les utilisateurs peuvent être qualifiés pour ce segment automatiquement, sans visite sur un site ou une application spécifique. PCS contribue à approfondir la compréhension de vos utilisateurs par Audience Manager, car il peut associer et segmenter les utilisateurs en temps réel ou en coulisses avec de nouvelles données de caractéristiques historiques. Ce comportement vous donne une image plus complète et plus précise de vos utilisateurs que des seules qualifications en temps réel.
Il n’existe aucun contrôle d’interface utilisateur qui permet à nos clients de travailler directement avec PCS. L’accès du client à PCS est indirect, par le biais de son rôle d’entrepôt de données et de transferts de données. Le PCS s’exécute sur Apache Cassandra.
Purge des identifiants inactifs à partir dePCS
Comme indiqué précédemment, le PCS stocke les identifiants de caractéristique pour les utilisateurs actifs. Un utilisateur actif est un utilisateur qui a été vu par les serveurs de données Edge de n’importe quel domaine au cours des 14 derniers jours. Ces appels à PCS maintiennent un utilisateur à l’état actif :
- /event appels
- /ibs appels (synchronisations des identifiants)
Les caractéristiques PCS sont vidées si elles sont inactives pendant 17 jours. Ces caractéristiques ne sont pas perdues cependant. Ils sont stockés dans un Hadoop. Si l’utilisateur est de nouveau consulté à un autre moment, Hadoop renvoie toutes ses caractéristiques à PCS, généralement dans un délai de 24 heures.
Autres DCS/PCS processus : Opt-out de la confidentialité
Ces systèmes de serveur gèrent la confidentialité et les demandes d’exclusion des utilisateurs. Les informations des cookies utilisateur ne sont pas collectées dans le fichier journal si un utilisateur s’est désabonné de la collecte de données. Pour plus d’informations sur nos politiques de confidentialité, consultez le Centre de confidentialité des Adobes.
Bibliothèque d’intégration de données (DIL) dil
DIL est le code que vous placez sur la page pour la collecte de données. Pour plus d’informations sur les services et les méthodes disponibles, voir l’ API DIL .
Serveur entrant vers serveur inbound-outbound-server
Il s’agit de systèmes qui reçoivent des données envoyées par diverses intégrations serveur à serveur avec nos clients. Pour plus d’informations, consultez la documentation sur l’ envoi de données d’audience .
Fichiers journaux log-files
Le PCS crée et écrit des données dans les fichiers journaux. Ils sont envoyés à d’autres systèmes de base de données pour traitement, création de rapports et stockage.