Show Menu
SUJETS×

Intégration DFA

La configuration de l’intégration DFA implique les tâches suivantes :

Configuration de l’intégration DFA

Découvrez les étapes de l’intégration des connecteurs de données DFA.
Les pages de configuration présentent un aperçu de l’intégration, ainsi que des liens utiles conduisant vers davantage d’informations. Cette intégration engendre des frais Adobe et DoubleClick. Contactez votre représentant commercial au sujet des deux organisations et veillez à comprendre la structure des frais.
  1. Connectez-vous au Adobe Analytics.
  2. Click Admin > Data Connectors .
  3. Locate DoubleClick DFA , then click Add New .
    On each page of the Integration Wizard, provide the required information, then click Next . Le tableau suivant explique quelles sont les informations nécessaires pour exécuter l’intégration à l’aide de l’assistant.
N° de page de l’Assistant Champ Description
1 Nom d’intégration Nom d’intégration affiché par Genesis dans la liste d’intégration active de la suite de rapports.
1 Adresse de courriel d’intégration Adresse électronique qui reçoit toutes les notifications liées à cette intégration.
2 Nom d’utilisateur Nom d’utilisateur de l’API DFA à utiliser avec cette intégration. Afin qu’un utilisateur puisse se connecter à l’API, vérifiez l’attribut de cette dernière dans l’interface DFA. Ensuite, un champ de mot de passe s’affiche où vous pouvez spécifier un mot de passe pour l’utilisateur. Ce mot de passe est saisi avec le nom d’utilisateur dans l’assistant pour authentification.
2 Mot de passe Mot de passe de l’API DFA.
2 Identifiant publicitaire
Identifiant de publicitaire DFA ou identifiant de configuration Floodlight parent. La fonctionnalité Connecteurs de données utilise cet identifiant afin d’identifier le publicitaire DFA à suivre (version 1.5 de l’intégration). Cet identifiant publicitaire n’est pas utilisé dans la version 2.0 de l’intégration ; l’identifiant de configuration Floodlight parent sera recherché et utilisé. Suivez les instructions à l’écran.
3 Variable publicitaire DFA eVar Analytics qui reçoit l’attribut de campagne DFA et les données sur les impressions et les clics. Généralement, il s’agit de l’eVar du code de suivi ( s.campaign ), but you can choose any available eVar. Connecteurs de données ajoute également les classifications DFA suivantes à l’eVar sélectionnée :
Campagnes  : collection des publicités diffusées sur plusieurs sites qui convoient un message commun.
Nom du site  : site où était diffusée la publicité.
Nom de la publicité  : nom de la publicité, comme défini dans votre compte DFA.
Site Placement Name (Nom de référencement du site) : site web et page où était diffusée la publicité.
Delivery Tool (Outil de remise) : DoubleClick for Advertisers.
Canal  : bannière publicitaire.
Cost Structure (Structure de coûts) : coût par million, coût par clic ou coût fixe, selon la structure de coûts de la publicité.
Creative Name (Nom du créatif) : nom du créatif associé à une publicité, un référencement et un identifiant de créatif.
DFA > Déduplication SearchCenter  : spécifie que DFA référence les valeurs dans les variables SearchCenter en cas de clics ou affichages publicitaires DFA. .
4 Impressions Événement personnalisé qui reçoit les données des mesures d’impressions DFA. Les impressions indiquent le nombre de fois où la publicité a été diffusée.
4 Clics Sélectionnez l’événement personnalisé qui reçoit les données des mesures de clics DFA. Clics indique le nombre de fois où les visiteurs ont cliqué sur la publicité, mesuré par la redirection de DFA. La mesure Clics établit la corrélation avec la mesure de clics publicitaires Analytics.
Note: DFA Clicks and Analytics Click-throughs might not match exactly due to differences in the way data is collected. .
5 View-Through Variable (Variable d’affichage publicitaire)
eVar Analytics qui reçoit les données d’affichage publicitaire DFA. La variable d’affichage publicitaire permet de savoir de quelle façon les affichages publicitaires affectent les taux de conversion sur votre site.
La fonctionnalité Connecteurs de données ajoute les mêmes classifications liées à DFA pour cette eVar que pour la variable publicitaire DFA (voir ci-dessus).
5 Time Since Last View (Durée depuis le dernier affichage) (variable d’intervalle de temps de l’affichage publicitaire) eVar Analytics qui reçoit les données de durée depuis le dernier affichage DFA. La durée depuis le dernier affichage correspond à la durée écoulée depuis le dernier affichage publicitaire.
5 Affichages publicitaires Événement personnalisé qui reçoit les données des mesures d’affichages publicitaires DFA. Utilisez l'événement d'affichage publicitaire avec la variable d'affichage publicitaire pour identifier les campagnes qui n'ont pas influencé un clic publicitaire direct, mais qui ont peut-être joué un rôle dans le trafic vers le site à un moment ultérieur.
Les Connecteurs de données renomment l’événement personnalisé sélectionné en "Affichages publicitaires".
6 Échec de la requête DFA (Facultatif) eVar Analytics qui reçoit les codes de message d’erreur de requête DFA signalés. Codes de message DFA possibles :
  • nc  : aucun cookie DoubleClick.
  • oo  : l’utilisateur s’est désabonné.
  • nh  : aucun historique de campagne.
  • qe  : erreur de requête (délai dépassé, serveur en panne, etc.).
