Power BI : Créer des Filtres de Date Intelligents avec Comparaisons Customisées et Pré-Configurées

Image without caption
Icon
Dans ce tutoriel je vous montre pas-à-pas comment mettre en place dans vos tableaux de board Power BI une sélection de dates aux petits oignons 🧅
Toutes les options s’offrent aux utilisateurs :
  • Des configurations dynamiques comme MTD
  • Des configuration statiques comme Vague 1 (avec date de début et de fin fixes)
  • Des configuration personnalisées grâce à l’option Custom + la sélection de la plage de date
Ce genre de demande pour les sélections de dates ultra flexibles, c’est quelque chose qui revient en permanence lorsque l’on créé des dashboards (peu importe l’outil). D’ailleurs c’est des choses que j’ai l’habitude de faire sur Tableau. 💡
Quand j’ai voulu répliquer le même système sur Power BI, je me suis heurtée à quelques difficultés : avoir toutes les options au même endroit, eh bah, c’était pas si facile ! ⛰️
Mais à force de tests, j’ai mis au point une méthode qui fonctionne et que j’aimerai bien simplifier dans le futur ! 🚀
Pour vous faciliter la vie, je vais passer en revue dans ce tutoriel toutes les étapes pour construire ce sélecteur de A à Z.
S’il y a des points que vous voulez sauter, n’hésitez pas à utiliser cette table des matières ⬇️

1. Les tables à créer

1.1. La création des tables

A. Les calendriers

Pour ceux qui ont déjà joué avec les dates dans Power BI, vous savez déjà qu’il faut créer une table de calendrier pour que tout ce petit monde fonctionne correctement, pour les autres c’est très simple :
On va dans l’onglet Accueil > Nouvelle Table > et on entre cette mesure ⬇️
sql
Calendar = CALENDAR( MIN('Table'[date]), MAX('Table'[date]) )
Ça donnera tous les jours (donc sans trou, même si vous en avez dans la table de base) entre la date min et max.
  • 'Table'[date] est le champ de date de la table où il y a vos mesures. S’il vous avez plusieurs tables avec des mesures, prenez le champ de date dans la table où il est le plus étendu.
