Building a vacation rental analytics dashboard in Yellowfin

Het runnen van een vakantieverhuur is een arbeidsintensieve taak.

Communiceren met gasten, het aansturen van schoonmaakpersoneel, het ontwikkelen van een prijsstrategie... Het is allemaal tijdrovend werk.

Wat het nog moeilijker maakt, is dat veel beslissingen worden genomen met onvolledige informatie: een gevoel dat "deze maand druk aanvoelde", een vermoeden dat de prijzen misschien te laag zijn, of een vaag gevoel dat één boekingskanaal begint te domineren. Dat is hoe intuïtie geruisloos bewijs vervangt.

Dit is waar analytics voor vakantieverhuur zijn waarde bewijst

Analytics geeft ons een objectief beeld van wat er daadwerkelijk in het bedrijf gebeurt, zodat we minder tijd besteden aan gissen en meer tijd aan handelen. Belangrijker nog, het helpt ons om een constant hoogwaardige ervaring te leveren waardoor gasten blijven terugkomen.

De uitdaging is dat de waarheid meestal versnipperd is over boekingsplatforms, spreadsheets en onderbuikgevoelens. Een goed dashboard brengt dit op één plek samen en geeft gebruikers een snelle, eerlijke blik op de prestaties, met de mogelijkheid om dieper te graven op het moment dat er iets afwijkends of onverwacht goeds te zien is. Dat gezegd hebbende, dit is wat we gaan bouwen:

Stap voor stap: hoe we het dashboard voor vakantieverhuur hebben gebouwd

Wanneer u een app bouwt, is het doel niet alleen om gebruikers grafieken te geven. Het doel is om ze vertrouwen te geven binnen de workflow waarin ze al werken. Daar is embedded analytics voor bedoeld. Het dashboard bevindt zich in uw app, spreekt uw producttaal en beantwoordt de vragen die gebruikers al stellen, zonder ze naar een spreadsheet of ander platform te sturen.

In deze blogpost bouwen we dezelfde soort basis die u in een echt embedded scenario zou gebruiken:

• een boekingsdataset opgeslagen in PostgreSQL
• een schone databronverbinding in Yellowfin
• Een View ontworpen voor dashboards en NLQ
• en een dashboard dat kan worden uitgebreid naarmate uw product groeit

Stap 1: Hoe u de PostgreSQL-database aanmaakt

We beginnen met het opslaan van boekingen in PostgreSQL, met één rij per boeking en variabelen zoals boekingsdatum, geboekte nachten, nachttarief, enz. Open vanuit PowerShell psql en maak een database aan voor de demo:

CREATE DATABASE hotel_demo;

\c hotel_demo

Maak de boekingentabel (bookings table) aan

Vervolgens maken we een platte boekingentabel (flat bookings table) die is ontworpen om de soorten vragen te ondersteunen die eigenaren van accommodaties van nature stellen.

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)

);

Deze structuur is opzettelijk eenvoudig – het weerspiegelt hoe boekingssystemen werken, houdt de granulariteit duidelijk en maakt downstream analyses gemakkelijker uit te leggen en uit te breiden.

Laad de data vanuit een CSV-bestand in onze PostgreSQL-tabel

Zodra de tabel klaar is, laden we de CSV:

\copy bookings_flat

FROM 'C:\Users\YourUser\Desktop\bookings_flat.csv'

DELIMITER ','

CSV HEADER;

Een snelle controle bevestigt dat alles erin staat:

SELECT COUNT(*) FROM bookings_flat;

Op dit moment hebben we een schone dataset op boekingsniveau die klaar is om te worden gekoppeld aan een analyselaag.

In de volgende stap verbinden we deze database met Yellowfin, bouwen we onze eerste Views en beginnen we de data vorm te geven tot iets dat uw eindgebruikers direct in uw product kunnen verkennen.

Stap 2: Verbind PostgreSQL met Yellowfin en stel de data veilig beschikbaar

De volgende taak is om de database op een gecontroleerde manier beschikbaar te maken voor de analyselaag.

Dit is waar Yellowfin in beeld komt.

Voor productteams is deze stap cruciaal. U verbindt niet zomaar een database. U bepaalt wat uw eindgebruikers in uw applicatie mogen zien, waarover ze vragen mogen stellen en waaruit ze inzichten kunnen opbouwen.

Maak een PostgreSQL-databron aan in Yellowfin

Vanuit de Yellowfin-beheerdersinterface maken we een nieuwe databron aan en verwijzen we deze naar onze PostgreSQL-instantie.

U heeft het volgende nodig:

• host
• poort (port)
• databasenaam
• gebruikersnaam en wachtwoord

Eenmaal verbonden, kan Yellowfin het databaseschema zien, maar er is nog niets zichtbaar voor gebruikers. Die scheiding is belangrijk. Tabellen zijn niet automatisch beschikbaar voor rapportage.

Maak een View aan op de boekingentabel

We maken nu een View aan op basis van de bookings_flat tabel.

In Yellowfin:

• maak een nieuwe View aan
• selecteer bookings_flat als de basistabel

Binnen de View veranderen we velden in metrics, dimensies en tijd waar dat nodig is.

Deze stap lijkt misschien administratief, maar het heeft een directe impact op de gebruikerservaring. Een goed gedefinieerde View maakt het bouwen van dashboards gemakkelijker en NLQ-vragen veel betrouwbaarder.

Wat dit direct mogelijk maakt

