Google s'est fendu d'un communiqué officiel le 28 janvier 2016 pour indiquer que le projet AMP (Accelerated Mobile Pages) est enfin compatible avec Google Analytics. Ce communiqué a fait suite à un article du même jour paru sur le blog officiel du projet AMP dont Google est un fer de lance.
Comme l'adage de Google le dit : "la rapidité est meilleure que la lenteur". Fort de ce constat ô combien surprenant (vous comprendrez mon ironie...), le projet d'accélération des pages sur mobiles est devenu un objectif phare de la firme leader de la recherche. Désormais, il risque d'être difficile de compter sans lui, et c'est même à se demander si Google verra encore un intérêt à l'HTML initial tant il parle d'AMP HTML à tout bout de champ.
Un des principaux problèmes rencontrés avec AMP HTML est le tracking des pages avec Google Analytics. Sachez qu'il est maintenant possible de suivre les versions AMP sans problème, grâce à l'introduction du couple de balises <amp-analytics>...</amp-analytics>. Auparavant, il fallait jouer avec le tag <amp-pixel> et espérer que cela fonctionne, ce qui était loin d'être le cas en général. Si vous voulez tout savoir sur la balise <amp-analytics>, la documentation officielle du projet a été mise à jour.
Cette nouvelle balise <amp-analytics> est assez intéressante car elle intègre un script de configuration personnalisé qui regroupe tous les événements et tracking des pages. Plus besoin d'aller ajouter des événements avec parcimonie au sein du code source, il suffit de tout ajouter entre les balises <script>...</script> (JSON) intégrées au sein du couple <amp-analytics>...</amp-analytics> (voir capture ci-dessus). En d'autres termes, comme l'indique le communiqué officiel :
(...) Vous pouvez définir les actions qui devraient déclencher des suivis au sein du script de configuration et laisser la magie de l'AMP faire le reste.
Il est possible de configurer Analytics via JSON, à partir de plusieurs paramètres :
- Le paramètre requests contient un objet JSON qui permet d'indiquer les événements à suivre (tracking), définis dans "triggers".
- Le paramètre vars récupère les variables utiles au bon fonctionnement d'Analytics, décrites ici. Vous pouvez par exemple indiquer le titre de la page via "title", l'URL canonique via "canonicalURL" et surtout "account" qui correspond au compte Analytics.
- Le paramètre triggers inclue l'ensemble des événements dans un objet JSON. Il est possible de donner un nom au type de tracking comme "pageview", "event", récupéré au sein du paramètre "requests". 4 propriétés sont possibles :
- on (requis) : type d'événement à écouter ("click"ou "visible").
- request (requis) : indique le nom de la requête à envoyer, spécifiée dans la section "requests".
- selector : sélecteur CSS sur lequel appliquer le tracking. Par exemple "a" pour suivre les clics sur les liens. Le sélecteur universel "*" est autorisé pour tout suivre.
- vars : permet de créer des paires clé/valeur à suivre et à intégrer au sein des URL de suivis (section "requests"). Par exemple, si nous créons une variable "machin:truc", il est possible de récupérer dynamiquement sa valeur en ajoutant "&machin=${machin}".
- Le paramètre transport indique le type de méthode d'envoi, qui peut être "xhrpost", "beacon" ou "image", avec une valeur booléenne (true/false).
Enfin, pour conclure sur les aspects techniques du suivi Analytics en AMP HTML, sachez que la balise ouvrante <amp-analytics> peut aussi accueillir deux attributs (optionnels) :
- type : indique le type de fournisseur à suivre. Pour le moment, seule la valeur "googleanalytics" est autorisée (tiens donc... ^^).
- config : précise un chemin vers une ressource JSON qui contient la configuration. Cela permet de gérer la configuration dans un fichier externe plutôt qu'entre des balises <script>. Il faut savoir que l'URL de chemin doit forcément être en HTTPS dans ce cas, comme dans cet exemple : <amp-analytics config="https://www.site.com/analytics.json"></amp-analytics>.
Vous savez tout sur la mise en place du tracking de base de Google Analytics en AMP HTML. Toutefois, je ne vous cache pas que le côté pratique du JSON n'a pas que des avantages. En effet, les modifications en direct comme dans le plugin officiel WordPress ou celui que je développe actuellement vont être beaucoup plus difficiles à gérer (voire impossible). Il faudra certainement privilégier des fichiers JSON à part pour se faciliter la tâche, mais cela s'ajoute aux nombreux autres cas particuliers du projet AMP (c'est sûrement son seul défaut majeur).