Coffee House Analysis

En un coup d’œil

Les montants de la source sont des entiers sans devise. Ils sont notés U.M dans le rapport comme sur cette page. Les prix vont de 10 à 35 U.M par article, et la carte proposée situe le café en Inde.

L’analyse porte sur les heures d’ouverture et de renfort, la contribution des produits au chiffre d’affaires et la composition des paniers.

Structure des fichiers sources

Le jeu de données public réunit deux exports du système de caisse. Une commande se décompose en plusieurs lignes, une par produit acheté, et le catalogue fournit le nom et le prix de chaque référence.

L’horodatage created_at sert de référence temporelle unique. La colonne updated_at est écartée des deux fichiers, car elle enregistre la dernière écriture en base.

Quatre contrôles sur les sources

Le rapport repose entièrement sur la colonne total. Avant de l’agréger, quatre vérifications portent sur la cohérence interne des fichiers.

Les totaux correspondent exactement au prix catalogue multiplié par la quantité. Trois produits du catalogue n’ont jamais été vendus sur la période, ce qui laisse 47 références dans les analyses par produit.

Préparer dans Power Query

La préparation rend l’horodatage exploitable dans les analyses. Il est dupliqué puis séparé en une date et une heure. L’heure ronde alimente la lecture horaire, tandis que le prix unitaire recalculé sert au contrôle avec le catalogue.

#"Removed Columns"   = Table.RemoveColumns(#"Changed Type", {"updated_at"}),
#"Duplicated Column" = Table.DuplicateColumn(#"Removed Columns", "created_at", "created_at - Copy"),
#"Extracted Date"    = Table.TransformColumns(#"Duplicated Column", {{"created_at", DateTime.Date, type date}}),
#"Extracted Time"    = Table.TransformColumns(#"Extracted Date", {{"created_at - Copy", DateTime.Time, type time}}),
#"Added Custom"      = Table.AddColumn(#"Extracted Time", "unit_price", each [total] / [quantity]),
#"Added Custom1"     = Table.AddColumn(#"Renamed Columns", "order_hour", each Time.Hour([time_created]))

Une seconde requête relit le même fichier et le regroupe par commande. Elle produit une ligne par commande, la quantité totale et une classe de panier.

#"Grouped Rows"  = Table.Group(#"Removed Columns1", {"order_id"},
                       {{"total_quantity", each List.Sum([quantity]), type nullable number}}),
#"Added Custom3" = Table.AddColumn(#"Grouped Rows", "order_size", each
                       if [total_quantity] <= 5 then "Small"
                       else if [total_quantity] <= 10 then "Medium"
                       else "Large")

Les seuils de 5 et 10 articles ont été choisis pour distinguer les commandes individuelles, partagées et de groupe. Ces catégories sont absentes de la source. Le plus gros panier de la période compte 64 articles.

Le modèle

Le modèle en étoile place les lignes de commande au centre et le catalogue dans une dimension produit. La table des paniers résume les commandes à un grain supérieur à celui des lignes et fonctionne comme une seconde table de faits.

Le filtrage bidirectionnel propage la sélection du segment Taille de panier jusqu’aux lignes de commande et recalcule le revenu sur la catégorie choisie.

Une table de dates alignée sur les ventes

Les mois, les jours de semaine et les comparaisons mensuelles s’appuient sur un calendrier calculé, borné par la première et la dernière vente.

DateTable =
ADDCOLUMNS(
    CALENDAR( MIN( 'order'[Order date] ), MAX( 'order'[Order date] ) ),
    "Year",         YEAR( [Date] ),
    "Month Number", MONTH( [Date] ),
    "Month Name",   FORMAT( [Date], "mmmm" ),
    "Day of Week",  WEEKDAY( [Date], 2 ),
    "Day Name",     FORMAT( [Date], "dddd" )
)

Le second argument de WEEKDAY place le lundi en premier jour, ce qui aligne la lecture hebdomadaire sur la semaine de travail. La date automatique de Power BI reste active en parallèle. Le segment Mois s’appuie sur la hiérarchie qu’elle génère.

Les mesures

Le modèle compte 22 mesures réparties en quatre familles. Les agrégats de base alimentent presque tous les visuels ; les autres familles servent une lecture précise.

Identifier l’heure de revenu maximal

La carte Peak hour renvoie l’heure associée au revenu maximal. La mesure classe les heures selon leur revenu, puis retourne la première.

peak_hour =
VAR HourSales =
    ADDCOLUMNS(
        VALUES( 'order'[Order hour] ),
        "revenue", [hourly_revenue]
    )
RETURN
    MAXX( TOPN( 1, HourSales, [revenue], DESC ), 'order'[Order hour] )

La même construction sert au produit vedette : top_prod classe les noms de produits par nombre de commandes distinctes et renvoie le premier. Les deux mesures suivent la sélection courante, si bien qu’un filtre de mois change l’heure et le produit affichés.

Trois mesures pour un écart mensuel

Chaque écart affiché sur la vue d’ensemble combine une valeur décalée d’un mois, une différence et une chaîne de caractères qui ajoute le signe. La mise en forme finale permet d’afficher le signe plus devant une valeur positive.

prevmonth_orders =
    CALCULATE( [Unique orders], DATEADD( 'DateTable'[Date], -1, MONTH ) )

delta_orders = [Unique orders] - [prevmonth_orders]

