Skip to main content
Chaque requête que vous construisez dans l’Explorer est une instruction AftersellQL (AQL). La plupart du temps, vous construisez les requêtes visuellement et n’écrivez jamais d’AQL à la main ; cette page est la référence des métriques et dimensions que vous pouvez choisir, de la forme textuelle de l’AQL et des règles de fuseau horaire.

Métriques disponibles

Voici les métriques que vous pouvez choisir, regroupées de la même manière que dans le sélecteur de métriques.

Revenus et profit

Conversions

Engagement

Performance de la boutique

Réseau Rokt

Dimensions

Les dimensions ventilent une métrique selon un attribut. Toutes les dimensions ne sont pas compatibles avec toutes les métriques ; l’Explorer empêche automatiquement les combinaisons incompatibles (par exemple, Decline rate et Show rate ne peuvent pas être ventilés par Currency).

Dimensions disponibles

Dimensions non disponibles

Les dimensions suivantes sont en cours de développement. Elles apparaissent dans le sélecteur mais s’affichent comme « Not compatible » pour toutes les métriques jusqu’à leur implémentation.

Syntaxe des instructions AQL

Une instruction AQL est une question unique composée de clauses. Seuls SELECT et une plage de dates (SINCE) sont obligatoires ; tout le reste est facultatif. Lorsque vous incluez des clauses facultatives, elles doivent apparaître dans cet ordre :
Un exemple minimal, les revenus d’upsell et le taux d’acceptation quotidiens sur les 30 derniers jours :
Les mots-clés ne sont pas sensibles à la casse (SELECT et select fonctionnent tous les deux) et les instructions ne se terminent pas par un point-virgule. Les valeurs de type chaîne sont entourées de guillemets doubles ; les nombres et les listes ne le sont pas.

SELECT et GROUP BY

  • SELECT liste les métriques à mesurer, séparées par des virgules, par exemple SELECT revenue, impressions, accept_rate.
  • GROUP BY ventile ces métriques selon une ou plusieurs dimensions, comme date, device, surface ou funnel. Sans GROUP BY, vous obtenez un total unique pour toute la période.

Filtrer avec WHERE

WHERE restreint les données avant qu’elles ne soient mesurées. Combinez les conditions avec AND.
impressions, accept_rate et rpv ne peuvent pas être filtrés ni regroupés par appareil, funnel, emplacement ou produit ; leur agrégat source ne contient pas de telle colonne. Ajouter WHERE device = "mobile" à une requête sélectionnant l’une de ces métriques est rejeté avec metric "impressions" cannot be filtered by "device".
Les comparaisons prises en charge sont =, !=, IN, NOT IN, >, <, >= et <=. Utilisez une liste avec IN pour faire correspondre plusieurs valeurs :
experiment n’est pas un champ filtrable ; il n’a pas d’agrégat source, donc WHERE experiment IN [...] est rejeté avec filters on "experiment" are not supported. Le filtre funnel prend en charge la sélection multiple : is one of (IN) inclut uniquement les funnels sélectionnés, is not one of (NOT IN) les exclut. Lorsque vous regroupez par Funnel et appliquez un filtre is one of, le graphique affiche une ligne par funnel sélectionné, sans regroupement « Other ».

Plages de dates et comparaisons

Chaque requête nécessite une plage de dates, définie avec SINCE : Préréglages disponibles : last_1d, last_7d, last_30d, last_90d, this_month, last_month et this_year.
  • GRAIN définit la taille des intervalles pour les séries temporelles : day, week ou month. (hour est accepté syntaxiquement mais aucun agrégat ne fournit de données horaires, une telle requête est donc rejetée avec group_by / time_grain combination is not supported.)
  • COMPARE superpose une seconde période. Utilisez previous_period, la fenêtre de même durée immédiatement antérieure. previous_year est masqué du sélecteur Compare car l’entrepôt de données ne contient aucune donnée antérieure à février 2026 ; il reste saisissable en AQL uniquement pour que les requêtes enregistrées auparavant continuent d’être analysées.
