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

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. Les données d’événement collectées par Sensors à partir de serveurs HTTP et d’applications sont transmises aux serveurs Data Workbench, qui convertissent les données en fichiers journaux ( .vsl) compressés. 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 lus et mis à la disposition du 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

Les fichiers journaux ( .vsl) contiennent les champs de données d’événement collectés à partir des serveurs par Sensors et utilisés 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 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 : http://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 : http://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 : http://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

Valeur hexadécimale 64 bits de l’identifiant unique du navigateur trouvé dans un cookie persistant tel que défini par un Capteur et fourni par le client avec une requête à 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 http://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) renvoie 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

x-timestamp converti en fuseau horaire local spécifié dans le fichier Transformation.cfg du 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 x-local-timestring dans le fichier Log Processing.cfg . 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 le champ Identifiant de la source de journal du fichier Log Processing.cfg lors de la définition de Capteur , 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 Modèle de masque des sources de données Capteur (dérivé des noms de fichiers .vsl ). Pour un fichier dont le nom est au format YYYMMDD-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 le fichier de configuration txlogd.confpour Sensor. Pour plus d’informations, voir le Guide du Data Workbench Sensor.

Sur cette page