6 Événement de dépassement de délai
Événement de compteur Analytics qui s’incrémente chaque fois que le délai s.maxDelay timer expires, and no response was received from the DFA servers. Use this event to configure the s.maxDelay variable Tuning s.maxDelay .)

Mises à jour de site web pour l’intégration DFA

Une fois que Genesis a configuré la suite de rapports Analytics pour l’intégration DFA, vous devez procéder comme suit pour configurer votre site web et votre environnement DFA dans le cadre de cette intégration :

Mise à jour du paramètre de chaîne de requête DFA

Si vous effectuiez déjà le suivi des campagnes publicitaires avec Adobe Analytics avant l’intégration de DFA, il est possible que toutes les campagnes (publipostage, recherche ou bannière) utilisent le même paramètre de chaîne de requête pour reconnaître l’identifiant de campagne référent sur la page d’entrée.
Afin de comprendre quand demander des données de clics publicitaires et d’affichages publicitaires auprès des données DFA pour vos campagnes publicitaires DFA, les connecteurs de données doivent détecter quand un visiteur a cliqué sur une bannière publicitaire d’une campagne DFA. Pour ce faire, vous devez ajouter un paramètre de chaîne de requête différencié à l’URL de la page d’entrée de la campagne publicitaire DFA afin que les connecteurs de données puissent faire la distinction entre les pages de campagne publicitaire DFA et les autres pages de campagne publicitaire que vous pouvez avoir sur votre site Web. Le dfa_overrideParam module externe JavaScript utilisé pour DFA.
Bien que la variable Campagne puisse être utilisée pour d’autres campagnes, ne l’utilisez pas pour les campagnes DFA. Si vous définissez la variable Campaign sur une page d’entrée de campagne DFA, Adobe ne peut pas lier les impressions et clics aux clics publicitaires de la campagne DFA. Une fois par visite, les serveurs de collecte Adobe vérifient s’il existe un clic ou affichage publicitaire antérieur sur les serveurs DFA. C’est pourquoi vous devez inclure le code du module externe DFA uniquement sur les pages d’entrée courantes afin d’éviter les redirections inutiles qui peuvent ralentir le chargement des pages, en particulier pour les utilisateurs ayant des connexions Internet plus lentes.

Mise à jour du code de collecte de données de votre site web

L’intégration Genesis pour DFA met à profit l’identifiant de configuration DFA Floodlight (dfa_SPOTID), qui améliore la cohérence du rapport entre DFA et le système de collecte de données Adobe.
Le terme Spotlight a été remplacé par Floodlight dans une version récente de Google DFA. Le paramètre JavaScript dfa_SPOTID a été nommé en fonction de la terminologie Spotlight, mais il est utilisé avec les deux versions.
Pour activer l’intégration DFA sur votre site Web, vous devez mettre à jour le code de collecte de données JavaScript en ajoutant ce qui suit :
  • Module Integrate pour DFA
  • Ajout à votre code de collecte

