Mesures par période dans Looker

L'analyse de période à période (PàP) est un type d'analyse qui mesure un élément dans le présent et le compare à la même mesure au cours d'une période comparable dans le passé.

Pour les dialectes compatibles avec les mesures PoP, les développeurs Looker peuvent ajouter des mesures PoP aux projets LookML afin d'activer l'analyse PoP dans les explorations Looker correspondantes.

Par exemple, la requête Looker Explore suivante indique le nombre de commandes créées au cours du mois en cours, ainsi que les mesures de variation en pourcentage pour le nombre de commandes créées l'année dernière, la différence par rapport à l'année dernière et la variation en pourcentage par rapport à l'année dernière. Vous pouvez vérifier la comparaison d'une année sur l'autre en examinant les valeurs. Par exemple, la valeur de Commandes l'année dernière pour 2012-03 est la même que celle de Nombre de commandes pour 2011-03 :

L'explorateur Looker affiche 89 commandes l'année dernière pour mars 2012 et 89 commandes pour mars 2011.

Pour ajouter une mesure PoP à un projet LookML, un développeur Looker doit créer un measure de type: period_over_period et inclure les sous-paramètres décrits dans la section suivante de cette page.

Par exemple, voici le code LookML d'une mesure PoP qui fournit le nombre de commandes pour l'année précédente :

  measure: order_count_last_year {
    type: period_over_period
    description: "Order count from the previous year"
    based_on: orders.count
    based_on_time: orders.created_year
    period: year
    kind: previous
  }

Cette mesure de PdP présente les attributs suivants :

  • Elle est définie avec based_on: orders.count. La mesure de variation en pourcentage fournira donc des données sur le nombre de commandes de la période précédente.
  • Elle est définie sur kind: previous, ce qui signifie qu'elle fournit la valeur du nombre de commandes de la période précédente (au lieu de fournir une différence dans le nombre de commandes par rapport à la période précédente, ou un pourcentage de variation du nombre de commandes par rapport à la période précédente).
  • Elle est définie avec period: year. Elle fournira donc le nombre de commandes sur une période comparable à celle de l'année précédente.

Sous-paramètres des mesures de couverture et fréquence

Une mesure PoP est un measure de type: period_over_period qui inclut les sous-paramètres décrits dans les sections suivantes :

Comme décrit dans la section Explorer les requêtes avec des mesures PoP, les mesures PoP calculent leurs valeurs en fonction de la définition LookML de la mesure PoP et des champs d'une requête Explorer. Pour cette raison, vous devez respecter les bonnes pratiques suivantes lorsque vous créez une mesure de variation en pourcentage dans LookML :

  • Indiquez aux utilisateurs d'Explorer la période de la mesure de variation en pourcentage, soit dans le nom de la mesure, soit dans le sous-paramètre description de la mesure.
  • Indiquez aux utilisateurs d'Explorer la mesure based_on de la mesure PoP, soit dans le nom de la mesure PoP, soit dans le sous-paramètre description de la mesure.

Par exemple, la mesure PoP suivante est nommée order_count_last_year et inclut une description pour indiquer aux utilisateurs qu'elle fournit le nombre de commandes de l'année précédente :

  measure: order_count_last_year {
    type: period_over_period
    description: "Order count from the previous year"
    based_on: orders.count
    based_on_time: orders.created_year
    period: year
    kind: previous
  }

based_on

Utilisez le champ based_on pour spécifier la mesure LookML sur laquelle la mesure de variation en pourcentage est basée. Par exemple, pour baser une mesure de variation en pourcentage sur le champ orders.count, saisissez ce qui suit :

    based_on: orders.count

Une mesure PoP basée sur orders.count fournit des informations sur le nombre de commandes d'une période précédente. Vous pouvez ainsi comparer le nombre de ventes entre une période actuelle et une période précédente.

La mesure LookML que vous spécifiez dans le champ based on doit être l'un des types de mesures suivants :

based_on_time

