Wagablog

Yet another web analytic’s blog

Archive for the ‘Google Analytics’ Category

EDIT MARS 08 : Les champs perso sont a nouveaux exploitables en écriture depuis le 12 mars

Juste un petit point pour prévenir que les deux champs personnalisés (”custom field”) qu’on pouvait utiliser pour stocker une valeur de notre choix sont désormais interdits à l’écriture.

On n’a eu aucune communication officielle de Google à ce sujet, donc les utilisateurs de filtres avancés en cascades s’en sont rendu compte au fur et à mesure que les rapports ne remontaient plus les données…

Il semble qu’il y ait eu une release le 8 janvier puis une autre le 14 janvier. Donc tous les comptes n’ont pas été impactés en même temps.

La solution consiste à utiliser d’autres champs permettant de stocker temporairement des données, comme le champ “user defined” (”valeur personnalisée”) ou “Contenu de la campagne” si on n’en a pas besoin par ailleurs.

Les codeurs de chez Google nous ont concocté un petit PDF permettant de faire le point sur les différences entre urchin.js et ga.js. C’est également l’occasion de faire le tour sur toutes les possibilités de configuration du GATC.

- Le nouveau marqueur prépare de futures nouvelles fonctionnalités qui sont dans le pipe des équipe GA (nouveaux types d’objectifs de conversion, nouveaux rapports dédiés aux interfaces riches…)

- il est possible de continuer à utiliser unrchin.js pendant encore au moins un an, mais les nouvelles fonctionnalités ne seront accessibles qu’avec le ga.js. Attention : le nouveau et l’ancien marqueur ne sont pas compatibles ==> ne pas utiliser les deux sur une même page.

(more…)

Le nouveau GATC est arrivé -> ga.js

Google Analytics a déployé officieusement hier son nouveau marqueur et le nouveau fichier javascript ga.js (en remplacement de urchin.js). Aucune annonce officielle n’a été faire, mais le “Centre d’aide” a été mis à jour et le marqueur est désormais proposé par défaut sur l’interface.

news-old.gif

Le marqueur de base était auparavant de la forme :

<script src=”http://www.google-analytics.com/urchin.js” type=”text/javascript”>
</script>
<script type=”text/javascript”>
_uacct = “UA-XXXXXXX-1″;
urchinTracker();
</script>

Le nouveau marqueur ressemble à ça :