Module Integrate pour DFA

The DFA integration leverages the Adobe Experience Cloud Integrate Module, which adds functionality to your core JavaScript data collection code ( s_code.js ). Le module Integrate fait partie du fichier .zip lorsque vous téléchargez le code AppMeasurement pour JavaScript depuis le Gestionnaire de code. Contactez votre consultant Adobe uniquement si vous avez besoin d’aide supplémentaire pour le trouver.
Insert the Integrate Module code in the Modules section of your website's s_code.js file.

Ajout à votre code de collecte

Selon vos sélections lors de l’activation de l’intégration DFA dans l’assistant d’intégration, les connecteurs de données génèrent et vous envoient par courrier électronique un ajout personnalisé pour votre code de collecte de données JavaScript. Insérez ce code dans la section principale du fichier s_code.js (et non dans la fonction doPlugins ni dans une autre fonction).
L’exemple de code illustré ci-dessous est présenté à seule fin de référence ; utilisez le code qui vous a été envoyé par courrier électronique quand vous aurez exécuté l’assistant d’intégration Connecteurs de données.
Le code de collecte est constitué des composants suivants :
  • Paramètres DFA Integrate
  • Modules externes requis pour l’intégration
Paramètres DFA Integrate
/************************** DFA VARIABLES **************************/ 
var dfaConfig = { 
   CSID:              "1234567", 
   SPOTID:            "29876543", 
   tEvar:             "eVar17", 
   errorEvar:         "eVar59", 
   timeoutEvent:      "event76", 
   requestURL:         "http://fls.doubleclick.net/ 
json?spot=[SPOTID]&src=[CSID]&var=[VAR]&host=integrate.112.2o7.net%2 
Fdfa_echo%3Fvar%3D[VAR]%26AQE%3D1%26A2S%3D1&ord=[RAND]", 
 
   maxDelay:          "1500", 
   visitCookie:       "s_dfa", 
   clickThroughParam: "CID", 
   searchCenterParam: "s_kwcid", 
   newRsidsProp:      undefined 
}; 
/************************ END DFA Variables ************************/ 

