Gérer une location de vacances est une tâche laborieuse.
Communiquer avec les clients, gérer le personnel de ménage, développer une stratégie de tarification… Tout cela prend beaucoup de temps.
Ce qui rend les choses encore plus difficiles, c'est que de nombreuses décisions sont prises avec des informations partielles : l'impression que « ce mois-ci a semblé chargé », le pressentiment que les prix pourraient être trop bas, ou le vague sentiment qu'un canal de réservation commence à dominer. C'est ainsi que l'intuition remplace discrètement les preuves.
C'est là que l'analyse des locations de vacances prouve sa valeur
L'analyse de données nous donne une vision objective de ce qui se passe réellement dans l'entreprise, ce qui nous permet de passer moins de temps à deviner et plus de temps à agir. Plus important encore, elle nous aide à offrir une expérience de haute qualité constante qui fidélise les clients.
Le défi réside dans le fait que la vérité est généralement éparpillée entre les plateformes de réservation, les feuilles de calcul et les intuitions. Un bon tableau de bord rassemble tout cela au même endroit et donne aux utilisateurs une lecture rapide et honnête des performances, avec la possibilité d'explorer plus en détail dès que quelque chose semble anormal ou étonnamment bon. Cela étant dit, voici ce que nous allons construire :
Étape par étape : comment nous avons construit le tableau de bord pour la location de vacances
Lorsque vous créez une application, le but n'est pas seulement de fournir des graphiques aux utilisateurs. Le but est de leur donner confiance au sein du flux de travail dans lequel ils évoluent déjà. C'est à cela que servent les analyses intégrées (embedded analytics). Le tableau de bord se trouve à l'intérieur de votre application, parle le langage de votre produit et répond aux questions que les utilisateurs se posent déjà, sans les renvoyer vers une feuille de calcul ou une autre plateforme.
Dans cet article de blog, nous allons construire le même type de fondation que vous utiliseriez dans un véritable scénario d'intégration :
- un jeu de données de réservations stocké dans PostgreSQL
- une connexion de source de données propre dans Yellowfin
- Une Vue conçue pour les tableaux de bord et le NLQ
- et un tableau de bord qui peut être étendu au fur et à mesure de la croissance de votre produit
Étape 1 : Comment créer la base de données PostgreSQL
Nous commençons par stocker les réservations dans PostgreSQL, avec une ligne par réservation et des variables telles que la date de réservation, les nuits réservées, le tarif par nuit, etc. À partir de PowerShell, ouvrez psql et créez une base de données pour la démo :
CREATE DATABASE hotel_demo;
\c hotel_demo
Créer la table des réservations
Ensuite, nous créons une table de réservations plate (flat table) conçue pour prendre en charge les types de questions que les propriétaires se posent naturellement.
DROP TABLE IF EXISTS bookings_flat; CREATE TABLE bookings_flat ( booking_id INTEGER PRIMARY KEY, booking_date DATE, nights_booked INTEGER, guests INTEGER, apartment_capacity INTEGER, guest_country TEXT, channel_type TEXT, device TEXT, nightly_rate_eur NUMERIC(10,2), total_booking_value_eur NUMERIC(12,2) );
Cette structure est intentionnellement simple : elle reflète le fonctionnement des systèmes de réservation, maintient une granularité évidente et rend les analyses en aval plus faciles à expliquer et à étendre.
Charger les données à partir d'un fichier CSV dans notre table PostgreSQL
Une fois la table en place, nous chargeons le CSV :
\copy bookings_flat
FROM 'C:\Users\YourUser\Desktop\bookings_flat.csv'
DELIMITER ','
CSV HEADER;
Une vérification rapide confirme que tout y est :
SELECT COUNT(*) FROM bookings_flat;
À ce stade, nous disposons d'un jeu de données propre au niveau de la réservation, prêt à être exposé à une couche d'analyse.
Dans la prochaine étape, nous connecterons cette base de données à Yellowfin, construirons nos premières Vues (Views) et commencerons à façonner les données en quelque chose que vos utilisateurs finaux pourront explorer directement au sein de votre produit.
Étape 2 : Connecter PostgreSQL à Yellowfin et exposer les données en toute sécurité
La tâche suivante consiste à rendre la base de données disponible pour la couche d'analyse de manière contrôlée.
C'est là que Yellowfin entre en jeu.
Pour les équipes produit, cette étape est cruciale. Vous ne connectez pas seulement une base de données. Vous décidez de ce que vos utilisateurs finaux seront autorisés à voir, des questions qu'ils pourront poser et des informations qu'ils pourront tirer de votre application.
Créer une source de données PostgreSQL dans Yellowfin
Depuis l'interface d'administration de Yellowfin, nous créons une nouvelle source de données et la pointons vers notre instance PostgreSQL.
Vous aurez besoin de :
- hôte
- port
- nom de la base de données
- nom d'utilisateur et mot de passe
Une fois connecté, Yellowfin peut voir le schéma de la base de données, mais rien n'est encore exposé aux utilisateurs. Cette séparation est importante. Les tables ne sont pas automatiquement disponibles pour les rapports.
Créer une Vue sur la table des réservations
Nous créons maintenant une Vue (View) basée sur la table bookings_flat.
Dans Yellowfin :
- créez une nouvelle Vue
- sélectionnez bookings_flat comme table de base
À l'intérieur de la Vue, nous convertissons les champs en métriques, dimensions et temps (time) là où c'est nécessaire.
Cette étape peut sembler administrative, mais elle a un impact direct sur l'expérience utilisateur. Une Vue bien définie rend les tableaux de bord plus faciles à construire et les questions NLQ beaucoup plus fiables.
Ce que cela permet immédiatement
Avec une seule Vue en place, nous débloquons plusieurs choses à la fois :
- les tableaux de bord peuvent être construits sans toucher au SQL
- le NLQ comprend ce qui peut être compté, moyenné ou groupé
- les équipes produit peuvent faire évoluer l'analyse sans modifier la base de données
Le plus important, c'est que nous avons créé une frontière nette. PostgreSQL reste la source de vérité. Yellowfin devient la couche narrative (storytelling layer).
Dans la prochaine étape, nous utiliserons cette Vue pour construire les premiers graphiques du tableau de bord et montrerons comment le NLQ s'intègre naturellement dans l'expérience.
Étape 3 : Construire les premiers graphiques et laisser le NLQ faire ce qu'il fait de mieux
Avec la Vue des réservations en place, nous pouvons enfin répondre à la question qui compte pour les équipes produit :
À quoi ressemble une expérience d'analyse utile pour un utilisateur final ?
L'objectif ici n'est pas de construire tous les graphiques possibles. Il est de faire ressortir les bons. Des graphiques qui offrent une clarté immédiate et qui invitent naturellement à poser d'autres questions.
C'est là que Yellowfin commence à briller.
Commencez par les résultats, pas par l'exploration
Nous commençons par construire des graphiques qui répondent d'abord aux questions basées sur les résultats. Ce sont les questions que les propriétaires se posent sans avoir besoin d'être incités.
Les revenus au fil du temps
C'est le point d'ancrage. Il indique aux utilisateurs si l'entreprise évolue dans la bonne direction et fournit un contexte pour tout le reste du tableau de bord. À lui seul, il n'explique pas pourquoi les revenus ont fluctué, mais il nous indique où chercher ensuite.
Tarif moyen par nuit par mois
Ce graphique donne un sens aux variations de revenus. Il montre si les performances sont stimulées par les prix ou par le volume. Lorsque les revenus augmentent en même temps que des tarifs stables, c'est que la demande est probablement en hausse. Lorsque les tarifs baissent sans augmentation des réservations, la stratégie de tarification est remise en question.
Ces deux graphiques réunis réduisent déjà les conjectures. Ils transforment de vagues impressions en données mesurables.
Ajoutez du contexte comportemental
Une fois que les résultats sont visibles, nous y intégrons le comportement.
Nombre de réservations
Les réservations reflètent la demande indépendamment du prix. Une augmentation des réservations associée à des revenus stagnants suggère une pression sur les prix. Moins de réservations avec des revenus stables signifient souvent des séjours plus longs ou des clients à plus forte valeur.
Durée moyenne de séjour
C'est ici que la réalité opérationnelle entre en jeu. Des séjours plus longs signifient généralement moins de rotations (turnovers) et des opérations plus prévisibles. Des séjours plus courts augmentent la charge de travail et peuvent cacher une demande plus faible derrière un nombre plus élevé de réservations.
Ces graphiques aident les utilisateurs à comprendre non seulement ce qui s'est passé, mais aussi comment cela s'est passé.
Rendez la stratégie visible
Enfin, nous mettons en évidence les graphiques qui influencent les décisions à long terme.
Revenus par canal
Cela montre à quel point l'entreprise dépend de Booking.com, Airbnb, Expedia, des réservations directes ou des clients de passage (walk-ins). Une forte dépendance aux OTA (agences de voyage en ligne) peut générer du volume, mais cela impacte les marges. La croissance des réservations directes signale souvent une demande plus saine et une meilleure reconnaissance de la marque.
Origine des clients
Le pays du client ajoute un contexte que les chiffres seuls ne peuvent fournir. Au fil du temps, ce graphique peut orienter les axes marketing et les décisions de tarification saisonnière.
Là où le NLQ s'intègre naturellement
Une fois ces graphiques en place, le NLQ (Requête en langage naturel) cesse d'être une nouveauté et commence à se comporter comme une extension naturelle du tableau de bord.
Les utilisateurs peuvent poser des questions de suivi telles que :
- réservations par canal le mois dernier
- tarif moyen par nuit pour les réservations directes
- revenus des clients en Allemagne
- durée du séjour par appareil
Parce que la Vue a été conçue avec soin, ces questions renvoient des réponses sensées sans nécessiter d'explications. Le NLQ fonctionne mieux lorsque le modèle de données reflète déjà la façon dont les utilisateurs pensent.
Pourquoi c'est important pour les équipes produit
Vous ne montrez plus aux utilisateurs des rapports statiques. Vous leur donnez :
- une vision partagée des performances
- la possibilité de poser leurs propres questions
- la certitude que les informations proviennent de la même source de vérité
Et la meilleure partie ? Au fur et à mesure que les données arrivent dans votre base de données, les graphiques dans Yellowfin se mettent à jour automatiquement. Cela signifie que vos utilisateurs ont une vue en temps réel des performances de l'entreprise.
Vous pensez être prêt à commencer à créer votre propre tableau de bord ? Inscrivez-vous pour un espace de test privé (playground) où vous pourrez découvrir toute la puissance de Yellowfin. En prime : vous trouverez des exemples de code qui facilitent l'intégration des analyses dans votre application.