<script type=”text/javascript”>
var gaJsHost = ((”https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);
document.write(”\<script src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’>\<\/script>” );
</script>
<script type=”text/javascript”>
var pageTracker = _gat._getTracker(”UA-XXXXXXX-1″);
pageTracker._initData();
pageTracker._trackPageview();
</script>

(more…)

Afin de mieux comprendre comment fonctionne Google Analytics, il est important de se pencher sur les cookies qu’il utilise. Tout d’abord, il faut savoir que GA gère des cookies first party, c’est à dire des cookies qui sont posés par le domaine en cours dans la barre d’adresse, par opposition aux cookies tierce partie (”third party”) qui sont posés par un domaine distant.

L’avantage d’un cookie first party, c’est qu’il sera beaucoup moins fréquemment rejeté par un paramétrage de sécurité du navigateur ou par les logiciels bloqueurs de publicités.
L’inconvénient, c’est que les données placées dans le cookie ne seront pas propagées d’un domaine à l’autre : on perd ainsi le tracking à chaque changement de domaine lors de la navigation de l’internaute. C’est là qu’interviennent les fonctions __utmLinker et __utmLinkPost.
(more…)

La nouvelle fonctionnalité d’analyse de la recherche sur site qui est sortie hier en anglais est désormais disponible même pour ceux qui ont leur interface configurée en français.

Pour l’activer, il faut modifier les informations relatives au profil :
On peut spécifier jusqu’à cinq nom de paramètre de requête, et autant de paramètre de catégorie (pour les sites qui permettent la recherche dans une catégorie précise).

config1.gif
(more…)

Google vient d’annoncer au salon eMetrics une série de nouveautés à venir pour Google Analytics. Ces nouvelles fonctionnalités seront ouvertes en beta test limité dans les semaines ou mois qui viennent. A terme, le nom du .js à héberger ne sera plus urchin.js, mais ga.js

On devrait notamment voir arriver un nouveau rapport dédié au tracking des utilisateur d’un moteur de recherche interne (pour les sites qui en proposent un à leurs utilisateurs). Il faudra activer ce rapport dans le paramétrage du profil. Il permettra semble-t-il d’obtenir un certain nombre d’informations comme :

  • le nombre de visites sur les pages de résultat,
  • le nombre total de recherches uniques,
  • le nombre moyen de pages de résultats vues par recherche,
  • le taux de sortie du site suite à une recherche,
  • le taux de re-précision d’une requête (c’est comme ça qu’on dit ?)
  • le temps passé sur le site suite à une recherche.
  • les conversions / transactions générées par tel ou tel mot clé cherché

Ce sera peut-être l’occasion pour Google de revoir le traitement de son service de moteur de recherche Google Custom (http://www.google.com/coop/cse/). En effet, lorsque celui-ci est installé sur un site, les recherches qui y sont exécutées remontent sur GA dans les rapport moteurs de recherche > Google, comme des mots clés tapés sur l’interface Google classique (ceci est du au fait que le referer commence par http://www.google.com/).
Ceci dit, nous avions déjà expliqué sur ce blog comment configurer GA pour logguer les requêtes d’un moteur de recherche interne. Avec cette nouveauté la manip devrait être plus simple et la segmentation des utilisateur du moteur se fera en natif. Toutefois, cette fonctionnalité ne devrait être accessible qu’aux moteur envoyant les requêtes dans l’url, et non en POST…

- Autre nouveauté, ceux qui installeront le nouveau javascript pourront exploiter le tracking des actions des visiteurs sur certains média et techno comme Ajax, Flash et d’autres composants multimédia. De nouveaux rapports seront ainsi disponible sous l’appellation “Event Tracking” (pour la version anglaise)

- toujours avec ga.js, le tracking des liens sortants se fera désormais automatiquement, sans utilisation du Urchin Tracker. On attend de voir comment sera géré le tracking des clics sur les liens vers un domaine suivit sur un même compte GA.

Maintenant que Google a annoncé ces évolutions on est tous impatients de voir ça, alors j’espère qu’on va pas devoir attendre trop longtemps pour leur sortie effective ;)

Des filtres avancés en cascade…

Aujourd’hui, nous allons voir comment utiliser les “filtres avancés en cascade” selon une méthode présentée par l’excellent blog de Lunametrics.

Il faut d’abord comprendre que les filtres sont appliqués dans un certain ordre, le deuxième s’appliquant avec les résultats issus du premier et ainsi de suite. C’est d’ailleurs pour cette raison qu’il est possible de redéfinir l’ordre des filtres dans l’interface.

Ordre filtres GA

Le principe est de créer un premier filtre dont le résultat sera stocké dans un des deux champs personnalisés qu’offre Google Analytics. Puis nous allons récupérer la valeurs de ce champs dans un deuxième filtre afin de le retraiter, et ainsi de suite tout au long du process de filtres mis en place.

Dans l’exemple ci dessous, nous allons concaténer les valeurs de certains champs de l’application afin de générer un rapport qui permettra d’enrichir les lignes de transaction (dans le cadre d’un site ecommerce) avec les données de source de trafic (support, source et termes des campagnes)

(more…)

Multiples domaines et sous domaines

Lorsque vous avez différents sous domaines à analyser avec un même compte, il convient de modifier le marqueur de la façon suivante:
<script src=”http://www.google-analytics.com/urchin.js” type=”text/javascript”></script>
<script>
_uacct = ‘UA-XXXXXX-X’; // votre identifiant de compte
_udn = “domaine.com”; /* force l’appel du cookie du domaine spécifié. Autrement, GA tente de récupérer le cookie du host présent dans la barre d’adresse et créera un nouveau cookie s’il n’en trouve pas déjà, ce qui risque de dupliquer vos visiteurs de et vous faire perdre le referrer d’origine */
urchinTracker();
</script>

(more…)

[resolu] Bug Google Analytics

Mise à jour du 3 septembre : le bug Analytics est résolu ! Vous pouvez repasser votre compte en Français :)

—————-

Depuis plusieurs jours maintenant, un bug sur GG Analytics en Français empêche la recherche au sein d’un rapport ou bien l’affichage de plus de dix lignes.

Les italiens ont le même problème.

La solution consiste a switcher le language du compte en anglais :

Modifier la langue du compte

Un case semble avoir été loggué avant le 20 aout auprès des ingénieurs concernés

Lorsque vous avez un moteur de recherche sur votre site, le traitement des requêtes peut être effectué en POST ou en GET.

En GET : les requêtes de vos visiteurs sont visibles dans l’URL.
Par exemple :
http://www.monsite.com/moteur.php?recherche=blabla
où blabla est votre requête
Une solution pour identifier ces requêtes consisterait à appliquer un filtre avancé modifiant l’URI de la demande de la manière suivante :
Champ A : URI de la demande
Extraire A : ^/moteur\.php\?recherche=(.*)$
Sortie vers : URI de la demande
Constructeur : /moteur/$A1

Vous auriez alors vos requêtes bien rangée dans un rapport adoc…
Mais celà ne serait pas forcément très utile alors qu’il suffirait dans le rapport “Pages les plus consultées” de filtrer les pages contenant /moteur.php de la façon suivante :
URIs contenant moteur.php
De cette manière, vous conservez l’historique des recherches de vos visiteurs, et vous pouvez extraire les données dans un tableau excel si vous souhaitez nettoyer les urls.

Dans le cas où les résultats du moteur peuvent être nombreux et présentent une pagination ou des options de tri, le problème est plus complexe puisque vous pouvez vous retrouver avec des URI du type :
/moteur.php?recherche=blabla&page=2&tri=prix
Et comme les conditions négatives en regexp ne semblent pas fonctionner dans les filtres des rapports, mieux vaut utiliser la méthode décrite ci-dessous.

En POST, les choses se compliquent un peu, puisque quelque soit la requête de l’internaute, l’URL des résultats de recherche reste systématiquement la même :
http://www.monsite.com/moteur.php par exemple
(more…)



Archives :


Reseau :