Le bloc Paramètres DFA Integrate définit les variables requises par l’intégration DFA. Les valeurs pour chacune de ces variables sont issues des sources suivantes :
CSID  : identifiant du site client. Généré par DFA une fois que vous avez exécuté l’assistant d’intégration. Les connecteurs de données prérenseignent cette variable à l’aide de votre identifiant du site client DFA et vous envoient cette valeur dans le courrier électronique de configuration après avoir exécuté l’assistant d’intégration. Cette variable n’est pas requise si la fonction AdServing avancée est activée sur votre compte.
SPOTID  : configuration Floodlight (précédemment appelée Spotlight ID). Les Connecteurs de données prérenseignent cette variable à l’aide de votre identifiant de configuration DFA Floodlight, en fonction des informations de compte DFA que vous avez spécifiées dans l’assistant d’intégration.
tEvar  : variable de transfert. Les Connecteurs de données prérenseignent cette variable à l’aide du nom de variable Analytics que vous avez spécifié comme variable d’affichage publicitaire dans l’assistant d’intégration. Ne changez pas cette valeur sans en avoir soigneusement discuté avec les services techniques ou les services Adobe Engineering.
errorEvar  : variable d’erreur. Les Connecteurs de données prérenseignent cette variable à l’aide du nom de variable Analytics que vous avez spécifié comme variable d’échec de requête DFA dans l’assistant d’intégration.
timeoutEvent  : événement de dépassement de délai. Les Connecteurs de données prérenseignent cette variable à l’aide du nom de variable Analytics que vous avez spécifié comme variable d’événement de dépassement de délai dans l’assistant d’intégration.
requestURL  : hôte DFA à distance auquel demander les informations publicitaires. Ne modifiez pas cette valeur, sauf si Adobe vous a demandé de le faire.
maxDelay  : spécifie le temps d’attente par le code de collecte de données JavaScript pour obtenir une réponse du serveur DFA Floodlight, en millisecondes. Adobe conseille d’utiliser cette valeur pour rechercher la valeur optimale en fonction du trafic de votre site. Par exemple, si vous augmentez cette valeur, davantage de données DFA sont généralement collectées, mais vous risquez de perdre des données de base sur le visiteur si celui-ci quitte le site durant la période du délai. Si vous réduisez cette valeur, le risque de perdre des données d’accès est moindre, mais il est possible que moins de données DFA soient envoyées avec les données d’accès Adobe.
visitCookie  : nom du cookie utilisé pour restreindre les appels DFA à une fois par visite.
clickThroughParam  : chaîne de requête, généralement incluse sur toutes les publicités, qui avertit le module Integrate qu’un clic vient d’avoir lieu. La présence de ce paramètre dans la chaîne de requête provoque la demande sur les serveurs DFA Floodlight, même si le visiteur a déjà été sondé au cours des 30 dernières minutes.
newRsidsProp  : (facultatif) valeur mappée à une variable de propriété de trafic non utilisée. L’intégration DFA collecte et stocke cette valeur dans le cookie de visite afin d’identifier les suites de rapports qui ont collecté des données pour un visiteur particulier. Cette propriété est nécessaire seulement pour les mises en œuvre personnalisées avec les services Adobe Engineering.
Modules externes requis pour l’intégration
L’ajout du code de collecte incorpore les modules externes supplémentaires qui améliorent le fonctionnement de l’intégration DFA :
  • Limite les requêtes DFA à une requête par visite.
  • Procure une certaine flexibilité eu égard au nom de cookie. La plupart des organisations utilisent s_dfa, mais vous pouvez utiliser n’importe quel nom de cookie valide pour l’intégration DFA.
  • Élimine les redirections superflues. Les données d’affichage publicitaire sont collectées en temps réel ; pour cette raison, les serveurs de collecte Adobe et les serveurs DFA peuvent éventuellement échanger des données sur chaque page vue. Le module externe bloque ces échanges de données quand les informations ne sont pas nécessaires.
L’un des mécanismes utilisés par le module externe pour éliminer les requêtes DFA superflues est un cookie de visite basé sur un domaine. Une suite de rapports d’intégration qui s’étend sur plusieurs domaines gonfle les données de clics et affichages publicitaires quand les visiteurs traversent les domaines après un affichage ou clic publicitaire influencé par DFA.

Confirmation d’une intégration DFA réussie

Après avoir effectué toutes les mises à jour de site web nécessaires, utilisez une visionneuse de trafic réseau, telle que Charles*, Chrome Developer Tools ou Firebug*, pour confirmer que DFA communique avec les serveurs de collecte Adobe.
Après avoir déployé le fichier DFA s_code.js , utilisez la visionneuse de trafic réseau pour afficher les demandes entre DFA et les serveurs de collecte de données Adobe, en recherchant ce qui suit :
  • A request to DFA's fls.doubleclick.net/json service. Ce service peut répondre différemment selon la version de DFA que vous utilisez. Avec l’intégration de DFA version 1.5 :
    • Une redirection HTTP 302 vers ad.doubleclick.net. Envoie une balise d’emplacement dans la réponse qui contient des informations sur le visiteur de la publicité.
    • This Location tag causes a redirect to integrate.112.2o7.net/dfa_echo. Ce service traduit les informations au sujet du visiteur de la publicité dans la chaîne codée JSON (JavaScript Object Notati on). Ces données sont renvoyées avec une réponse HTTP 200 OK.
  • Avec l’intégration de DFA version 2.0 (fonction AdServing avancée activée) :
    • fls.doubleclick.net répond directement avec une réponse 200 OK.
Dans les deux cas, une demande réussie engendre une demande aux serveurs de collecte de données Adobe qui contient le paramètre vX, où X est votre numéro d’eVar d’affichage publicitaire. Cette valeur de paramètre prend la forme : DFA-XXXX-XXXX- XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX. Cette chaîne contient les données au sujet du dernier clic et de la dernière impression pour le visiteur actuel.

Réglage de s.maxDelay