Les données de reporting commencent en février 2026 ; une fenêtre antérieure renvoie donc un résultat vide pour les deux périodes.

Choisir un graphique

  • CHART définit comment le résultat est affiché : scorecard, line_chart, bar_chart, area_chart, funnel_chart ou table.
  • TIMEZONE définit le fuseau horaire utilisé pour regrouper les dates, sous la forme d’un nom IANA entre guillemets, par exemple TIMEZONE "America/New_York". Par défaut, UTC (voir Fuseaux horaires).
Le type funnel_chart a des exigences spécifiques :
  • Mode emplacement. Regroupez par placement et sélectionnez une métrique. Les étapes sont ordonnées selon la séquence canonique des emplacements (upsell par défaut, puis downsell, puis upsells supplémentaires). Seule la première métrique est tracée ; les métriques supplémentaires sont mentionnées dans une note de bas de page.
  • Mode métrique. Sélectionnez deux métriques ou plus sans GROUP BY. Chaque métrique devient une étape du funnel dans l’ordre de la requête (par exemple, SELECT impressions, conversions affiche la déperdition des impressions vers les conversions). Toutes les métriques doivent partager la même unité.
Le mode emplacement nécessite une métrique pouvant être ventilée par emplacement. impressions, accept_rate et rpv ne le peuvent pas ; pour celles-ci, le graphique en funnel affiche « These metrics can’t be grouped by placement ».

Trier et limiter

  • ORDER BY trie les résultats selon une métrique ou une dimension, avec ASC ou DESC.
  • LIMIT plafonne le nombre de lignes renvoyées, utile pour les questions de type « top N ».

Autres exemples

impressions, accept_rate et rpv ne peuvent pas être ventilés par appareil ; leur agrégat est boutique × surface × jour, sans colonne d’appareil. Utilisez revenue (ou une autre métrique issue des conversions) pour les comparaisons par appareil.

Fuseaux horaires

Par défaut, les requêtes s’exécutent en UTC. Vous pouvez remplacer le fuseau horaire afin que les résultats regroupés par date reflètent l’heure locale (consultez Définir un fuseau horaire pour les étapes dans la barre d’outils).
Les requêtes qui incluent Impressions, Accept Rate ou Revenue Per Visit regroupent toujours les dates en UTC, quel que soit le fuseau horaire sélectionné, car ces métriques proviennent d’un agrégat quotidien établi en jours UTC. Si une requête mélange l’une d’elles avec d’autres métriques, l’ensemble des résultats repasse en UTC afin que les intervalles de dates restent alignés.

La clause TIMEZONE

Spécifiez un fuseau horaire directement en AQL avec la clause TIMEZONE, qui se place entre CHART et ORDER BY :
Lorsqu’elle est présente, la clause remplace la sélection de la barre d’outils pour cette requête, et elle est conservée lorsque vous enregistrez et rechargez la requête.

Fuseaux horaires disponibles

Le sélecteur (et la clause TIMEZONE) accepte un ensemble fermé de dix fuseaux. Tout autre fuseau horaire IANA est rejeté comme non pris en charge.

Account default et effet du fuseau horaire sur les résultats

Si Lock reporting timezone est activé dans vos paramètres d’analytics, sélectionner Account default utilise ce fuseau horaire verrouillé (la barre d’outils affiche le fuseau résolu, par exemple Timezone: Account default (Paris (CET))). La page des paramètres d’analytics accepte la liste IANA complète, mais Reports ne prend en compte que les dix fuseaux ci-dessus ; si votre fuseau verrouillé n’en fait pas partie, Account default se résout silencieusement en UTC. Si Lock reporting timezone n’est pas activé, Account default revient à UTC. Lorsqu’un fuseau horaire est défini, le regroupement par date utilise l’heure locale au lieu de l’UTC. Par exemple, un événement à 2026-03-29T01:30:00Z tombe le 28 mars à New York (ET) mais le 29 mars à Paris (CET). Les requêtes sans fuseau horaire, y compris celles enregistrées auparavant, continuent de s’exécuter en UTC.