Utilisez le sous-paramètre based_on_time pour fournir à Looker un champ temporel qu'il pourra utiliser pour calculer les valeurs de mesure de la période précédente. Ce champ temporel peut avoir l'une des valeurs suivantes :

  • Une dimension temporelle. Si vous spécifiez une dimension temporelle dans le sous-paramètre based_on_time, vos utilisateurs doivent inclure exactement la même dimension temporelle dans toutes les requêtes qui utilisent la mesure "Variation en pourcentage". De plus, la période de la dimension temporelle doit être égale ou inférieure à la valeur period de la mesure de variation en pourcentage. Par exemple, si la mesure de variation de période à période est définie avec based_on_time: created_month, la valeur period de la mesure de variation de période à période ne peut pas être week ni date.

  • L'une des périodes suivantes d'un groupe de dimensions type: time :

    • year
    • fiscal_year
    • month
    • fiscal_quarter
    • quarter
    • week
    • date
    • raw

  • L'une des périodes suivantes d'un groupe de dimensions type: custom_calendar

    • custom_date
    • custom_period
    • custom_quarter
    • custom_season
    • custom_week
    • custom_year

Si vous spécifiez une période pour le groupe de dimensions dans le sous-paramètre based_on_time, la période spécifique que vous utilisez n'a pas d'importance. Vous devez simplement pointer la mesure PoP vers un groupe de dimensions de type: time afin que la mesure PoP puisse utiliser le code temporel sous-jacent du groupe de dimensions. Vous ne pouvez pas spécifier de période à partir d'un groupe de dimensions de type: duration. Les groupes de dimensions de type "durée" ne sont pas acceptés et génèrent une erreur d'exécution dans Explorer.

kind

Utilisez le paramètre kind pour spécifier le type de calcul que la mesure de variation en pourcentage doit effectuer pour la période précédente. Vous pouvez spécifier l'une des valeurs suivantes pour kind :

  • previous : (par défaut) valeur de la période précédente.
  • difference : différence entre les périodes (la période précédente est soustraite de la période actuelle).

  • relative_change : variation en pourcentage par rapport à la période précédente. La variation en pourcentage est calculée à l'aide de l'équation suivante :

    $$ relativeChange = (current - previous)/previous $$

period

Utilisez le sous-paramètre period pour spécifier la cadence de la mesure de PdP, c'est-à-dire le nombre de périodes à remonter dans votre comparaison. Par exemple, une mesure de variation en pourcentage définie avec period: year affichera les valeurs de l'année précédente. Si vous exécutez une requête Explorer sur le nombre de commandes mensuel, la mesure period: year (variation en pourcentage) affichera les valeurs du même mois de l'année précédente. Vous pourrez ainsi comparer le nombre de commandes de novembre 2025 à celui de novembre 2024.

Le sous-paramètre period accepte les valeurs suivantes :

  • year
  • fiscal_year
  • quarter
  • fiscal_quarter
  • month
  • week
  • date

custom_calendar_period

