AMP

AMP Analytics dans le détail

Ce guide propose une analyse détaillée du amp-analytics, en divisant un exemple de configuration de la balise amp-analytics en quatre catégories principales :

Le reste de ce guide utilise cet exemple de configuration qui effectue le suivi des vues de page et des clics des utilisateurs sur des liens, et envoie les données d'analyse à un fournisseur tiers, Google Analytics:

<amp-analytics type="googleanalytics" config="https://example.com/analytics.account.config.json">
<script type="application/json">
{
  "requests": {
    "pageview": "https://example.com/analytics?url=${canonicalUrl}&title=${title}&acct=${account}",
    "event": "https://example.com/analytics?eid=${eventId}&elab=${eventLabel}&acct=${account}"
  },
  "vars": {
    "account": "ABC123"
  },
  "extraUrlParams": {
    "cd1": "AMP"
  },
  "triggers": {
    "trackPageview": {
      "on": "visible",
      "request": "pageview"
    },
    "trackAnchorClicks": {
      "on": "click",
      "selector": "a",
      "request": "event",
      "vars": {
        "eventId": "42",
        "eventLabel": "clicked on a link"
      }
    }
  },
  'transport': {
    'beacon': false,
    'xhrpost': false,
    'image': true
  }
}
</script>
</amp-analytics>

Remarque : Le code illustré ci-dessus est fourni à titre d'exemple pour vous aider à apprendre, mais il ne constitue en rien un exemple réaliste. Si vous travaillez avec des fournisseurs de solutions d'analyse, il est probable que cet exemple n'ait pas de sens ; les configurations du fournisseur simplifieront les choses. Pour obtenir des exemples de configuration de votre fournisseur, consultez sa documentation.

Où envoyer les données d'analyse : l'attribut type

AMP est conçu pour prendre en charge deux modèles courants de collecte des données :

  • L'ingestion par un point d'extrémité appartenant à un éditeur pour les systèmes d'analyse interne
  • L'ingestion par un point d'extrémité appartenant à un fournisseur aux fins d'interopérabilité avec la solution du fournisseur (par exemple, Adobe Analytics, Chartbeat ou encore Google Analytics)

Pour envoyer des données d'analyse à un fournisseur de solutions d'analyse, incluez l'attribut type dans la balise amp-analytics, et définissez sa valeur sur le fournisseur approprié, tel que défini dans la spécification du composant amp-analytics.

Par exemple, <amp-analytics type="googleanalytics"> envoie les données d'analyse au fournisseur de solutions d'analyse tiers Google Analytics. Pour envoyer les données à un point d'extrémité appartenant à l'éditeur, il vous suffit de ne pas inclure l'attribut type ; les données d'analyse sont envoyées aux points d'extrémité définis pour chaque requête.

Les configurations des fournisseurs de solutions d'analyse constituent un bon point de départ pour commencer avec le composant amp-analytics. Pour en savoir plus, consultez la documentation et les ressources d'aide de votre fournisseur. Comme nous l'avons déjà indiqué, la liste des fournisseurs qui proposent déjà une intégration AMP ainsi que des liens vers leurs ressources respectives sont disponibles dans la spécification du composant amp-analytics.

Si vous êtes un fournisseur de solutions d'analyse, découvrez comment intégrer votre propre configuration d'analyse dans AMP HTML.

Charger une configuration distante : l'attribut config

Il n'est pas nécessaire d'inclure toutes les configurations de amp-analytics dans votre page AMP. En lieu et place, vous pouvez appeler une URL distante pour tout ou partie des configurations.

Cela vous permet entre autres de faire varier la configuration en fonction d'une requête spécifique. Si, en tant qu'éditeur, vous avez le contrôle du fichier distant, vous pouvez effectuer tout traitement nécessaire côté serveur pour créer les données de configuration.

Pour charger les configurations distantes, la première étape consiste à inclure l'attribut config dans la balise amp-analytics :

<amp-analytics config="https://example.com/analytics.account.config.json">

L'étape suivante consiste à créer le contenu JSON qui réside dans l'URL distante. Dans cet exemple simple, la configuration contenue dans l'objet JSON est juste la valeur de variable due compte d'analyse.

Exemple de contenu dans https://example.com/analytics.account.config.json :