🧚‍♀️ La dernière étape pour parfaire cette étape est de marquer notre table Calendar en tant que table de date (on peut faire ça dans le modèle > … > Marquer comme table de dates
Icon
À quoi ça sert ?
C’est un filet de sécurité dans le cas où les colonnes de dates ne sont pas de type date mais integer pour éviter d’ajouter des REMOVEFILTERS() partout (car Power BI le fait implicitement quand une relation est basée sur des dates).
Image without caption
La table Calendar sera utilisée en tant que table date principale. Mais on aura aussi besoin d’une table de date secondaire (Accueil > Nouvelle Table) :
sql
Calendar Comparison = 'Calendar'
Calendar Comparison est un replica de Calendar

B. Les périodes

Maintenant que nous avons nos deux calendriers, il nous faut des tables avec nos différentes options de sélection de période :
Pour la période principale
  • Configurations dynamiques
    • MTD
      QTD
      YTD
      Last Month
      Last Quarter
      Last Year
      All Time
  • Configuration statique
    • Vague 1
  • Configuration personnalisée
    • Custom
Pour la période de comparaison
  • Previous Period
Icon
Qui doit, quand des configurations dynamiques sont sélectionnées dans la période principale, prendre la valeur de Previous MTD (par exemple) et pas simplement le même nombre de jours juste avant.
  • Same Period Last Year
  • Custom
Icon
Je vous propose toutes ces options mais bien évidemment, ne gardez que celles qui sont pertinentes à votre use case.
Pour la période principale, on utilise les formules de time intelligence proposées directement par Power BI (je les ai détaillées dans les toggles plus haut).
Avec ça, on créé une nouvelle table (Accueil > Nouvelle Table) qui décrit toutes nos périodes :
Date Period
Pour la période de comparaison, on n’utilise pas les formules de time intelligence parce que les options doivent être capables de s’adapter à la sélection de la période principale. On créé donc une table toute simple :
Date Period Comparison

1.2. Les relations entre les tables

C’est la où la première étape se joue vraiment !
Il faut bien configurer les relations entre nos tables

A. Calendar <> Table de métriques

Image without caption
Entre Date et measured_at (le champ de date de ma table de métriques) il faut une relation 1:* à sens unique (de Calendar à Table de métriques). Chaque ligne de la table de métriques se relie à une seule ligne du calendrier, mais chaque ligne du calendrier peut être utilisée plusieurs fois.
Laissez cette relation active ⬇️
Image without caption
Icon
Les relations actives filtrent directement les autres tables sans action supplémentaire de notre part tandis que les relations inactives ont besoin d’une précision dans une expression DAX (USERELATIONSHIP()) pour filtrer quelque chose.

B. Calendar Comparison <> Table de métriques

Image without caption
Entre Date et measured_at (le champ de date de ma table de métriques) il faut une relation 1:* à sens unique (de Calendar Comparison à Table de métriques). Chaque ligne de la table de métriques se relie à une seule ligne du calendrier de comparaison, mais chaque ligne du calendrier de comparaison peut être utilisée plusieurs fois.
Rendre la relation inactive ⬇️
Image without caption

C. Calendar <> Date Period

Image without caption
Entre Date et Date il faut une relation 1:* à double sens (de Calendar à Date Period)
Image without caption

D. Modèle global

Et voilà ! 🎉 Notre modèle est fin prêt ! Passons à la mise en place du visuel.
Note : Il n’y a pas de relation entre Date Period Comparison et d’autres tables.
Note : Il n’y a pas de relation entre Date Period Comparison et d’autres tables.

2. La mise en place des slicers

2.1. Les éléments

Pour créer l’élément de gestion des périodes il vous faudra 4 segments différents :
  1. Un segment pour mettre les option de dates de la période principale (Date Period.Type)
  1. Un segment pour mettre le date range de la période principale si l’utilisateur choisit de sélectionner une période customisée (Calendar.Date)
  1. Un segment pour mettre les option de dates de la période principale (Date Period Comparison.comparison period)
  1. Un segment pour mettre le date range de la période de comparaison si l’utilisateur choisit de sélectionner une période customisée (Calendar Comparison.Date)
Image without caption

2.2. Les mesures de filtre

Pour ne pas que les utilisateurs soient confus, il faut que les deux segments de date range soient désactivés (donc inutilisables) lorsque l’option Custom liée n’est pas sélectionnée.
Pour ça, il faut créer une mesure pour chaque date range qui servira de filtre pour que l’élément soit seulement actif quand Custom est choisit :
sql
Date Range Filter = IF( SELECTEDVALUE('Date Period'[Type]) = "Custom", 1, 0 )
Pour la période principale
sql
Date Range Filter Comparison = IF( SELECTEDVALUE('Date Period Comparison'[comparison period]) = "Custom", 1, 0 )
Pour la période de comparaison
Pour les composants 2 et 4, il faut respectivement amener Date Range Filter et Date Range Filter Comparison dans le panel des filtres et mettre la condition est 1.
Image without caption
Image without caption

2.3. Les interactions entre les visuels

Le set-up est presque terminé ! Il ne manque plus qu’à éditer les interactions pour que les deux segments responsables du type de période agissent sur son date range respectif, mais pour que le date range n’agissent pas sur le type de période (i.e. on ne veut pas que si notre dernière sélection customisée est les 7 derniers jours, ne plus être capable de sélectionner Last Month dans le dropdown).
Pour ça, sélectionner un visuel > Format > Modifier les interactions.

3. Les mesures

Voilà (enfin) l’étape où notre sélection de période va nous servir ! 🎉

3.1. Les dates de début et de fin de période

Pour certaines mesures, on aura besoin d’avoir les dates de début et de fin de période. Voilà comment les calculer.
Période principale (pré-requis à la période de comparaison)
Période de comparaison

3.2. La période principale

Ça c’est le plus simple, comme notre table Date Period utilise des formules de time intelligence, il n’y a plus qu’à gérer le cas où l’utilisateur choisit Custom.
Exemple pour une métrique, nouveaux utilisateurs :
sql
Current New Users = SWITCH ( TRUE (), SELECTEDVALUE ( 'Date Period'[Type] ) = "Custom", SUM ( TableDeMetriques[total_new_users] ), CALCULATE ( SUM ( TableDeMetriques[total_new_users] ), REMOVEFILTERS ( 'Calendar'[Date] ) ) )
  • REMOVEFILTERS ( 'Calendar'[Date] ) est indispensable pour la même raison que pour la mesure Current Period Start Date

3.3. La période de comparaison

Pour la période de comparaison, il y a plus d’étapes parce que la sélection du type de comparaison (Previous Period, Same Period Last Year, ou Custom) n’ont pas de fonction de time intelligence derrière. De plus, on a besoin d’un peu plus d’adaptabilité car lorsque la période principale est MTD et la période de comparaison est Previous Period, nous voulons que la comparaison donne le Previous MTD (e.g. Période principale : 01/08 - 13/08 alors Période de comparaison : 01/07 - 13/07 - et pas 19/07 - 31/07). La même logique applique pour Last Month où on ne veut pas avoir en comparaison les 30 jours d’avant (si le mois dernier est septembre), mais le mois précédent en entier (donc août). En résumé, on veut comparer des période équivalentes.
Pour rendre les choses plus compréhensibles, on va séparer notre mesure en 3 :
Comparaison Custom
Comparaison Previous Period
On regroupe tout ça dans une seule mesure
Icon
On a tout ce qu’il nous faut ! 💃
Maintenant on peut utiliser dans nos visuels les mesures Current New Users et Full Comparison Period New Users
Image without caption

3.4. [Bonus] Les % de différence

Et pour les courageux qui ont tenu jusqu’ici, ce qui est bien pratique avec ces mesures c’est que l’on peut les utiliser facilement pour calculer des pourcentages de différence :
sql
% Diff New Users = CONCATENATE ( CONCATENATE ( IF ( [Current New Users] >= [Full Comparison Period New Users], "+", "" ), ROUND ( ( DIVIDE ( [Current New Users] - [Full Comparison Period New Users], [Full Comparison Period New Users], 0 ) ) * 100, 1 ) ), "%" )
PS : Je vous ai même inclus la méthode pour avoir directement le format +X% ou -X%
✍️
L’auteure : Eva Despesse
Image without caption
BI Engineer chez UnNest, Eva est en charge des sujets de modélisation de la donnée et du dashboarding, notamment sur Tableau et Power BI.
Ayant commencé dans une start-up, j’ai pu toucher aux flux de données de bout en bout. J’apprécie particulièrement faire les modélisations en bout de chaine avec le dashboarding pour suivre toute la chaine de transformation de données en information.
✉️ Me contacter : eva.despesse@unnest.co