Comment créer un sélecteur de période de comparaison sur Looker Studio en utilisant BigQuery ?

Avant de commencer, voici 2 formations gratuites en rapport avec la question traitée qui devraient vous donner les informations nécessaires pour bien comprendre la réponse à cette question :

Formation sur Google Big Query (2023)

Formation sur Looker Studio (2023)

Allez, c’est parti ! 🤓

Un sélecteur de période de comparaison permet de faire varier la période de comparaison d’un ou plusieurs graphiques sur un rapport en fonction de la plage de dates sélectionnée sur ce dernier.

Voici les périodes de comparaison les plus souvent utilisées :

• Période précédente ;
• Même période l’année précédente ;
• Même période le mois précédent ;
• Même période la semaine précédente.

Ainsi, si la plage de dates sélectionnée est “du 2023-08-07 au 2023-08-10”, alors :

• Période précédente = “du 2023-08-03 au 2023-08-06” ;
• Même période l’année précédente = “du 2022-08-07 au 2022-08-10” ;
• Même période le mois précédent = “du 2023-07-07 au 2023-07-10” ;
• Même période la semaine précédente = “du 2023-07-31 au 2023-08-06”.

À date (août 2023), il n’existe pas de fonctionnalité simple et native permettant à un utilisateur de faire varier la période de comparaison d’un ou plusieurs graphiques sur un rapport Looker Studio en mode “lecteur”.

En effet, une seule période de comparaison parmi plusieurs peut être sélectionnée par graphique en mode “éditeur” et très souvent l’utilisateur d’un rapport n’a pas la main dessus, car il n’a pas les droits “éditeur”.

Ce manque de flexibilité est assez problématique, car les analyses comparatives temporelles sont fondamentales dans la prise de décision basée sur les données.

Pour contrer ce manque, très souvent, les éditeurs multiplient les graphiques du rapport en faisant varier les périodes de comparaison.

Cette solution induit souvent une augmentation du nombre d’informations par page du rapport et/ou du nombre de pages du rapport, ce qui se traduit par une baisse de l’expérience utilisateur et par conséquent une augmentation du temps de lecture pour tirer profit du rapport. Dans le pire des cas, une mauvaise expérience utilisateur peut carrément mener à une non-utilisation du rapport.

Mais il existe une solution !! 🤓

Cette solution est principalement rendue possible grâce :

• Aux customs querys (connecteur BigQuery) ;
• Aux paramètres.

Les customs querys font référence à une option de connexion du connecteur BigQuery. Cette option de connexion permet de créer une source de données alimentée par une requête SQL pouvant récupérer et consolider des données depuis plusieurs tables BigQuery. L’option de connexion classique du connecteur BigQuery permet uniquement la connexion à une table.

Voici le lien de la documentation :

https://support.google.com/looker-studio/answer/6370296?hl=en&ref_topic=10587734&sjid=18178109581856647950-EU#zippy=%2Cin-this-article

Les paramètres permettent de transmettre des informations fournies par l’utilisateur à des connecteurs (customs querys BigQuery par exemple) ou bien à des champs calculés. Ainsi, les paramètres permettent de créer des rapports plus réactifs, personnalisables et interactifs.

Voici le lien de la documentation :

https://support.google.com/looker-studio/answer/9002005?hl=FR#zippy=%2Cau-sommaire-de-cet-article

La combinaison des paramètres et des customs querys permet de requêter sur plusieurs tables BigQuery de façon dynamique en fonction de certains paramètres ajustés par l’utilisateur.

Voici le lien de la documentation :

https://support.google.com/looker-studio/answer/10588439?hl=en&ref_topic=10587734&sjid=14249646789956575294-EU

Cette pratique est très puissante et permet de passer au-delà d’un grand nombre de limites.

Cependant, cette pratique compte 3 principaux inconvénients :

• Elle nécessite des compétences techniques (SQL) ;
• Si trop utilisée, elle peut ralentir un rapport ;
• Si trop utilisée, elle peut vraiment complexifier la maintenance d’un rapport.

C’est donc une solution technique à utiliser avec modération uniquement dans les cas à réelle valeur ajoutée.

Afin que vous compreniez mieux, nous avons créé un Looker Studio avec un exemple concret.

Cet exemple n’est pas “directement actionnable”, l’idée est de vous montrer ce qu’il est possible de faire afin de nourrir votre inspiration 🙂

Dans cet exemple, nous avons créé un sélecteur de période de comparaison qui fait varier la période de comparaison d’un scorecard.

Pour ce faire nous avons utilisé:

• Un paramètre “Période de comparaison” pouvant prendre 4 valeurs (”Période précédente”, “Même période l’année précédente”, “Même période le mois précédent”, “Même période la semaine précédente”) ;
• Un sélecteur de dates ;
• Une custom query qui requête sur une table BigQuery à deux colonnes (date, sessions) ;
• La combinaison d’un scorecard, d’un tableau et d’une zone de texte afin de créer un scorecard custom qui répond à nos besoins.

Voici le lien du Looker Studio à dupliquer pour comprendre la configuration sur l’outil ainsi que la requête SQL injectée dans la custom query :

Lien du Looker Studio :

https://lookerstudio.google.com/reporting/c920ebac-8240-4751-add5-7b7b714a119b/page/p_gkk39agk8c

La Requête SQL :

https://drive.google.com/file/d/1vzyU_imLDH5NCSNocfMBWTOFY52ldsRx/view?usp=sharing

Cette requête SQL fonctionne pour :

• Un type de graphique (scorecard) ;
• Un KPI (session) ;
• Une dimension (date) ;
• 4 périodes de comparaison (”Période précédente”, “Même période l’année précédente”, “Même période le mois précédent”, “Même période la semaine précédente”).

Mais nous pourrions l’adapter pour :

• Un autre type de graphique ;
• Plusieurs KPI ;
• Plusieurs dimensions ;
• D’autres périodes de comparaison.

Avec un peu d’imagination, il est possible de faire beaucoup de choses ! 🙂