Une mise en œuvre réussie de DFA implique d’optimiser s.maxDelay pour votre site.
En règle générale, la décision d’augmenter ou de diminuer s.maxDelay implique un compromis entre l’obtention de davantage de données sur les visiteurs DFA et la mise en danger de la collecte de données sur les visiteurs Adobe. Increasing s.maxDelay obtains more DFA visitor data, but (placed excessively high) could endanger the collection of Adobe visitor data. Si vous réduisez s.maxDelay, la collecte des données sur les visiteurs d’Adobe est garantie, mais des données sur les visiteurs de DFA risquent d’être omises.
s.maxDelay ne se contente pas d’encapsuler le temps pris par les communications réseau pour contacter DFA ; il représente également les délais qui s’écoulent avant que le navigateur ne déclenche et n’évalue le code JavaScript sur lequel reposent ces communications. En effet, le module Integrate commence le s.maxDelay minuteur après avoir inséré l’élément HTML dans le modèle DOM qui extrait les données du serveur DFA Floodlight. Le temps pris par le navigateur pour réellement initier la demande HTTP d’après ce nouvel élément HTML varie en fonction des autres images ou des fichiers JavaScript qui se chargent simultanément, de la vitesse de l’ordinateur des visiteurs et des mises en œuvre de navigateur spécifiques. En outre, lorsque les données JSON sont récupérées auprès du serveur DFA Floodlight, le code JavaScript doit être évalué par le navigateur. Ceci dépend entièrement du navigateur et peut être retardé si la quantité de code JavaScript s’exécutant simultanément est conséquente ou s’il y a plusieurs demandes JavaScript asynchrones.
Ainsi, s.maxDelay doit être défini en fonction de la complexité de la page d’entrée et du délai réseau avec DFA. Sur certains sites, l’une des manières possibles de réduire la complexité de la page consiste à déclencher le code de collecte Adobe au début du chargement de la page, de sorte que le navigateur soit moins occupé au moment où le serveur Floodlight est appelé.
La variable de dépassement de délai est obligatoire lors du réglage de s.maxDelay , because it is incremented every time the s.maxDelay timeout is reached. Lorsque vous décidez d’augmenter ou de diminuer s.maxDelay nous vous recommandons de suivre cette procédure :
  1. Collecte plusieurs jours de données avec s.maxDelay une valeur particulière.
  2. Exécutez une Daily Unique Visitors Report pour la période.
  3. Run the Timeout Event Report to check the number of timeouts that are coming through. N’oubliez pas qu’un dépassement de délai est collecté une seule fois par visiteur.
Avec les chiffres dont vous disposez, calculez :
Timeout Percentage = [Step 3] / [Step 2] * 100

Le pourcentage de dépassement de délai prend actuellement en compte tous les visiteurs sur le site. Certains de ces visiteurs peuvent en fait n’avoir aucune connexion avec DFA ; le dépassement de délai est donc trompeur. Pour améliorer ce calcul, une autre analyse consiste à prendre en compte seulement les visiteurs uniques sur les pages avec le paramètre clickThroughParam défini (par exemple, ?CID=1 ). Les résultats seront ainsi plus précis.
Si le pourcentage de dépassement de délai est très faible, envisagez de réduire s.maxDelay . S’il est très élevé, augmentez s.maxDelay . When decreasing s.maxDelay , you will want to rerun the Timeout Report to ensure that timeouts have not dramatically increased. Lorsque vous augmentez s.maxDelay , vous souhaiterez exécuter une Page Views Report pour vous assurer que les pages vues ne tombent pas en panne en raison de données perdues. Each time s.maxDelay is changed observe the data for several days in order to ensure that the data represents a trend, and not just a day-to-day fluctuation.
The optimal setting for s.maxDelay is the point at which the timeout percentage is minimized while Page Views do not drop off.
Les dépassements de délai devraient normalement diminuer quand vous passerez à la version 2.0 de l’intégration, en raison de l’élimination des redirections 302. Les premières conclusions obtenues des utilisateurs de la version bêta ont démontré une réduction constante des dépassements de délai ; davantage de données DFA sont ainsi collectées.