format_order_delta =
VAR Delta = [delta_orders]
RETURN
    SWITCH(
        TRUE(),
        Delta > 0, "+" & FORMAT( Delta, "0" ),
        Delta < 0, "-" & FORMAT( ABS( Delta ), "0" ),
        "0"
    )

La mise en forme convertit la mesure affichée en texte. Les calculs et les tris numériques utilisent donc les mesures chiffrées conservées en amont.

La composition des deux pages

Deux pages masquées de 320 sur 240 pixels servent d’infobulle. Le survol d’un mois sur la barre de revenu ou d’un jour sur le graphique hebdomadaire ouvre une fiche avec le revenu, les commandes, la quantité et les meilleurs produits de la période concernée. Le détail par produit reste accessible sans occuper de place sur la page.

Le segment Mois figure sur les deux pages, le segment Taille de panier sur la seconde, et un bouton remet les sélections à zéro. Une troisième page tient la liste complète des lignes de commande pour la vérification et l’export.

Le thème personnalisé utilise le brun foncé pour la série principale, le tan et le crème pour les séries secondaires, puis réserve le vert et l’ambre aux états positif et neutre des indicateurs de croissance. Les en-têtes de visuels sont masqués et les titres sont composés en zones de texte, ce qui permet un titre et un sous-titre distincts au-dessus de chaque bloc.

Résultats commerciaux

Entre 15 h et 17 h, le café réalise 98 % de son revenu, dont 62 % à 16 h. Les commandes restent rares pendant le reste de la journée. Cette concentration situe les besoins de préparation, de réassort et de présence en salle sur ces trois heures.

Le chaii représente 26 % du revenu et apparaît dans 2 243 commandes sur 3 282, soit deux commandes sur trois. Lunch normal suit à 16 % et Executive lunch à 7 %. Sur les 47 références vendues, les huit premières génèrent 70 % du revenu. Une rupture de chaii toucherait donc une grande partie des commandes.

Une commande compte 4,5 articles en moyenne. Les commandes de cinq articles ou moins représentent 80 % du volume et 49 % du revenu. Les commandes de plus de dix articles pèsent 6 % du volume pour 29 % du revenu. Le plus gros panier atteint 64 articles ; la source ne contient aucune variable permettant de préciser la nature de cette commande de groupe.

Les revenus du jeudi, du mardi et du mercredi se situent entre 57 000 et 61 000 U.M. Ils atteignent 46 000 le vendredi et 12 000 le samedi. Le dimanche n’apparaît jamais dans les données, ce qui peut indiquer une fermeture hebdomadaire.

Le revenu passe de 3 215 U.M en avril à 126 920 en mai puis 158 660 en juin. Avril couvre six jours de service à partir du 21, tandis que juin s’arrête le 19. La hausse d’avril à mai provient surtout de cette différence de couverture. La comparaison de mai à juin donne 25 % et constitue la seule comparaison mensuelle interprétable sur la période.

Trois précisions de lecture

Écart entre l’affichage et la valeur

Le format de trois chiffres du rapport prête à confusion. Les valeurs corrigées sont documentées ici ; le fichier livré reste inchangé.

Périmètre du dénominateur de l’anneau

Le visuel conserve les produits pesant 3 % ou plus du revenu. La mesure de contribution divise par ALLSELECTED sur la table produit et respecte ce filtre. Son dénominateur vaut 202 080 U.M, soit le revenu des huit produits affichés ; le revenu total atteint 288 795. Le chaii apparaît ainsi à 37 %, alors que sa part du revenu total est de 26 %. Les parts de l’anneau décrivent uniquement la répartition au sein des huit produits affichés.

Interprétation de la carte %MoM

La mesure de croissance divise le taux par cent, puis le format 0,0 % le multiplie de nouveau par cent. La carte affiche donc +1,2 % là où le rapport sous-jacent vaut 1,22, soit +122 %. Le sens de variation et la flèche restent corrects.

Les écarts mensuels supposent un mois sélectionné

Sans sélection dans le segment Mois, le contexte couvre toute la période et DATEADD décale cette période entière. Les écarts affichés comparent alors la série à une fenêtre décalée. Choisir un mois rétablit la comparaison attendue.

Limites

• Deux mois partiels sur trois. La série commence le 21 avril et s’arrête le 19 juin. Seul mai est complet, ce qui interdit toute projection et limite les comparaisons mensuelles.
• Aucun identifiant client. La fidélité, la fréquence de visite et la valeur client sont hors de portée de ces deux fichiers.
• Aucune devise. Les montants sont des entiers sans unité déclarée, d’où la notation U.M.
• Aucun coût. Faute de prix de revient et de remise, le rapport mesure uniquement le chiffre d’affaires.
• Un seul horodatage. Rien n’indique si created_at enregistre la prise de commande ou l’écriture en base. La concentration de 98 % du revenu entre 15 h et 17 h peut correspondre à un service de fin d’après-midi ou à une saisie groupée.

Fichiers

Le rapport est construit au format PBIP : le rapport et le modèle sont enregistrés en texte, donc lisibles dans un diff. Le PDF conserve les deux pages paysage à leur taille d’origine.

Les chiffres cités sur cette page sont recalculés directement depuis les deux fichiers CSV, indépendamment du rapport. Ils servent de référence si le modèle évolue.