Dashboards die zeggen wat je nog niet wist

Ja, en vaak is dat ook waar een traject begint. Een dashboard op vieze data geeft mooie grafieken die niets zeggen, of erger: cijfers die elkaar tegenspreken. Eerst volgt een data-quality audit: welke bronnen heb je, welke velden zijn betrouwbaar, waar zitten dubbelingen, lege records, foute formats, achterhaalde definities. Daarna wordt een lichte modelleerlaag ingericht (vaak met dbt) waar de logica eenmalig staat: wat is een actieve klant, hoe wordt omzet geteld, wat hoort bij welke campagne. Pas op die schone laag worden dashboards en AI-analyses gebouwd. Dat klinkt als omweg maar is goedkoper dan twee keer iets bouwen op data waar je niet op kunt vertrouwen. Eerlijk: soms is dit voorwerk groter dan het dashboard zelf, en dat wordt er dan ook bij gezegd.

DataDream werkt met BigQuery, Postgres of DuckDB als warehouse, dbt voor de modellering, Fivetran of Airbyte voor connectoren (of custom scripts als dat goedkoper is), en Looker Studio, Metabase of Hex voor dashboards. Voor AI-analyses wordt Claude of GPT via API gebruikt. Dit is bewust een open stack: je SQL-modellen draaien op elke warehouse, dbt is open source, dashboards worden geplaatst in een tool die jij zelf kunt beheren. Documentatie en code worden altijd geleverd in jouw repository, niet in een platform waar je vast zit. Als je later van leverancier wisselt, of het zelf wil overnemen, kan dat. Geen black box.

Klantsegmentatie en gedragsanalyse vallen onder de AVG zodra je persoonsgegevens verwerkt, ook als het alleen e-mail of klant-ID is. Belangrijk: een grondslag moet helder zijn. Voor analyses op je eigen klantdata is dat meestal gerechtvaardigd belang of uitvoering van overeenkomst, mits je het kunt onderbouwen en de impact op de klant beperkt is. DataDream helpt die afweging maken en documenteren. Voor zwaardere profilering met geautomatiseerde besluitvorming gelden strengere regels (artikel 22 AVG). Praktische maatregelen die standaard worden ingericht: pseudonimiseren waar het kan, retentietermijnen op datasets, geen klantdata naar externe AI-leveranciers zonder DPA, en een verwerkingsregister-update zodat je het kunt verantwoorden bij een audit. Voor twijfelgevallen kijkt de AI Quickscan eerst welke data je mag gebruiken.

Zelf onderhouden is het uitgangspunt. Dashboards worden gebouwd in tools die je zelf kunt openen, aanpassen en delen, zoals Looker Studio (gratis, Google-account) of Metabase (open source, eigen server). De SQL-modellen daaronder staan in dbt en zijn versiebeheerd in jouw GitHub of GitLab, dus iedere collega met SQL-kennis kan ze lezen en wijzigen. Bij elke metric staat uitleg: wat telt mee, wat niet, en waarom. Als je een interne data-collega hebt of inhuurt, kan die het overnemen. DataDream blijft graag betrokken voor de zware AI-analyses en nieuwe bronnen, maar dat is een keuze, geen verplichting.

Een data warehouse is een gestructureerde opslag voor schone, gemodelleerde data, typisch SQL-tabellen waar dashboards en rapportages op draaien. Voorbeelden: BigQuery, Snowflake, Postgres, DuckDB. Een data lake is een rauwere opslag, vaak in een goedkoop bestandssysteem (S3, GCS), waar data in zijn oorspronkelijke vorm landt voordat hij gemodelleerd wordt. Voor de meeste MKB-bedrijven is een data warehouse genoeg. Een data lake (of "datalake") wordt pas zinvol bij hoge volumes ongestructureerde data, bijvoorbeeld logbestanden, afbeeldingen, of sensordata waar je later iets mee wil. Het advies is bijna altijd te beginnen bij een eenvoudig warehouse (BigQuery is goedkoop tot je er niet meer onder uit komt) en pas uit te bouwen naar een lake-architectuur als de use cases dat rechtvaardigen. Dataverwerking en data-quality is overal hetzelfde principe: schoon model, herleidbare definities, geteste pipelines.

Ja. DataDream werkt vaak met Looker Studio, Metabase of Hex omdat dat sneller en goedkoper is voor het MKB, maar als jullie al fors investeren in Power BI of Tableau dan wordt daar gewoon op verder gebouwd. De warehouse en de dbt-modellen werken hetzelfde, alleen de visualisatie-laag verschilt. Een veelvoorkomend patroon: het dashboard-werk in Power BI is prima, maar de data eronder is een wirwar van Excel-exports en handmatige stappen. Daar zit de winst, niet in de visualisatie. Dan wordt de pipeline aangepakt en blijft Power BI de presentatie-laag. Hetzelfde geldt voor Tableau, Qlik, of Pyramid.

Ja, en dat is vaak waar de meeste waarde zit. Als je data al schoon staat in een warehouse, kan daar bovenop worden gebouwd: anomalie-detectie (welke transacties wijken af van het patroon), klantsegmentatie op gedrag (clustering met machine learning), voorspellingen (cashflow, voorraad, klantverloop), sentiment-analyse op reviews of supporttickets, en natural-language interfaces ("vraag aan je data hoeveel orders er vorige maand uit Brabant kwamen"). Er wordt aangesloten op bestaande tabellen, geen nieuwe systemen toegevoegd als het niet hoeft, en de output wordt geleverd in dashboards die je al kent of in geautomatiseerde rapportages naar e-mail of Slack.

Drie checks die standaard worden ingebouwd. Een: elk getal in een dashboard heeft een definitie en een herleidbare query. Je kunt altijd doorklikken naar de onderliggende rijen om te kijken of het klopt. Twee: dbt heeft tests (uniqueness, niet-null, referentiele integriteit, business-rules) die op elke run draaien. Als de data afwijkt komt er een alert voor jij het in het dashboard ziet. Drie: voor AI-analyses (voorspellingen, segmentaties) wordt een back-test gedaan op historische data en wordt getoond hoe goed de output overeenkomt met wat er werkelijk gebeurde. Geen blind vertrouwen op een model. Als de back-test slecht is, wordt dat gezegd. Een goed dashboard zegt wat je niet wist, maar het moet wel kloppen.

Ja, en dat is precies het onderscheid tussen een dashboard en een agentic data-workflow. Een dashboard wacht totdat iemand inlogt en kijkt. Een data-agent krijgt API-toegang tot je bronnen (GA4 Data API, HubSpot, Shopify, Exact, je eigen database) via access tokens en handelt het proces autonoom af: data ophalen, transformeren, afwijkingen detecteren, AI-samenvatting schrijven, rapport sturen. Wekelijks, dagelijks, of getriggerd door een drempelwaarde. Jij stelt de guardrails in: welke bronnen de agent mag lezen, welke metrics hij bewaakt, wanneer hij een alert stuurt en naar wie. Dit is fundamenteel anders dan een scheduled export of een BI-refresh: de agent besluit wat rapportagewaardig is, niet alleen wat er staat. Voor de bredere agentic aanpak zie AI agents.