Met één enkele View op zijn plaats, ontgrendelen we direct verschillende zaken:

• dashboards kunnen worden gebouwd zonder SQL aan te raken
• NLQ begrijpt wat er kan worden geteld, gemiddeld of gegroepeerd
• productteams kunnen analyses doorontwikkelen zonder de database te wijzigen

Het belangrijkste is dat we een heldere grens hebben gecreëerd. PostgreSQL blijft de bron van de waarheid. Yellowfin wordt de verhalende laag (storytelling layer).

In de volgende stap gebruiken we deze View om de eerste grafieken voor het dashboard te bouwen en laten we zien hoe NLQ natuurlijk in de ervaring past.

Stap 3: Bouw de eerste grafieken en laat NLQ doen waar het goed in is

Met de boekings-View op zijn plaats, kunnen we eindelijk de vraag beantwoorden die belangrijk is voor productteams:

Hoe ziet een nuttige analytics-ervaring eruit voor een eindgebruiker?

Het doel hier is niet om elke mogelijke grafiek te bouwen. Het is om de juiste naar boven te halen. Grafieken die direct duidelijkheid geven en die van nature uitnodigen tot vervolgvragen.

Dit is waar Yellowfin begint te schitteren.

Begin met resultaat, niet met exploratie

We beginnen door eerst grafieken te bouwen die vragen op resultaatniveau (outcome-level) beantwoorden. Dit zijn de vragen die eigenaren van accommodaties stellen zonder dat ze daartoe aangespoord hoeven te worden.

Omzet in de loop van de tijd
Dit is het anker. Het vertelt gebruikers of het bedrijf de goede kant op gaat en biedt context voor alles wat er verder op het dashboard staat. Op zichzelf verklaart het niet waarom de omzet is veranderd, maar het vertelt ons wel waar we vervolgens naar moeten kijken.

Gemiddeld nachttarief per maand
Deze grafiek geeft betekenis aan omzetveranderingen. Het laat zien of de prestaties worden gedreven door prijs of door volume. Wanneer de omzet stijgt terwijl de tarieven stabiel blijven, neemt de vraag waarschijnlijk toe. Wanneer de tarieven dalen zonder een stijging in boekingen, wordt de prijsstrategie een vraagstuk.

Deze twee grafieken samen verminderen het giswerk al. Ze veranderen vage indrukken in iets meetbaars.

Voeg gedragscontext toe

Zodra de resultaten zichtbaar zijn, voegen we een laag met gedrag toe.

Aantal boekingen
Boekingen tonen de vraag onafhankelijk van de prijs. Een stijging in boekingen gepaard met een gelijkblijvende omzet suggereert druk op de prijzen. Minder boekingen met een stabiele omzet betekent vaak een langer verblijf of gasten die meer opleveren.

Gemiddelde verblijfsduur
Hier komt de operationele realiteit in beeld. Een langer verblijf betekent meestal minder wisselingen en meer voorspelbare operaties. Een korter verblijf verhoogt de werkdruk en kan een zwakkere vraag verbergen achter een hoger aantal boekingen.

Deze grafieken helpen gebruikers niet alleen te begrijpen wát er is gebeurd, maar ook hóe het is gebeurd.

Maak de strategie zichtbaar

Tot slot brengen we de grafieken naar voren die langetermijnbeslissingen beïnvloeden.

Omzet per kanaal
Dit toont hoe afhankelijk het bedrijf is van Booking.com, Airbnb, Expedia, directe boekingen of inloop. Een grote afhankelijkheid van OTA's (Online Travel Agencies) kan het volume verhogen, maar heeft invloed op de marges. Groei in directe boekingen duidt vaak op een gezondere vraag en een sterkere merkherkenning.

Herkomst van de gast
Het land van de gast voegt context toe die cijfers alleen niet kunnen bieden. Na verloop van tijd kan deze grafiek richting geven aan marketingfocus en seizoensgebonden prijsbeslissingen.

Waar NLQ op een natuurlijke manier in past

Zodra deze grafieken er staan, is NLQ geen nieuwtje meer en begint het te functioneren als een natuurlijke uitbreiding van het dashboard.

Gebruikers kunnen vervolgvragen stellen zoals:

• boekingen per kanaal vorige maand
• gemiddeld nachttarief voor directe boekingen
• omzet van gasten in Duitsland
• verblijfsduur per apparaat

Omdat de View zorgvuldig is ontworpen, leveren deze vragen zinnige antwoorden op zonder dat er uitleg nodig is. NLQ werkt het beste wanneer het datamodel al weerspiegelt hoe gebruikers denken.

Waarom dit belangrijk is voor productteams

U laat gebruikers geen statische rapporten meer zien. U geeft ze:

• een gedeeld beeld van de prestaties
• de mogelijkheid om hun eigen vragen te stellen
• het vertrouwen dat inzichten uit dezelfde bron van waarheid komen

En het beste deel? Naarmate er data uw database binnenkomt, worden de grafieken in Yellowfin automatisch bijgewerkt. Dit betekent dat uw gebruikers een realtime overzicht hebben van hoe het bedrijf presteert.

Denkt u dat u klaar bent om uw eigen dashboard te gaan bouwen? Meld u aan voor een persoonlijke testomgeving (private playground) waar u de volledige kracht van Yellowfin kunt ervaren. Bonus: u vindt hier codevoorbeelden die het eenvoudig maken om analytics in uw app in te sluiten.