web-dev-qa-db-fra.com

Comment créer et implémenter un code de suivi de pixel

OK, voici un objectif que je cherche depuis un moment. 

Comme on le sait, la plupart des entreprises de publicité et d’analyse utilisent un code dit «pixel» afin de suivre les affichages, les transactions, les conversions, etc. de sites Web. 

J'ai une idée générale sur la façon dont cela fonctionne, le problème est de savoir comment le mettre en œuvre. Les codes de suivi se composent de quelques parties.

  1. Le code de suivi lui-même. Il s’agit du code que l’utilisateur insère sur sa page Web dans la section <head>. L'objectif principal de ce code est de définir des variables spécifiques au client et d'appeler le fichier *.js.

  2. *.js fichier . Ce fichier contient toute la magie des cookies CRUD (créer/lire/mettre à jour/supprimer), suivre les événements de l'utilisateur et son interaction avec la page Web.

  3. Le code de pixel . Il s'agit d'une balise <img> avec l'attribut src pointant vers un fichier image *.gif (par exemple) qui prend tous les paramètres collectés sur la page et les stocke dans la base de données. 

Exemple:

Code pixel WordPress: <img id="wpstats" src="http://stats.wordpress.com/g.gif?host=www.hostname.com&amp;list_of_cookies_value_pairs;" alt="">

Google Analitycs: http://www.google-analytics.com/__utm.gif?utmwv=4&utmn=769876874&etc

Maintenant, il est évident que la requête *.gif doit atteindre un langage de script côté serveur pour pouvoir lire les données de paramètres et les stocker dans une base de données.

Quelqu'un at-il une idée de la façon de mettre en œuvre cela dans Zend? 

UPDATE Une autre chose qui m'intéresse est la suivante: comment éviter au navigateur de l'utilisateur de charger le *.gif en cache? Est-ce qu'une valeur de paramètre aléatoire fera l'affaire? Exemple: src="pixel.gif?nocache=random_number" où la valeur du paramètre nocache sera différente à chaque demande.

zend-frameworktrackingpixel
13
Andrei Stalbe

Comme Zend est construit en PHP, il pourrait être intéressant de lire la question suivante: Développer un pixel de suivi .

En plus de cette réponse et si vous cherchez un moyen d'éviter la mise en cache de l'image de suivi, la méthode la plus simple consiste à lui ajouter une chaîne unique/aléatoire, générée au moment de l'exécution.

Par exemple, côté serveur et avec la création de chaque image, vous pouvez ajouter un identifiant d'URL aléatoire:

<?php

  // Generate random id of min/max length
  $Rand_id = Rand(8, 8);

  // Echo the image and append a random string
  echo "<img src='pixel.php?a=".$vara."&b=".$varb."&Rand=".$Rand_id."'>";

?>
2
nickhar

Eh bien, tous les codes ci-dessus sont corrects et sont bons, mais pour être certain, le gars ci-dessus mentionne "g.gif"

Vous pouvez simplement ajouter un simple code php pour écrire dans un fichier SQL ou fwrite ("fichier.txt", $ open) Où var $ open sert de compteur ++ si quelqu'un ouvre votre courrier ... puis enregistrez-le sous "g .gif "

Pour faire tout cela, il suffit d’ajouter:

<Files "/thisdirectory">
 AddType application/x-httpd-php .gif
</Files>

dans votre fichier ".htaccess" mais assurez-vous de créer un nouveau répertoire pour ce g.gif ou quel que soit le type.gif où le répertoire ne contient que g.gif et .htaccess

0
i am ArbZ

Tout d'abord, le *.gif n'a pas besoin d'être ce type de fichier, la seule chose qui nous intéresse est l'en-tête Content-Type http. Définissez-le sur image/gif (ou tout autre type approprié) au début, exécutez votre code et restituez une sorte d'image dans le corps de la réponse.

0
Femaref

Il suffit d’ajouter mes 2 centimes à ce fil car je pense qu’il manque une option importante et fréquemment utilisée: vous n’avez pas nécessairement besoin d’un langage de script pour capturer la demande. Une approche plus efficace consiste à utiliser le journal d'accès au serveur Web (tel que le journal d'accès Apache, par exemple) pour consigner la demande, puis à le gérer avec les outils de votre choix, tels que la pile ELK, par exemple. 

Cela simplifie considérablement le traitement des demandes, car aucun langage de script n'est chargé pour préparer la réponse, il suffit d'une réponse native Apache, qui est généralement beaucoup plus efficace.

0
Alberto