Champs d’enregistrement des données d’événement

IMPORTANT

En savoir plus sur le Data Workbench Annonce de fin de vie.

Informations sur les champs de données que le serveur Data Workbench peut traiter pour créer un jeu de données.

À propos des données d’événement

Les données d’événement utilisées pour créer un jeu de données résident dans des fichiers appelés sources de journal. Les données disponibles dans les sources de journal sont appelées données d’événement, car chaque enregistrement de données représente un enregistrement de transaction ou une instance unique d’un événement avec un horodatage associé.

Les données d’événement d’une source de journal sont collectées en temps réel par Sensors. Données d’événement collectées par Sensors des serveurs HTTP et d’applications est transmis aux serveurs Data Workbench, qui convertissent les données en journal compressé ( .vsl). Les données d’événement résidant dans un fichier plat, un fichier XML ou une source de données ODBC sont lues par le serveur Data Workbench, qui fournit des décodeurs que vous définissez pour extraire un ensemble commun de champs de données de ces différents formats.

Les sections suivantes apportent des informations sur les champs de données (appelés champs d’enregistrement de données d’événement ou champs de saisie de journal ) collectés par Sensors ou lire et rendre disponible pour le serveur data workbench.

REMARQUE

Les noms des champs respectent généralement la convention de dénomination du format de fichier journal étendu W3C. La plupart des champs comportent des préfixes qui indiquent la source des informations contenues dans le champ :

  • cs indique la communication du client au serveur.
  • sc indique la communication du serveur au client.
  • s indique des informations provenant du serveur.
  • c indique les informations provenant du client.
  • x indique les informations créées par un produit logiciel Adobe.

Champs d’enregistrement des données d’événement de la ligne de base

Journal ( .vsl) contiennent les champs de données d’événement collectés à partir des serveurs par Sensors et utilisé par le serveur data workbench dans le processus de construction du jeu de données. Le tableau suivant répertorie les champs d’un enregistrement de données d’événement type tel qu’il est enregistré par Sensor:

Champ Description
c-ip

Adresse IP du client, telle qu’elle est incluse dans la demande envoyée au serveur.

Exemple : 207.68.146.68

cs(cookie)

Les cookies envoyés par le client avec la demande.

Exemple : v1st=42FDF66DE610CF36; ASPSESSIONIDQCATDACQ=GPIBKEIBFBFIPLOJMKCAAEPM;

cs(referrer)

Chaîne de référent HTTP envoyée par le client au serveur avec la demande.

Exemple : https://www.mysite.net/cgi-bin/websearch?qry

cs(user-agent)

Chaîne envoyée par le client avec sa requête au serveur qui indique le type d’agent utilisateur du client.

Exemple : Mozilla/5.0 (Windows) U ; Windows NT 5.1 ; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

cs-method

Type de méthode de la requête HTTP.

Exemple : GET

Référence : https://www.w3.org/TR/2000/NOTE-shoplogfileformat-20001115/#field_method

cs-uri-query

Partie de chaîne de requête de l’URI (tige + chaîne de requête = URI). Ceci est précédé d’un point d’interrogation (?) et peut contenir une ou plusieurs paires nom-valeur séparées par des esperluettes (&).

Exemple : page=homepage

cs-uri-stem

La partie racine de l’URI (tige + chaîne de requête = URI). La racine est le chemin d’accès réel ou logique à la ressource demandée sur le serveur.

Exemple : /index.asp

sc(content-type)

Type de contenu de la ressource demandée par le client comme indiqué par le serveur.

Exemples : text/html, image/png, image/gif, video/mpeg

sc-bytes

Nombre d’octets de données envoyés du serveur au client en réponse à la demande.

Exemple : 4996

sc-status

Code d’état renvoyé au client par le serveur.

Exemple : 200

Référence : https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

s-dns

Nom de domaine complet ou adresse IP de l’hôte de la ressource demandée.

Exemple : www.adobe.com

x-expérience

Liste de tous les noms et groupes d’expériences contrôlés dont le client est membre au moment de la requête.