{
  "vars": {
    "account": "UA-XXXXX-Y"  // Replace with your property ID.
  }
}

La dernière étape consiste à vous assurer que ce qui se trouve dans le fichier distant est inséré à l'endroit approprié dans la configuration de amp-analytics. Dans les requêtes pageview et event de cet exemple, la valeur de la variable account est automatiquement définie sur la valeur du compte indiqué dans l'URL distante ("account": "UA-XXXXX-Y") :

"requests": {
  "pageview": "https://example.com/analytics?url=${canonicalUrl}&title=${title}&acct=${account}",
  "event": "https://example.com/analytics?eid=${eventId}&elab=${eventLabel}&acct=${account}"
}

Important : AMP ne valide pas les usages multiples d'une même variable. Les valeurs sont renseignées en fonction d'un ordre de préférence de substitution des variables, et les valeurs indiquées dans les URL distantes sont en première position (voir Ordonnancement de la substitution des variables).

Les attributs requests, triggers et transport

L'attribut requests détermine quelles données sont envoyées (par exemple pageviews ou events) et où ces données sont envoyées (les URL utilisées pour transmettre les données).

L'attribut triggers indique à quel moment les données d'analyse doivent être envoyées, par exemple lorsqu'un utilisateur affiche une page ou clique sur un lien.

L'attribut transport indique comment envoyer une requête, et plus spécifiquement le protocole.