Si votre mesure de variation en pourcentage est basée sur un calendrier personnalisé (si le paramètre based_on_time de la mesure de variation en pourcentage spécifie une période d'un groupe de dimensions de type: custom_calendar), vous devez utiliser le paramètre custom_calendar_period au lieu du paramètre period.

Utilisez le sous-paramètre custom_calendar_period pour spécifier la cadence de la mesure de PdP, c'est-à-dire le nombre de périodes à remonter dans votre comparaison. Par exemple, une mesure PoP définie avec custom_calendar_period: custom_year affichera les valeurs de l'année précédente (telle qu'elle est définie dans votre calendrier personnalisé). Si vous exécutez une requête Explorer sur le nombre de commandes mensuel personnalisé, la mesure custom_calendar_period: custom_year PoP affichera les valeurs du même mois de l'année précédente. Vous pourrez ainsi comparer le nombre de commandes du mois personnalisé en 2026 au nombre de ventes du même mois personnalisé en 2025.

Le sous-paramètre custom_calendar_period accepte les valeurs suivantes :

  • custom_date
  • custom_period
  • custom_quarter
  • custom_season
  • custom_week
  • custom_year

Pour savoir comment créer des mesures PoP qui utilisent un calendrier personnalisé, consultez la section Utiliser des mesures PoP avec des calendriers personnalisés.

value_to_date

Utilisez le sous-paramètre value_to_date pour indiquer si Looker doit calculer les valeurs de la mesure "Variation en pourcentage" en utilisant le temps écoulé dans la période actuelle au moment de l'exécution de la requête. Le sous-paramètre value_to_date peut être no (par défaut) ou yes.

  • Une valeur de no suppose que l'intégralité de la période est utilisée lors de l'agrégation des données.
  • Une valeur de yes calcule la durée observée au cours de la période actuelle et l'applique à la mesure de variation en pourcentage.

Par exemple, avec une mesure de variation en pourcentage d'une période à l'autre définie avec value_to_date: yes, si vous exécutez une requête Explorer à 13h10 le 6 juin avec la mesure de variation en pourcentage et une dimension de période, Looker appliquera le temps écoulé le 6 juin (13 heures, 10 minutes et 0 seconde) aux calculs pour chacune des dates de la requête. Pour chaque date, Looker fournira les valeurs des 13 premières heures et 10 minutes.

Si vous aviez la même mesure PoP définie avec value_to_date: no et que vous exécutiez la même requête Explorer le 6 juin à 13:10:00, Looker calculerait la valeur du PoP en utilisant toutes les données disponibles pour chaque date. Si vous essayez de comparer les valeurs du 6 juin à celles du 6 du mois précédent, sachez que le 6 juin n'est pas encore terminé et qu'il est possible que des données supplémentaires soient disponibles après 13h10.

Consultez Comment value_to_date affecte les valeurs de la mesure "Période par rapport à la période précédente" pour obtenir un exemple de l'impact de value_to_date: yes sur les résultats d'une requête Explorer.

Comme décrit dans la section Exigences pour les requêtes Explorer avec des mesures PoP, lorsque vous exécutez une requête Explorer avec une mesure PoP, Looker applique automatiquement la granularité de période minimale de la requête à la période utilisée par la mesure PoP. Pour les requêtes Explorer avec une mesure PoP définie avec value_to_date: yes, Looker prend la dimension de période la plus petite de la requête et calcule la partie de cette période qui s'est écoulée lorsque la requête est exécutée. Il applique ensuite cette partie à toutes les valeurs de la mesure PoP.

Explorer les requêtes avec des mesures de part de portefeuille

Le calcul effectué pour une mesure PoP est basé sur la définition LookML de la mesure PoP, ainsi que sur les périodes spécifiées dans la requête Explorer elle-même. La mesure PoP adapte son calcul aux périodes sélectionnées dans la requête Explorer. Par exemple, si la mesure de variation en pourcentage est définie avec period: year et que la requête Explorer contient la dimension de période orders.created_month, la mesure de variation en pourcentage calculera les valeurs mensuelles en comparant janvier 2025 à janvier 2024. Si vous souhaitez afficher les valeurs annuelles, vous devrez exécuter une requête Explorer avec la mesure "Variation en pourcentage" et uniquement la période orders.created_year.

Voici quelques exemples de la façon dont la mesure period de probabilité d'achat interagit avec les périodes sélectionnées dans une requête Explorer :

  • Si une mesure PoP est définie avec period: year et que vous exécutez une requête Explorer avec un intervalle trimestriel, la mesure PoP renverra les valeurs du même trimestre de l'année précédente (T1 2025 par rapport à T1 2024).
  • Si une mesure PoP est définie avec period: year et que vous exécutez une requête Explorer avec un intervalle de temps mensuel, la mesure PoP renverra les valeurs du même mois de l'année précédente (avril 2025 par rapport à avril 2024).
  • Si une mesure PoP est définie avec period: month et que vous exécutez une requête Explorer avec un intervalle mensuel, la mesure PoP renvoie les valeurs du mois précédent (avril 2025 par rapport à mars 2025).

Conditions requises pour les requêtes Explorer avec des mesures de période par période

Étant donné qu'une mesure de variation en pourcentage effectue des calculs basés à la fois sur la définition LookML de la mesure de variation en pourcentage et sur les champs que vous sélectionnez dans la requête d'exploration, vous devez au minimum inclure les champs suivants dans une requête d'exploration comportant une mesure de variation en pourcentage :

  • Mesure de la probabilité d'achat.
  • Dimension temporelle adaptée à la period associée à la mesure de variation en pourcentage. La dimension temporelle peut être incluse dans la requête à partir du sélecteur de champ de l'exploration ou dans les filtres de l'exploration :
    • Les requêtes de mesure PoP prennent en charge des granularités temporelles de la date ou plus grandes, telles que le mois, le trimestre ou l'année. Les requêtes de mesure PoP ne prennent pas en charge les dimensions avec des intervalles de temps en heures ou en minutes.
    • Si la mesure PoP est définie avec un based_on_time qui est une période d'un groupe de dimensions, alors la requête Explore doit inclure une période du même groupe de dimensions qui utilise une période égale ou inférieure à celle spécifiée dans le paramètre period de la mesure PoP. Vous pouvez inclure le groupe de dimensions dans l'Exploration elle-même (en sélectionnant le groupe de dimensions dans le sélecteur de champs de l'Exploration) ou en filtrant sur le groupe de dimensions. Par exemple, si la valeur based_on_time de la mesure PoP est définie avec une période du groupe de dimensions orders.created et que la mesure PoP est définie avec period: month, la requête Explore doit inclure une période du groupe de dimensions orders.created égale ou inférieure à un mois, telle que orders.created_date. La période de référence dans la requête Explore doit être égale ou inférieure à la période de référence car, par exemple, vous ne pouvez pas effectuer une comparaison mensuelle sur une période d'un an.
    • Si la mesure PoP est définie avec un based_on_time qui est une dimension temporelle , alors la requête Explore doit inclure exactement la même dimension temporelle, soit en incluant la dimension à partir du sélecteur de champs d'Explore, soit en spécifiant un filtre sur la dimension. La dimension temporelle doit être d'une période égale ou inférieure à celle spécifiée dans le paramètre period de la mesure PoP. Par exemple, si la mesure PoP est définie avec based_on_time: created_date et la mesure PoP est définie avec period: month, la requête Explore doit inclure la dimension created_date.

Si la mesure PoP est définie avec un based_on_time qui correspond à une période d'un groupe de dimensions, veuillez noter les exigences suivantes concernant la période dans la requête Explore :

  • La période de temps dans la requête Explore doit être égale ou inférieure à celle spécifiée dans le paramètre period de la mesure PoP. Par exemple, si la mesure PoP based_on_time est définie avec une période du groupe de dimensions orders.created et que la mesure PoP est définie avec period: month, la requête Explore doit inclure une période du groupe de dimensions orders.created égale ou inférieure à un mois, telle que orders.created_date. La période de référence dans la requête Explore doit être plus courte car, par exemple, il est impossible de comparer des mois sur une période d'un an.
  • La plage de temps dans la requête Explore doit elle-même contenir des informations d'horodatage. Par exemple, les intervalles de temps year, month et date d'un groupe de dimensions fournissent des informations d'horodatage réelles. En revanche, la période day_of_week est extraite de l'horodatage sous-jacent pour fournir une valeur telle que Wednesday. De même, les intervalles de temps tels que month_name, month_num et day_of_month ne fournissent pas eux-mêmes d'informations d'horodatage, ils ne peuvent donc pas être utilisés par les mesures PoP pour calculer les valeurs de la période précédente. Toutefois, si vous incluez dans la requête Explore un horodatage tel que date, cela fournira à la mesure PoP des informations d'horodatage qu'elle pourra utiliser pour calculer les valeurs de la période précédente. Vous pouvez également inclure la période day_of_week dans la requête Explore, car la mesure PoP peut utiliser les informations de la période date pour les calculs.

Tant que vous respectez ces exigences dans votre requête Explore, vous pouvez ajouter d'autres champs et dimensions de période dans la requête Explore, mais toutes les périodes de la requête Explore doivent être égales ou inférieures à la période de la mesure PoP period. Lorsque vous exécutez une requête Explore avec une mesure PoP, Looker applique automatiquement la granularité temporelle minimale de la requête à la période utilisée par la mesure PoP. Dans l'exemple Explore présenté au début de cette page, les mesures PoP ont toutes été définies en LookML avec period: year. Cela signifie que, quelle que soit la période sélectionnée dans la requête Explore (dans ce cas, une période mensuelle), la mesure PoP renverra les résultats pour la même période de l'année précédente.

Si vous souhaitez voir quelles périodes sont prises en charge par votre mesure PoP dans une fenêtre Explore, vous pouvez tester différentes périodes sans avoir à exécuter de requêtes. Cliquez sur l'onglet SQL de la section Data de l'Explore, puis ajoutez des champs et des filtres à partir du sélecteur de champs de l'Explore. Si la mesure PoP ne peut pas calculer votre requête avec les champs et filtres sélectionnés, l'onglet SQL affichera un message indiquant que le SQL ne peut pas être généré.

Si vous exécutez une requête pour laquelle le code SQL ne peut pas être généré, la fenêtre Explorer renverra une erreur contenant les détails et un lien vers le LookML correspondant.

Utilisation des mesures PoP avec des calendriers personnalisés

Pour créer une mesure PoP qui utilise un calendrier personnalisé , vous devez procéder comme suit :

  • Dans le fichier de vue où vous modélisez votre calendrier personnalisé, incluez éventuellement un bloc de paramètres previous_ordinal_mapping dans votre bloc de paramètres calendar_definition. Le paramètre previous_ordinal_mapping est facultatif à partir de Looker 26.8. Dans Looker 26.8 et versions ultérieures, Looker suppose pour les calendriers personnalisés que la semaine précédente pour la semaine 1 est la semaine 52 et le jour précédent pour le jour 1 est le jour 364. Si ce n'est pas le cas pour votre calendrier personnalisé, vous devez utiliser le bloc de paramètres previous_ordinal_mapping.
  • Dans la définition LookML de la mesure PoP, dans le paramètre based_on_time, spécifiez la période annuelle d'un groupe de dimensions de type: custom_calendar
  • Dans la définition LookML de la mesure PoP, utilisez le paramètre custom_calendar_period au lieu du paramètre period.

Voici par exemple le LookML pour un groupe de dimensions de calendrier personnalisé et une mesure PoP qui utilise ce calendrier personnalisé :

dimension_group: cust_created {
    type: custom_calendar
    sql: {TABLE}.created_at;;
    based_on_calendar: cust_retail_calendar
    custom_timeframes: [custom_year, custom_quarter]

  }

measure: count_last_custom_year {
    type: period_over_period
    based_on: count
    based_on_time: cust_created_custom_year
    custom_calendar_period: custom_year
    kind: previous
  }

Exemples

Les sections suivantes présentent quelques exemples de différentes mesures PoP et de requêtes Explore :

Comparaison des effectifs avec les mesures PoP d'une année sur l'autre et d'un mois sur l'autre

Voici le LookML pour un exemple de mesure total_births, un groupe de dimensions birth de type:time et deux mesures PoP basées sur la mesure total_births et qui utilisent le groupe de dimensions birth comme champ based_on_time :


  dimension_group: birth {
    type: time
    timeframes: [raw, time, date, week, month, quarter, year]
    sql: ${TABLE}.birth_date ;;
  }

  measure: total_births {
    type: sum
    sql: ${TABLE}.total_births ;;
  }

  measure: total_births_last_year {
    type: period_over_period
    kind: previous
    based_on: total_births
    based_on_time: birth_year
    period: year
    value_to_date: no
    value_format_name: decimal_0
  }

  measure: total_births_last_month {
    type: period_over_period
    kind: previous
    based_on: total_births
    based_on_time: birth_year
    period: month
    value_to_date: no
    value_format_name: decimal_0
  }

Veuillez noter les points suivants concernant ces champs :

  • Les deux mesures PoP sont définies avec kind: previous, elles fournissent donc toutes deux la valeur de la mesure de la période précédente.
  • Les deux mesures PoP sont définies avec value_to_date: no, elles calculent donc toutes deux la valeur de la mesure pour l'ensemble de la période (c'est-à-dire la granularité de période minimale de la requête).
  • Les deux mesures PoP sont définies avec based_on_time: birth_year, elles utilisent donc toutes deux l'horodatage sous-jacent du groupe de dimensions birth.
  • La mesure PoP total_births_last_year est définie avec period: year, et la mesure PoP total_births_last_month est définie avec period: month.

Voici une requête Explore qui inclut les trois mesures et la dimension temporelle birth_month :

L'outil Explorer de Looker affiche les colonnes "Mois de naissance", "Nombre total de naissances", "Nombre total de naissances le mois dernier" et "Nombre total de naissances l'année dernière". La valeur "Total des naissances le mois dernier" pour 2024-07 est de 290 699, ce qui correspond à la valeur "Total des naissances" pour 2024-06. La valeur "Total des naissances l'année dernière" pour 2024-07 est de 310 347, ce qui correspond à la valeur "Total des naissances" pour 2023-07.

Remarques concernant les résultats de l'onglet "Explorer" :

  • La période la plus courte de la dimension dans la requête Explorer est birth_month. La mesure de variation en pourcentage fournit donc des valeurs mensuelles.
  • Dans la ligne du mois le plus récent, 2024-07, la valeur Total des naissances le mois dernier indique le nombre total de naissances pour le mois précédent, 2024-06. Pour le vérifier, consultez la valeur Total des naissances de la ligne 2024-06. Les deux valeurs correspondent.
  • Dans la ligne du mois le plus récent, 2024-07, la valeur Total des naissances l'année dernière indique le nombre total de naissances pour le même mois (07) de l'année précédente (2023). Pour le vérifier, consultez la valeur Total des naissances pour la ligne 2023-07. Les deux valeurs correspondent.

Incidence de value_to_date sur les valeurs de mesure de la période après période

Comme dans l'exemple précédent, voici le LookML pour la mesure total_births et le groupe de dimensions birth de type:time, ainsi que deux mesures de variation en pourcentage basées sur la mesure total_births et qui utilisent le groupe de dimensions birth comme champ based_on_time. Toutefois, dans cet exemple, la mesure de variation en pourcentage total_births_last_year_value_to_date est définie avec value_to_date: yes et la mesure de variation en pourcentage total_births_last_year est définie avec value_to_date: no :

  dimension_group: birth {
    type: time
    timeframes: [raw, time, date, week, month, quarter, year]
    sql: ${TABLE}.birth_date ;;
  }

  measure: total_births {
    type: sum
    sql: ${TABLE}.total_births ;;
  }

  measure: total_births_last_year {
    type: period_over_period
    kind: previous
    based_on: total_births
    based_on_time: birth_year
    period: year
    value_to_date: no
    value_format_name: decimal_0
  }

  measure: total_births_last_year_value_to_date {
    type: period_over_period
    kind: previous
    based_on: total_births
    based_on_time: birth_year
    value_to_date: yes
    period: year
    value_format_name: decimal_0
  }

Voici une requête Explorer qui inclut les trois mesures et la période de la dimension birth_year. Cette requête Explorer a été exécutée le 4 juin à 16:25:08, ce qui est important pour la mesure value_to_date: yes du PdP.

Exploration Looker affichant les colonnes "Année de naissance", "Nombre total de naissances", "Nombre total de naissances l'année dernière" et "Valeur du nombre total de naissances l'année dernière depuis le début de l'année". La valeur "Total des naissances l'année dernière" pour 2024 est de 3 581 036, ce qui correspond à la valeur "Total des naissances" pour 2023. La valeur "Naissances depuis le début de l'année dernière" pour 2024 est de 1 743 505.

Les résultats de l'exploration montrent comment le sous-paramètre value_to_date modifie le calcul des mesures de variation en pourcentage :

Remarques concernant les résultats de l'onglet "Explorer" :

  • Dans la ligne correspondant à l'année la plus récente, 2024, la valeur Naissances totales l'année dernière indique le nombre total de naissances pour l'année précédente, 2023. Vous pouvez vérifier le calcul en regardant la valeur Total Births pour la ligne 2023. Les deux valeurs correspondent.
  • Dans la ligne de l'année la plus récente, 2024, la valeur Total Births Last Year Value to Date est inférieure à la valeur Total Births Last Year. Ceci est dû au fait que la requête Explore a été exécutée le 4 juin à 16:25:08, et parce que la mesure PoP total_births_last_year_value_to_date est définie avec value_to_date: yes, Looker a donc calculé les valeurs annuelles en utilisant uniquement les données jusqu'au 4 juin à 16:25:08 pour chaque année.

Filtrer les requêtes Explore qui incluent des mesures PoP

Veuillez noter ce qui suit concernant le filtrage des requêtes Explore incluant des mesures PoP :

  • Le filtrage est pris en charge pour les requêtes Explore incluant des mesures PoP. Cependant, il n'est pas possible de filtrer directement sur une mesure PoP. Par exemple, dans le premier exemple Explorez ces requêtes sur la dimension birth_month et les mesures PoP total_births, total_births_last_year et total_births_last_month, vous ne pourriez pas filtrer cette requête sur les mesures PoP total_births, total_births_last_year ou total_births_last_month.
  • Lorsque vous filtrez sur un champ associé au paramètre based_on_time d'une mesure PoP, si la période du filtre est plus fine que la période de la requête, la mesure PoP n'affichera que les résultats pour la partie de la période de la requête correspondant à la valeur du filtre. Par exemple, si vous effectuez une requête sur la dimension orders.created_year et que vous filtrez la requête pour le mois de janvier, pour chaque année, la mesure PoP affichera uniquement les valeurs de janvier. On pourrait confondre ces résultats avec ceux de l'année entière.
  • Pour les requêtes Explore de mesure PoP, afin de calculer les données de la mesure PoP, Looker récupère les données pour une période supplémentaire à la granularité de période la plus fine de la requête. Par exemple, si vous créez une requête Explore avec une dimension mensuelle, une mesure PoP définie avec period: year et un filtre pour les 6 derniers mois, Looker identifiera la granularité la moins fine dans la requête, qui dans cet exemple serait la période year de la mesure PoP. Dans cet exemple, Looker récupérerait les données des 6 derniers mois, ainsi que les données d'une année supplémentaire, afin de pouvoir comparer chacun des 6 derniers mois au même mois de l'année précédente.
  • Comme décrit dans Exigences pour les requêtes Explore avec des mesures PoP, les requêtes Explore qui incluent des mesures PoP doivent avoir une dimension temporelle appropriée pour le period qui est associé à la mesure PoP. Si vous ne sélectionnez pas de dimension temporelle dans le sélecteur de champs de l'Explorateur, Looker peut déduire les informations requises à partir des dimensions temporelles des filtres de l'Explorateur. Dans ce cas, Looker triera les résultats de la requête Explore selon la dimension temporelle du filtre.

Visualisations avec mesures PoP

La visualisation graphique du tableau est recommandée pour les mesures PoP. D'autres options de visualisation peuvent également fonctionner, en fonction des champs de votre requête Explore.

Si vous utilisez une visualisation autre qu'un tableau, vérifiez qu'elle est claire. Étant donné que les mesures de variation en pourcentage fournissent des comparaisons avec une période précédente, les visualisations avec des mesures de variation en pourcentage peuvent être trompeuses. Par exemple, une mesure de variation en pourcentage d'une année sur l'autre définie sur kind: previous affichera la valeur de l'année dernière pour la date de cette année. Si votre requête Explore inclut la valeur de l'année en cours ainsi que la mesure de variation en pourcentage d'une année sur l'autre, l'année en cours aura deux valeurs dans la visualisation.

Si vous utilisez une visualisation autre qu'un tableau, vérifiez qu'elle indique clairement que les mesures de période sur période sont des comparaisons avec une période précédente.

Limites des mesures de couverture et de fréquence

Notez les limites suivantes des mesures de couverture et de fréquence :

  • Les mesures de période par période ne sont compatibles qu'avec les projets LookML qui utilisent le nouveau runtime LookML. Si l'ancienne fonctionnalité Utiliser l'ancien environnement d'exécution LookML est activée sur votre instance, le fichier manifeste de votre projet doit inclure une instruction new_lookml_runtime:yes.
  • Les mesures PoP ne sont pas compatibles avec le connecteur Looker dans Data Studio.
  • Les mesures de couverture et de fréquence doivent être basées sur une mesure agrégée, comme décrit dans la section based_on. Vous ne pouvez pas baser une mesure de PdP sur une mesure non agrégée.
  • Pour les connexions BigQuery sur les instances où la fonctionnalité expérimentale Agrégats symétriques BI Engine est activée, les mesures PoP sont acceptées, mais les requêtes SQL avec des mesures PoP n'utiliseront pas la fonctionnalité Agrégats symétriques BI Engine.
  • Les mesures de variation de période à période ne sont pas compatibles avec l'analyse de cohortes.
  • Les mesures PoP ne sont pas compatibles avec les calculs cumulés.
  • Les mesures de période sur période comparent toujours la période actuelle à la période précédente. Vous ne pouvez pas configurer une mesure PoP pour comparer la période actuelle à une période autre que la précédente. Par exemple, vous ne pouvez pas créer de mesure PoP pour comparer le mois de mai de l'année dernière à celui de décembre de cette année.
  • Les mesures de période sur période ne sont pas compatibles avec les intervalles arbitraires, comme les deux semaines actuelles par rapport aux deux semaines précédentes.
  • Les paramètres Liquid ne sont pas acceptés dans les paramètres d'une mesure PoP. Toutefois, si les champs based_on ou based_on_time d'un point de mesure de la période par rapport à la période précédente pointent vers une dimension définie avec Liquid, ce code Liquid sera traité.

  • Pour les mesures de période par période qui utilisent des calendriers personnalisés :

    • (Avant Looker 26.8) Le paramètre based_on_time doit faire référence à la période custom_year d'un groupe de dimensions type: custom_calendar.
    • (Avant Looker 26.8) Pour les mesures PoP définies avec custom_calendar_period: custom_year, si la requête utilisateur contient custom_week ou custom_date, Looker fournit la valeur de la semaine précédente ou de la date de l'année précédente.

  • Les mesures de période sur période ne sont pas compatibles avec les fonctionnalités Looker suivantes :

  • Vous ne pouvez pas utiliser les mesures de probabilité d'achat pour créer un champ personnalisé.

  • Pour les comparaisons hebdomadaires, nous vous recommandons de créer une mesure PoP qui utilise un calendrier personnalisé.

  • Les mesures de période sur période définies avec des périodes fiscales ne peuvent pas être utilisées dans des requêtes d'exploration avec des périodes non fiscales. De plus, les mesures de période sur période avec des périodes définies avec des périodes non fiscales ne peuvent pas être utilisées dans les requêtes avec des dimensions de période fiscale.

  • Les mesures PoP sont compatibles avec le décalage du mois fiscal. En effet, le paramètre based_on_time de la mesure PoP hérite de la valeur fiscal_month_offset du fichier de modèle LookML associé à l'exploration. Si vous définissez une mesure PoP avec fiscal_year ou fiscal_quarter, elle ne sera acceptée dans une requête Explorer que si celle-ci spécifie une période fiscal_year ou fiscal_quarter. Dans ce cas, la valeur fiscal_offset_month est respectée.

  • Le period de la mesure "période par période" doit être égal ou supérieur à la période sélectionnée dans la requête d'exploration. Par exemple, pour une mesure PoP définie avec period: month, la requête Explorer doit avoir une dimension de période d'un mois ou moins, comme une semaine ou un jour.

  • Lorsque vous utilisez des mesures de variation en pourcentage, incluez toujours la dimension de période correspondante dans l'exploration, en plus de la dimension date_time. Par exemple, si vous définissez une mesure de variation en pourcentage pour calculer les valeurs du mois correspondant du trimestre précédent, vous devez inclure la dimension du trimestre correspondant (par exemple, [dimension_name]_quarter) dans l'exploration, en plus de la dimension du mois. Sans la dimension de période correspondante, le code SQL généré applique une fonction de troncature (telle que TIMESTAMP_TRUNC(..., QUARTER)) à la date avant de calculer la période précédente, ce qui fait que la requête est évaluée en fonction du début du trimestre.

    Par exemple, dans une comparaison pour février, le code SQL généré récupère la valeur du premier mois du trimestre précédent (octobre) au lieu du mois correspondant (novembre). L'inclusion de la dimension de période correspondante dans l'exploration garantit une génération et un regroupement SQL appropriés.

Dialectes de base de données pris en charge pour les mesures PoP

Le tableau suivant indique les dialectes qui prennent en charge les mesures de période sur période dans la dernière version de Looker :

Dialecte Compatibilité
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica