Google impose le HTTPS et not provided

Google impose désormais sa recherche sécurisée (HTTPS) à tous ses utilisateurs. Ceci empêche les webmasters de connaître les mots-clés générateurs de trafic et renvoie un “not provided”. La seule solution pour les webmestres est d’acheter des publicités AdWords…

Voici ce que vous trouvez maintenant sur votre interface Google Analytics:

exemple not-provided

Interface Google Analytics, résultat de type (not provided)

 

Commençons par un petit rappel des définitions:

Définition web du mot referrer

Referrer, parfois écrit référent en français correspond à l’url de provenance quand un internaute clique sur un lien dans son navigateur pour aller d’une page d’un site A à une page d’un site B. Le navigateur transmet au site B l’URL de la page du site A. Le webmaster du site B peut ainsi identifier précisément la provenance du visiteur. Dans Google Analytics, l’ensemble du trafic généré par les liens est regroupé dans les “Sites référents”.

 

Définition de l’expression “not provided”

Quand le site référent est un moteur de recherche, plutôt que de simplement indiquer l’URL de la page de provenance (qui contient en général de nombreux paramètres peu compréhensibles), les outils de web analytics tels que Google Analytics récupèrent parmi ces paramètres ce qu’on appelle la requête, c’est-à-dire les mots-clés tapés par l’internaute.

Sous prétexte que ces mots-clés peuvent contenir des données personnelles, Google a décidé en 2010 qu’il pouvait être utile de supprimer cette information. Ainsi, dans certains cas à l’époque, le webmaster qui recevait du trafic en provenance de Google ne pouvait plus identifier le mot-clé puisque Google le coupait en amont (avant que l’internaute n’arrive sur le site). N’ayant aucun mot-clé fourni à afficher, Google Analytics a décidé d’indiquer “(not provided)”.

 

Historique des changements concernant le “not provided”

Google a petit à petit imposé la recherche en mode sécurisée à tous ses utilisateurs et depuis quelques semaines, le nombre d’utilisateurs, concernés par ces changements, est monté fortement.

Ces changements de Google se sont traduits immédiatement par une hausse brutale du not provided comme on peut le voir sur le site notprovidedcount.com :

not provided augmentation modification

Augmentation des not-provided (source: notprovidedcount.com)

 

 

Voici la chronologie complète des recherches Google en mode sécurisé :

  • Mai 2010 : Google lance la recherche en mode sécurisé. Les internautes qui l’utilisent privent les outils de web analytics d’informations sur la recherche effectuée.
  • Octobre 2011 : uniquement sur google.com, tous les utilisateurs connectés à leur compte Google sont automatiquement basculés sur la recherche sécurisée. Hausse importante et immédiate du not provided aux Etats-Unis.
  • Mars 2012 : ce fonctionnement est alors étendu à toutes les versions de Google, y compris google.fr, ce qui fait exploser la part du not provided dans les statistiques des sites français. 10% des recherches sont effectuées par https/ au bout de quelques semaines.
  • Juillet 2012 : avec la sortie de sa version 14, Firefox utilise désormais Google en mode sécurisé pour faire toutes les recherches via la barre de recherche du navigateur.
  • Septembre 2012 : avec la sortie de iOS6, Safari sur mobiles utilise lui aussi Google en mode sécurisé, mais pour une raison inconnue (source: http://searchengineland.com/ios-6-removes-all-google-search-referer-data-134560), la conséquence en termes de web analytics est pire puisqu’ aucun referrer n’est transmis. Le not provided ne progresse pas mais la part de requêtes connues chute d’autant.
  • Janvier 2013 : Google impose la recherche SSL à tous les internautes utilisant Chrome 25 (connectés ou non au compte Google).
  • Septembre 2013 : Google impose petit à petit le SSL à tous les internautes… C’est la généralisation du not provided !

 

Des solutions au not provided?

Il n’y a pas de solution “simple” à ce problème. 

Aucun outil de mesure d’audience, qu’il soit basé sur un marqueur dans les pages web ou sur les logs, ne peut résoudre le problème du not provided, puisque Google supprime l’information en amont, avant que l’internaute ne quitte réellement le moteur de recherche…

Question que l’on peut se poser:

  • si Google passe effectivement en HTTPS, on ne devrait même pas avoir de referrer, alors y en a-t-il ou pas ?

Une fois l’internaute sur Google, Google le renvoie dans tous les cas vers une version sécurisée reconnaissable au fait qu’elle utilise le protocole HTTPS.

Au moment où l’internaute clique sur le lien dans les résultats, Google n’envoie pas l’internaute directement vers le site web externe concerné : il le fait passer par une URL intermédiaire utilisant le protocole HTTP (et non plus HTTPS). Cette URL est transmise alors en tant que referrer au site web qui reçoit la visite. Dans cette URL où est codée la requête de l’internaute, il ne reste plus rien : Google a supprimé la valeur du paramètre “q” (ou ses variantes).

La solution du rapport de trafic dans Google Webmaster Tools

Malgré cette politique visant à masquer des données, Google continue de fournir les mots-clés générateurs de trafic en référencement naturel mais uniquement de façon décorrélée des sessions.

Concrètement, il s’agit d’une liste de requêtes ayant généré du trafic vers votre site depuis les SERP Google (SEO), avec la page d’arrivée.

C’est une fausse solution au problème du not provided, puisque vous ne pouvez pas l’efficacité de ces visites. Vous ne pouvez pas mesurer un taux de conversion (ou “transformation”) et encore moins des ventes générées. Vous ne pouvez pas calculer de ROI à moins d’opter pour la solution payante Google Adwords, voir plus loin.

A l’heure actuelle, ce rapport des requêtes les plus fréquentes dans Google Webmaster Tools est limité par les contraintes suivantes :

  • aucun lien avec la notion de session et donc de taux de transformation
  • seules les données des 90 derniers jours sont accessibles (Google pourrait étendre cet historique à 1 an).Vous pouvez télécharger les données mais ce n’est pas la panacée.
  • seules les 2000 principales requêtes du jour peuvent être listées

 

La solution Google AdWords

Lorsqu’il s’agit de contenter ses annonceurs AdWords (ceux qui contribuent à 95% des revenus de Google), Google n’éprouve plus le besoin de protéger la vie privée de ses utilisateurs alors qu’il se sert de ce prétexte pour mettre en place sa version sécurisée de recherche. Etonnant non?

Cela fait froid dans le dos mais vous devez vous faire à l’idée de devoir payer et obtenir du trafic depuis Google pour pouvoir connaître d’où viennent vos visiteurs, par quels mots clés ils sont arrivés sur votre site et quels mots clés ont généré une conversion / vente.

Une fois que vous aurez paramétré une ou plusieurs campagne AdWords et qu’elles tourneront, vous aurez donc à nouveau accès aux rapports sur les requêtes “termes de recherche”. Mais attention, ce rapport ne liste pas toutes les recherches avec autant d’exhaustivité que l’ancienne version Google non sécurisée.

 

Conclusion

La globalisation de ce cryptage des données et l’arrivée du not provided est une véritable catastrophe pour tout webmaster qui souhaite étudier ces mots clés et analyser et optimiser son audience web.

 

Un commentaire to “Google impose le HTTPS et not provided”

Laisser un commentaire

Vous devez être connecté pour laisser un commentaire.