Exemple : VSHome_Exp.Group_1,VSRegistration_Exp.Group_2

x-timestamp

Date et heure (GMT) auxquelles la demande a été reçue par le serveur. Le temps est exprimé sous la forme du nombre de 100 nanosecondes écoulées depuis le 1er janvier 1600.

Exemple : 127710989320000000 correspond à la valeur x-timestamp pour 11:28:52.0000000 le mardi 13 septembre 2005.

x-trackingid

La valeur hexadécimale 64 bits de l’identifiant de navigateur unique trouvé dans un cookie persistant tel que défini par un Sensor et fourni par le client avec une demande à un serveur.

Exemple : 42FDF66DE610CF36

Champs dérivés

Le tableau ci-dessous répertorie des exemples de champs dérivés par le serveur Data Workbench des champs d’enregistrement de données d’événement de ligne de base :

Champ Description
cs(cookie)(name) La valeur d’une paire nom-valeur donnée dans un cookie.
cs(referrer-domain)

Nom de domaine ou adresse IP de l’URI de référence HTTP.

Remarque : Ce champ est en lecture seule.

cs(referrer-host)

Nom d’hôte complet du référent.

Exemple : Si cs(referrer) est https://my.domain.com/my/page , cs(referrer-host) est my.domain.com .

cs(referrer-query)(name)

La valeur d’une chaîne de requête de référent.

Remarque : Vous ne pouvez pas accéder à une valeur de chaîne de requête de référent à l’aide du champ cs(referrer)(name) .

cs-uri

L’URI complet (tige + chaîne de requête = URI entier).

Exemple : /shopping/checkout.html?product1=8Track&product2=casette&product3=cd

cs-uri-query(name)

La valeur associée au nom donné. S’il existe plusieurs valeurs pour le nom donné, ce champ renvoie la dernière de ces valeurs.

Exemples :
  • Pour l’URI /shopping/checkout.html?product1=8Track&product2=casette&product3=cd , cs-uri-query(product3) renvoie cd.
  • Pour l’URI /shopping/checkout.html?product1=8Track&product1=casette , cs-uri-query(product1) retournerait une casette.

ctime x-timestamp exprimé en secondes depuis le 1er janvier 1970. Ce champ est également appelé x-unixtime.
date x-timestamp au format AAAA-MM-JJ.
time x-timestamp au format HH:MM:SS
x-local-timestring

Horodatage converti en fuseau horaire local spécifié dans la variable Transformation.cfg pour le jeu de données. Le format est AAAA-MM-JJ HH:MM:SS.mmm.

Remarque : Vous pouvez également définir des conversions temporelles, telles que l’horodatage x-local dans la variable Log Processing.cfg fichier . Pour plus d’informations, voir Fichier de configuration de traitement du journal .

x-log-source-id

Identifiant correspondant à la source du journal pour une entrée de journal spécifique. Pour que l'identifiant soit enregistré, vous devez le spécifier dans la variable Identifiant de source de journal du champ Log Processing.cfg lors de la définition Sensor , fichier journal ou sources de données ODBC. Pour plus d’informations, voir Fichier de configuration de traitement du journal .

Exemple : de VSensor01.

x-mask Le modèle de masque de la variable Sensor sources de données (dérivées de la variable .vsl noms de fichier). Pour un fichier dont le nom est au format YYYYMMDD-SENSORID.VSL , x-mask est SENSORID.
x-timestring x-timestamp au format AAAA-MM-JJ HH:MM:SS.mmm.
x-unixtime Heure UNIX décimale dérivée de l’horodatage x.

Sensor, lorsqu’il est utilisé sur un serveur, peut collecter des champs de données d’événement de n’importe quel en-tête ou variable HTTP valide disponible via l’API du serveur. Pour collecter ces champs de données, vous devez spécifier les champs d’en-tête ou les variables de votre choix dans la variable txlogd.conffichier de configuration pour Sensor. Pour plus d’informations, voir Data Workbench Sensor Guide.

Sur cette page