Govanalytics versus Matomo: waar de grens van een goede keuze ligt

Bij grote Nederlandse uitvoeringsorganisaties die met Matomo (https://matomo.org) werken duikt steeds vaker hetzelfde patroon op: drie legitieme eisen die niet langer tegelijk te leveren zijn.

• Directies vragen om actuele dashboards.
• Data-architecten willen bezoekersdata in het centrale warehouse.
• Systeembeheer wil minder cron-jobs in de monitoringstack.

Twee van die drie lukt; alle drie wordt structureel lastig zodra een organisatie boven de honderd miljoen events per maand uitkomt.

Dit is geen privacy-vraagstuk. Anders dan bij Google Analytics gaat het niet over Schrems II, niet over de Autoriteit Persoonsgegevens, niet over data die naar de VS lekt. Matomo heeft die problemen vier jaar geleden al opgelost. Het gaat over wat er gebeurt als een publieke organisatie groeit voorbij waar Matomo van oorsprong voor is ontworpen (een goede privacy-first analytics-applicatie), niet een warehouse-native data-platform.

Ik werk sinds 2016 in privacy-first analytics, eerst acht jaar bij Piwik PRO. In die periode is het Matomo-vraagstuk wezenlijk veranderd. Vijf jaar geleden was de vraag of publieke organisaties bij Matomo terechtkonden. Die vraag is beantwoord; ze konden, en velen hebben het gedaan. De vraag die ervoor in de plaats is gekomen, is wat je doet als je vooruitkijkt naar de komende vijf jaar.

Wat Matomo verdient om eerst gezegd te worden

Matomo is geen Google Analytics. Dat klinkt voor de hand liggend, maar het bepaalt de toon van deze hele vergelijking. Matomo is een van de meest volwassen privacy-first analytics-producten in Europa, het draait al sinds 2007 in verschillende vormen, en het heeft een serieus aantal Nederlandse en Europese publieke organisaties succesvol uit de Google-afhankelijkheid getrokken.

Wat Matomo concreet goed doet: een uitgebreide UI met heatmaps, session recordings, A/B-testing, form analytics en funnels die je nergens anders in deze prijsklasse zo geïntegreerd vindt. Een plugin-ecosysteem dat na vijftien jaar groeien daadwerkelijk antwoord geeft op de meeste niche-vragen. Sterke privacy-tooling met cookieloze configuratie en consent-management. WordPress-integratie die in publieke contexten vaak relevant is. CNIL-erkenning, GPL-licentie, transparante roadmap.

Voor veel publieke organisaties is Matomo nog steeds het goede antwoord. Als je dashboards voor één website draait, je events-volume zit ruim onder de 2 a 3 miljoen per maand, je marketingteam gebruikt actief heatmaps en A/B-tests, en je analytics-data hoeft niet samen te leven met andere databronnen — dan is de vraag die ik ga stellen niet jouw vraag.

Voor andere organisaties is hij dat wel.

Waar Matomo’s grenzen zichtbaar worden

Het probleem met Matomo in een publieke context is niet één ding. Het zijn vier dingen, die elk afzonderlijk te hanteren zijn en die samen de aanleiding worden voor het soort mail waarmee dit artikel opent.

Het datamodel zelf. Matomo slaat data op in een genormaliseerd MySQL-schema verspreid over tabellen als log_visit, log_link_visit_action, log_action, conversion en archieftabellen. Voor dashboardgebruik via Matomo’s eigen UI is dat onzichtbaar. Voor een data-analist die de bezoekersdata wil koppelen aan andere bronnen, voor een BI-tool die direct op de database wil draaien, of voor een AI-agent die patronen moet vinden, betekent het dat elke nuttige vraag een serie joins vereist. Het schema is gemaakt om Matomo’s eigen rapportages te voeden, niet om door iemand anders bevraagd te worden.

Schaal. Matomo’s rapportages leunen op pre-aggregatie via archive-cronjobs. Onder normale belasting werkt dat prima. Boven ergens rond de honderd miljoen events per maand begint het te kraken: cron-jobs lopen achter, dashboards vertonen data van gisteren in plaats van vanmiddag, MySQL-tuning wordt een wekelijkse activiteit, en het ICT-team begint serieuze hardware-budgetten in te dienen. Niet onmogelijk om te beheren; maar het is geen analytics-tool meer, het is een infrastructuurproject.

De operationele last bij zelf hosten. Matomo zelf draaien betekent PHP, MySQL of MariaDB, archive-cron monitoring, plugin-updates, GeoIP-databases bijwerken, security patches en database-tuning. Elk onderdeel is op zich beheerbaar. Bij elkaar opgeteld vormen ze een operationele oppervlakte die voor kleinere publieke organisaties met beperkte ICT-capaciteit groot is, en die voor grotere organisaties een dedicated rol vereist. Wanneer degene die het oorspronkelijk heeft opgezet van baan wisselt, ontstaat er een typische knowledge cliff.

Het warehouse-pad. Voor publieke organisaties die een bredere datastrategie ontwikkelen — een centraal datawarehouse, dashboards die meerdere bronnen combineren, AI-toepassingen op gestructureerde data — is Matomo’s positionering ongemakkelijk. De Matomo Cloud heeft een warehouse-connector en je kunt exports naar Looker Studio of BigQuery configureren, maar dat blijft een export-workflow vanuit Matomo. De primaire opslag zit in Matomo’s eigen database; alles daarbuiten is een afgeleide. Voor een organisatie die warehouse-eerst denkt, is dat de verkeerde kant op.

Daar komt voor sommige organisaties nog een vijfde overweging bij: Matomo Cloud draait op AWS Frankfurt. Voor publieke organisaties die “data-soevereiniteit” strikt lezen — geen niet-EU-subprocessors — is dat een puntje. Voor de meeste is het geen probleem. Matomo is op dit vlak helemaal schoon als je zelf host.

Wat Govanalytics anders doet

Govanalytics is gebouwd om dit specifieke probleem op te lossen voor (publieke) organisaties die niet hun hele meetstrategie willen weggooien. De technische basis is D8a.tech, MIT-gelicenseerd open source.

Het belangrijkste eerst: Govanalytics accepteert Matomo-trackingverzoeken. Matomo’s eigen addTracker-API kan dezelfde events naar een Govanalytics-endpoint sturen, parallel aan Matomo zelf. Voor organisaties die jaren in hun Matomo-tagging hebben geïnvesteerd, betekent dat dat de tagging-implementatie niet hoeft te veranderen. Je voegt een tweede ontvanger toe, valideert dat de cijfers kloppen, en kiest dan welk pad je verder bewandelt.

De data komt aan in een vlak schema. Geen joins tussen log-tabellen, geen action-ID-resolutie. Sessiecontext, campagnedata, e-commerce-velden en custom dimensions staan direct op de event-rij. Voor BI-tools, voor data-analisten en voor AI-agents is dat het verschil tussen “we kunnen dit bevragen” en “we moeten eerst een transformatielaag bouwen”.

Er zijn geen archive-cronjobs. De data is bijna realtime queryable. Bij hoge volumes betekent dat geen dashboards die achter de feiten aanlopen omdat een batch-proces vastloopt.

Eerlijk over wat Govanalytics niet doet vergeleken met Matomo: geen heatmaps, geen session recordings, geen A/B-testing, geen form analytics. Geen plugin-ecosysteem. De ingebouwde dashboard-laag is bewust simpeler dan Matomo’s UI. Als je organisatie actief gebruikmaakt van Matomo’s bredere UI-modules, is het niet vanzelfsprekend dat Govanalytics een upgrade is; dan is het een ander soort tool.

Vier paden uit Matomo

Het zou oneerlijk zijn om te suggereren dat dit een keuze is tussen Matomo en Govanalytics. Voor publieke organisaties die tegen Matomo’s grenzen aanlopen zijn er vier paden.

Een beslissingskader dat daadwerkelijk werkt

Vier vragen die in mijn ervaring bepalen welk pad past.

• Hoe dicht zit je tegen de schaalgrens? Als je events-volume onder de tien miljoen per maand zit en daar de komende jaren niet boven uitkomt, is Matomo’s schaalvraagstuk niet jouw vraagstuk. Boven de tientallen miljoenen wordt het relevant. Boven de honderd miljoen is het meestal doorslaggevend.

• Heb je een datastrategie waarin bezoekersdata samenleeft met andere bronnen? Zo ja, dan weegt warehouse-native zwaar. Zo nee — als analytics een eilandje mag zijn dat alleen het communicatieteam gebruikt — dan is Matomo’s eigen UI vaak de pragmatische keuze.

• Hoeveel gebruik je daadwerkelijk van Matomo’s UI-modules? Wees specifiek. Heatmaps die in 2022 zijn aangezet en sindsdien niet meer bekeken, tellen niet. A/B-tests die wel gepland maar nooit gedraaid zijn, tellen niet. Als de oprechte gebruikspatronen neerkomen op standaard webrapportages plus de occasionele export, geef je minder op dan de tool-vergelijking suggereert.

• Hoeveel operationele last wil en kan je dragen? Matomo zelf hosten op grote schaal is engineering-werk. Matomo Cloud verschuift dat naar een leverancier, maar voegt de AWS-subprocessor toe. Govanalytics-managed verschuift het ook, zonder die subprocessor. Geen van deze opties is gratis — kies bewust welke vorm van last past bij jouw team.

Beantwoord deze vier eerlijk, en het juiste pad beperkt zich meestal vanzelf.

De overstap is minder pijnlijk dan veel teams denken

De grootste mythe rond een Matomo-naar-warehouse-migratie is dat je een nieuwe tracker moet uitrollen, een nieuwe tagging-implementatie moet bouwen, en al je dashboards opnieuw moet maken. In de praktijk hoeft dat niet.

Omdat Govanalytics het Matomo-trackingprotocol accepteert, kun je beginnen met Matomo’s eigen addTracker-API gebruiken om dezelfde events naar twee endpoints te sturen — Matomo zelf én Govanalytics. Geen verandering aan de website, geen nieuwe tagging-implementatie. Je laat het een aantal weken draaien, vergelijkt cijfers, valideert het schema, en kiest dan of Matomo blijft voor de UI (en Govanalytics voor de warehouse-pipeline), of dat je gaandeweg volledig overstapt.

Voor publieke organisaties met aanstaande datastrategie-deadlines, NIS2-trajecten waarin de hele toolstack tegen het licht wordt gehouden, of een centraal warehouse dat op stapel staat, is dat het verschil tussen “we kunnen dit binnen een kwartaal regelen” en “dit wordt een meerjarenproject”.

Waar dit naartoe gaat

Matomo zelf zal in deze richting bewegen. De warehouse-connector en de Looker Studio-integratie zijn al stappen in dat pad; ik verwacht dat Matomo’s eigen architectuur de komende jaren verder in de richting van warehouse-native opslag zal evolueren, omdat dat is waar de bredere data-stack naartoe gaat. De inzet die ik bij D8a.tech doe, is dat de organisaties die nu al die kant op willen, daar niet op hoeven te wachten.

De verstandige zet voor publieke organisaties die nu evalueren is om de keuze te maken die past bij de huidige operationele realiteit — met één oog op data-portabiliteit. Zorg dat wat je ook kiest je in staat stelt om je raw data eruit te krijgen en in een warehouse te laden. Daar landt de volgende migratie hoe dan ook, voor iedereen.

Matomo blijft een goede keuze voor veel publieke organisaties. Wat verandert, is dat steeds meer organisaties tegen de grens van die keuze aanlopen — meestal niet plotseling, maar geleidelijk, in de vorm van een data-architect die vraagt naar warehouse-toegang, een directie die actuelere dashboards wil, of een ICT-team dat minder cron-jobs in de monitoringstack wil. Voor wie die grens herkent, is er nu een pad dat niet betekent dat je terug naar af moet.