AMP

Deep dive into AMP analytics

Important: this documentation is not applicable to your currently selected format email!

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>

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 liste de fournisseurs d'analyses.

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 liste de fournisseurs d'analyses.

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

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"
></amp-analytics>

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"
    }
  }
}

IMPORTANT – L'approche ci-dessus n'est recommandée que pour les pages AMP et non pour les annonces AMPHTML. La priorité d'analyse étant plus faible par rapport au contenu de la page, il est recommandé de suivre les clics en utilisant une redirection du navigateur pour éviter la perte de clics.

AMP prend en charge les configurations de déclencheur suivantes:

Configuration du déclencheur Description
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).
vars Objet 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 issus d'une configuration avec une priorité inférieure sont remplacés par des déclencheurs de mêmes noms issus d'une configuration avec une priorité plus élevée (voir Ordre de 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 transport Description
beacon Indique 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.
xhrpost Indique 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.
image Indique que la requête peut être envoyée en générant une balise Image. Cela envoie une requête GET.

Une seule méthode de transport est utilisée, et c'est celle avec la priorité la plus élevée qui est activée, autorisée et disponible. L'ordre de priorité est beacon > xhrpost > image. Si l'agent utilisateur du client ne prend pas en charge une méthode, la méthode de priorité la plus élevée suivante activée est utilisée.

N'incluez l'attribut de transport dans votre configuration que si vous souhaitez limiter les options de transport, sinon vous pouvez 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 s'ils ont une priorité plus élevée que image. Si l'agent utilisateur du client prend en charge la méthode image, elle sera utilisée; sinon, aucune demande n'est envoyée.

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

Ordonnancement de la substitution des variables

AMP remplit les variables avec des valeurs dans un ordre de priorité:

  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, il existe une configuration à distance, des variables définies au niveau supérieur, dans les déclencheurs et 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 la même variable var est définie dans plusieurs emplacements, la commande variable de priorité définit sa valeur une fois. Ainsi, si la configuration à distance a défini account comme UA-XXXXX-Y dans l'exemple ci-dessus, les valeurs des différentes variables seront les suivantes:

var Valeur Défini par
canonicalUrl http://example.com/path/to/the/page Plateforme
title My homepage Déclencheur
account UA-XXXXX-Y Configuration distante
clientId my user Déclencheur