Lisez la suite pour en savoir plus sur ces configurations. (Vous pourrez également en apprendre davantage sur ces configurations dans la amp-analytics

Quelles données sont envoyées : l'attribut requests

La valeur request-name est utilisée dans la configuration du déclencheur pour déterminer quelle requête envoyer en réponse à un événement en particulier. La valeur request-value est une URL https. Ces valeurs peuvent inclure des jetons d'espace réservé pouvant renvoyer à d'autres requêtes ou variables.

"requests": {
  "pageview": "https://example.com/analytics?url=${canonicalUrl}&title=${title}&acct=${account}",
  "event": "https://example.com/analytics?eid=${eventId}&elab=${eventLabel}&acct=${account}"
}

Certains fournisseurs de solutions d'analyse (notamment Google Analytics) ont déjà fourni une configuration, que vous utilisez via l'attribut type. Si vous utilisez un fournisseur de solutions d'analyse, il se peut que vous n'ayez pas besoin d'inclure l'information requests. Reportez-vous à la documentation de votre fournisseur pour savoir si l'attribut requests doit être configuré et, le cas échéant, comment le configurer.

Ajout d'une URL de requête : Attribut extraUrlParams

L'attribut extraUrlParams spécifie des paramètres additionnels à ajouter à la chaîne de requête de l'URL de requête via la convention usuelle « &foo=baz ».

L'exemple amp-analytics ajoute un paramètre additionnel cd1 à la requête et définit la valeur de ce paramètre sur « AMP » :

"extraUrlParams": {
  "cd1": "AMP"
}

Lorsque les données sont envoyées : l'attribut triggers

L'attribut triggers indique le moment auquel une requête d'analyse doit être envoyée. Il contient une paire clé/valeur précisant le nom et la configuration du déclencheur. Le nom du déclencheur peut être n'importe quelle chaîne composée de caractères alphanumériques (a-zA-Z0-9).

Par exemple, le composant amp-analytics suivant est configuré pour envoyer une requête à https://example.com/analytics lorsque le document est chargé pour la première fois et à chaque fois que l'on clique sur la balise a :

"triggers": {
  "trackPageview": {
    "on": "visible",
    "request": "pageview"
  },
  "trackAnchorClicks": {
    "on": "click",
    "selector": "a",
    "request": "event",
    "vars": {
      "eventId": "42",
      "eventLabel": "clicked on a link"
    }
  }
}

AMP prend en charge les configurations suivantes pour le déclencheur :

Configuration du déclencheurDescription
on (obligatoire)Événement à écouter. Les valeurs valides sont click, scroll, timer et visible.
request (obligatoire)Nom de la requête à envoyer (tel que spécifié dans les requêtes ).
varsObjet contenant des paires clé/valeur utilisé pour remplacer la valeur vars dans la configuration de premier niveau ou pour spécifier une valeur vars unique à ce déclencheur (voir également Ordonnancement de la substitution des variables).
selector (obligatoire lorsque on est défini sur click)Sélecteur CSS utilisé pour définir plus précisément les éléments à suivre. Utilisez la valeur * pour suivre tous les éléments. Cette configuration est utilisée conjointement avec le déclencheur click. Découvrez comment utiliser le sélecteur pour suivre les clics sur une page et les interactions sociales.
scrollSpec (obligatoire lorsque on est défini sur scroll)Définit les conditions en fonction desquelles l'événement scroll est déclenché lorsque l'on fait défiler la page. Cet objet peut contenir les propriétés verticalBoundaries et horizontalBoundaries. Au moins l'une des deux propriétés est obligatoire pour qu'un événement scroll soit déclenché. Les valeurs de chacune des propriétés doivent être des ensembles de nombres contenant les limites pour lesquelles un événement scroll est généré. Voir cet exemple sur le suivi du défilement.
timerSpec (obligatoire lorsque on est défini sur timer)Définit les conditions en fonction desquelles l'événement timer est déclenché. L'événement timer est déclenché immédiatement, puis à un intervalle spécifié. Cette configuration est utilisée conjointement avec le déclencheur timer.

Important : Les déclencheurs d'une configuration dont la priorité est inférieure sont annulés par les déclencheurs du même nom dont la priorité est supérieure (voir Ordonnancement de la substitution des variables).

Comment les données sont envoyées : l'attribut transport

L'attribut transport indique comment envoyer une requête. Les trois modes suivants sont activés par défaut :

Mode de transportDescription
beaconIndique qu'il est possible d'utiliser navigator.sendBeacon pour transmettre la requête. Cela envoie une requête POST avec des identifiants et une section body vide.
xhrpostIndique qu'il est possible d'utiliser XMLHttpRequest pour transmettre la requête. Cela envoie une requête POST avec des identifiants et une section body vide.
imageIndique que la requête peut être envoyée en générant une balise Image. Cela envoie une requête GET.

Un seul mode de transport est utilisé : celui qui est activé, autorisé, disponible et dont la priorité est la plus haute. La priorité est beacon > xhrpost > image. Si l'user-agent du client ne prend pas en charge un mode, c'est le mode suivant dans l'ordre de priorité qui est utilisé.

N'incluez l'attribut transport dans votre configuration que si vous souhaitez limiter les options de transport. Vous risquez sinon d'arrêter les requêtes.

Dans l'exemple ci-dessous, beacon et xhrpost sont définis sur false. Ils ne seront donc pas utilisés même si leur priorité est supérieure à celle du mode image. Si l'user-agent du client prend en charge le mode image, il sera utilisé. Sinon, aucune requête n'est envoyée.

'transport': {
  'beacon': false,
  'xhrpost': false,
  'image': true
}

Ordonnancement de la substitution des variables

AMP renseigne les valeurs des variables dans l'ordre de priorité suivant :

  1. Configurations distantes (via config).
  2. vars imbriqué dans un déclencheur dans triggers.
  3. vars au niveau supérieur imbriqué dans amp-analytics.
  4. Valeurs fournies par la plateforme.

Dans cet exemple, nous avons une configuration distante, des variables définies au niveau supérieur dans triggers et des valeurs au niveau de la plateforme :

<amp-analytics config="http://example.com/config.json">
<script type="application/json">
{
  "requests": {
    "pageview": "https://example.com/analytics?url=${canonicalUrl}&title=${title}&acct=${account}&clientId=${clientId(cid-scope)}",
  },
  "vars": {
    "account": "ABC123",
    "title": "Homepage"
  },
  "triggers": {
    "some-event": {
      "on": "visible",
      "request": "pageview",
      "vars": {
        "title": "My homepage",
        "clientId": "my user"
      }
  }
}
</script>
</amp-analytics>

Lorsque le même var est défini à plusieurs endroits, l'ordre de priorité de la variable définit sa valeur une fois. Ainsi, si la configuration distante définit account sur UA-XXXXX-Y, comme dans l'exemple ci-dessus, les valeurs des différentes occurrences de vars sont les suivantes :

varValeurDéfini par
canonicalUrlhttp://example.com/path/to/the/pagePlateforme
titleMy homepageDéclencheur
accountUA-XXXXX-YConfiguration distante
clientIdmy userDéclencheur