De WhatsApp Business API levert meer data dan de WhatsApp Business-app, maar minder dan de meeste merken denken. Bezorgpercentages, leespercentages en reactiepercentages zijn beschikbaar. Omzettoewijzing, de klantwaarde over de hele relatie in combinatie met WhatsApp-activiteit en vergelijkingen tussen kanalen vragen extra werk bovenop wat de API zelf biedt. Wie weet waar de grens ligt tussen wat de API automatisch rapporteert en wat je zelf moet bouwen, voorkomt de teleurstelling van te hoge verwachtingen en laat geen kansen liggen door te weinig te gebruiken van wat het platform wel biedt.
Wat de WhatsApp Business API zelf rapporteert
De API levert een vaste set gegevens op bericht- en gespreksniveau. Als je precies weet wat er beschikbaar is, bouw je realistische rapportages en reken je niet op functies die het platform niet heeft.
Statusgegevens per bericht
Voor elk bericht dat je via de API verstuurt, geeft WhatsApp in elke fase van de bezorging een statusupdate. Dit zijn de beschikbare statussen:
- Verzonden: het bericht heeft de API verlaten en zit in het bezorgsysteem van WhatsApp
- Bezorgd: het bericht is op het toestel van de ontvanger aangekomen
- Gelezen: de ontvanger heeft het bericht geopend (alleen beschikbaar als de ontvanger leesbevestigingen heeft aanstaan)
- Mislukt: het bericht kon niet worden bezorgd, met een foutcode die de reden aangeeft
Deze statussen komen binnen als webhooks. Dat betekent dat de API de statusupdate direct naar het systeem van het merk stuurt, zonder dat je steeds zelf hoeft op te vragen. Deze webhook-events opvangen en opslaan is de basis van analytics op berichtniveau. Zonder een systeem dat de webhooks ontvangt en logt, is de data weg.
Statistieken op gespreksniveau
Naast de status van losse berichten geeft de API data op gespreksniveau via de analytics-endpoints. Beschikbare statistieken zijn onder meer het aantal gesprekken per categorie (marketing, service-informatie, authenticatie, klantenservice), per periode en per land. Deze data is handig voor kostenbeheer (hoeveel betaalde gesprekken waren er per categorie) en voor het volgen van volumetrends. Over individuele gesprekken geeft ze niets: er is geen endpoint dat de volledige tekst van eerdere gesprekken of de uitkomst van een bepaald gesprek teruggeeft. De inhoud van gesprekken is live beschikbaar via webhooks, maar daarna niet meer op te vragen via de API, tenzij het eigen systeem van het merk de inhoud heeft opgeslagen.
Prestaties van berichtsjablonen
Voor berichtsjablonen die je in uitgaande campagnes gebruikt, geeft de API gebundelde prestatiegegevens: hoe vaak elk sjabloon is verstuurd, bezorgd, gelezen en beantwoord. Deze data is beschikbaar per sjabloon, niet per ontvanger. Je ziet dus hoe een sjabloon over het geheel presteerde, maar niet welke contacten het lazen of beantwoordden. Prestatiedata per sjabloon is onmisbaar om te zien welke berichtvormen en invalshoeken bij je publiek werken, en vormt de basis voor de keuze welke sjablonen je houdt, verbetert of schrapt.
Kwaliteitsscore van het telefoonnummer
De API geeft de kwaliteitsscore van het zakelijke telefoonnummer door. WhatsApp past die score aan op basis van wat klanten doen: blokkeringen, meldingen en uitschrijvingen tellen mee. De score heeft drie niveaus (hoog, gemiddeld, laag) en bepaalt direct de berichtlimieten van het account. Als je de kwaliteitsscore volgt via de API of het dashboard van Business Manager, zie je een verslechtering vroeg en kun je de oorzaak onderzoeken voordat je minder berichten mag versturen. Een daling van hoog naar gemiddeld is een waarschuwing. Bij een daling naar laag moet je meteen actie ondernemen om de oorzaak te vinden en op te lossen.
Wat de API niet rapporteert
Dit zijn de opvallende gaten in de eigen rapportage van de API:
- De inhoud van gesprekken: de tekst van eerdere berichten is na afloop van het gespreksvenster niet meer op te halen via de API, tenzij je die zelf hebt opgeslagen
- Omzettoewijzing: er is geen ingebouwde koppeling tussen een WhatsApp-gesprek en een aankoop die daarna volgt
- Prestaties van medewerkers: reactietijden, oplossingspercentages en kwaliteitsscores per medewerker houdt de API zelf niet bij
- Demografie van het publiek: WhatsApp geeft geen leeftijd, geslacht of locatie van contacten
- Vergelijkingscijfers: de API vertelt je niet hoe je presteert ten opzichte van het branchegemiddelde
Gespreksanalyse: inzicht in de prestaties van je flows
Gebruik je geautomatiseerde gespreksflows (chatbots, welkomstreeksen, kwalificatieflows), dan wil je weten hoe contacten door die flows heen bewegen. Zo zie je waar ze goed werken en waar ze falen.
Voltooiingspercentage van flows
Het voltooiingspercentage van een flow is het aandeel contacten dat een flow startte en het afgesproken eindpunt bereikte zonder halverwege af te haken. Een hoog percentage betekent dat de flow duidelijk, relevant en makkelijk te volgen is. Bij een laag percentage vallen contacten af voordat ze bij de oplossing zijn. Als je het voltooiingspercentage per flow en door de tijd heen volgt, zie je of aanpassingen de flow beter of slechter maakten. Bepaal het eindpunt voordat je de flow bouwt: bij een supportflow kan dat "probleem opgelost" zijn, bij een kwalificatieflow "contact overgedragen aan het verkoopteam".
Uitvalanalyse: waar contacten afhaken
Een uitvalanalyse laat precies zien bij welke stap in een gespreksflow contacten het vaakst afhaken. Veel uitval bij één stap is een betrouwbaar teken dat daar iets misgaat: het bericht is onduidelijk, de getoonde opties passen niet bij wat het contact nodig heeft, de gevraagde reactie kost te veel moeite, of de wachttijd op een antwoord (bij hybride flows) is te lang. De oplossing hangt af van de diagnose. Een onduidelijk bericht herschrijf je. Een menu met verkeerde opties bouw je om. Een te ingewikkelde actie maak je eenvoudiger. Doe de uitvalanalyse voor elke flow na de eerste twee weken live en daarna elke maand. Dan worden je flows steeds beter in plaats van slechter.
Doorverwijspercentage en redenen voor doorverwijzing
Het doorverwijspercentage is het aandeel geautomatiseerde gesprekken waarbij een medewerker het moest overnemen. Een laag percentage is niet automatisch goed: als de chatbot vragen afhandelt die hij zou moeten doorverwijzen (ingewikkelde klachten, waardevolle verkoopgesprekken, gevoelige accountkwesties), schiet de automatisering door. Een hoog percentage betekent dat de automatisering onderpresteert op de situaties waarvoor ze is gebouwd. Het nuttigste gegeven is niet het percentage zelf, maar de reden voor de doorverwijzing. Als je de redenen elke week indeelt in categorieën, zie je in welke situaties de chatbot beter moet worden en welke altijd bij mensen horen te blijven.
Verdeling van reactietijden binnen een gesprek
Bij hybride flows, waarin geautomatiseerde stappen en menselijke reacties elkaar afwisselen, laat het meten van de reactietijd per fase zien waar vertraging ontstaat. Een geautomatiseerde stap van drie seconden en een menselijke stap van 45 minuten in dezelfde flow geven een wisselvallige ervaring. Met de verdeling van reactietijden per stap zie je welke stappen traag zijn, zodat je gericht kunt verbeteren: meer bezetting, betere routering of meer automatisering. Het doel is niet dat elke stap even snel is, want automatisering is van nature sneller dan mensen. Het doel is dat de menselijke stappen niet de snelle service verpesten die de klant in de geautomatiseerde stappen ervoer.
Flows onderling vergelijken
Merken draaien meestal meerdere gespreksflows tegelijk: een welkomstflow voor nieuwe contacten, een flow die supportvragen sorteert, een kwalificatieflow voor verkoopaanvragen en een flow om inactieve contacten terug te halen. Als je voltooiingspercentages, uitvalpatronen en doorverwijspercentages naast elkaar legt, zie je welke flows de meeste aandacht nodig hebben en welke zo goed werken dat je ze kunt kopiëren. Een supportflow met 85 procent voltooiing en een verkoopkwalificatieflow met 40 procent voltooiing laten zien waar je eerst moet verbeteren, voordat je een van beide flows verder opschaalt.
Een complete WhatsApp-analyticsstack opbouwen
De eigen rapportage van de API, gecombineerd met data uit het gesprekkenplatform, het CRM en het webshop- of ordersysteem, geeft een compleet beeld van de prestaties van WhatsApp. Om die stack te bouwen moet je keuzes maken over het vastleggen, opslaan en koppelen van data.
Webhook-events vastleggen en opslaan
De API levert statusupdates van berichten realtime als webhooks. Leg je die events niet vast en sla je ze niet op, dan is de data weg. Een webhook-ontvanger die elk statusevent in een database logt, is de basis van de analyticsstack. Leg in de log minimaal vast: het bericht-ID, het telefoonnummer van de ontvanger, het tijdstip, de status en bij mislukte berichten de foutcode. Deze ruwe log is de bron van waaruit je alle statistieken op berichtniveau berekent. Zonder die log zijn bezorg- en leespercentages alleen beschikbaar via de vooraf samengevatte analytics-endpoints van de API. Die geven overzichten, maar niet de details die je voor een grondige analyse nodig hebt.
WhatsApp-data koppelen aan het CRM
Als je gespreksdata uit WhatsApp koppelt aan contactrecords in het CRM, kun je analyseren per contact: hoeveel gesprekken had een bepaald contact, wat was de uitkomst van elk gesprek en hoe verhoudt de aankoopgeschiedenis zich tot de WhatsApp-activiteit. Daarvoor heb je een vaste identificatie nodig, meestal het telefoonnummer, die in beide systemen staat en waarmee je records aan elkaar koppelt. Zijn de records gekoppeld, dan kun je vragen over beide systemen heen stellen: welke contacten op de WhatsApp-lijst kochten de afgelopen 90 dagen iets, welke contacten voerden een WhatsApp-gesprek maar kochten nog niet, en welke contacten reageren het meest op broadcasts.
Omzet toewijzen via de datastack
Om omzet aan WhatsApp-gesprekken toe te wijzen, heb je een koppeling nodig tussen het gesprek en de aankoop. De schoonste aanpak gebruikt een gesprek-ID dat bij de checkout wordt meegegeven als een verkoop vanuit een WhatsApp-gesprek begint. Zo kun je de aankoop in het ordersysteem als WhatsApp-bron taggen. Is dat technisch niet haalbaar, dan geven vervangende methoden een benadering: unieke kortingscodes per broadcast, betaallinks met UTM-tags of verkoopbronnen die medewerkers in het CRM noteren. Vergelijk de aan WhatsApp toegewezen omzet elke maand met de kosten van het kanaal (API-kosten, tijd van het team, platformkosten). Zo krijg je de ROI-berekening die verdere investering rechtvaardigt.
Analyticsplatforms en dashboards
Ruwe data in databases is niet toegankelijk voor het marketing- of klantenserviceteam zonder een rapportagelaag erbovenop. Er zijn drie opties voor die laag:
- Het analyticsdashboard in het platform van je WhatsApp Business Solution Provider, dat de statistieken toont die de Provider zelf bijhoudt
- Een BI-tool die is gekoppeld aan het datawarehouse waarin de webhook-events en CRM-data staan, voor eigen rapporten en vragen over systemen heen
- Rapportage in spreadsheets voor kleinere organisaties, waarbij je data uit de analytics-endpoints van de API exporteert en handmatig combineert
De juiste keuze hangt af van het datavolume, de technische middelen en hoe vaak de data ververst moet worden. Een grote API-omgeving met duizenden gesprekken per dag heeft een echte BI-tool nodig. Een kleinere organisatie redt zich met geplande exports en een goed opgezette spreadsheet.
Bewaartermijnen en privacyverplichtingen
WhatsApp-gespreksdata in de eigen analyticsstack van een merk valt onder dezelfde privacyverplichtingen als andere klantgegevens. Bewaartermijnen voor gesprekslogs, contactrecords en prestatiedata bepaal je aan de hand van de privacywetgeving in elk land waar je actief bent. Data die je niet meer nodig hebt, verwijder je volgens een vast schema in plaats van haar eindeloos te bewaren. Vraagt een contact om verwijdering van zijn gegevens, dan moet die verwijdering ook de analyticsstack omvatten, naast het CRM en elk ander gekoppeld systeem. Gegevensverwijdering vanaf het begin inbouwen in de analytics-infrastructuur is veel makkelijker vol te houden dan het achteraf toevoegen.
Van data naar beslissingen
Een analyticsstack die data oplevert maar geen beslissingen verandert, is dure infrastructuur zonder rendement. Om WhatsApp-data om te zetten in beslissingen voor de dagelijkse gang van zaken en voor de strategie heb je een vast beoordelingsritme nodig en een duidelijke koppeling tussen signalen in de data en acties.
De wekelijkse datacheck: beslissingen voor de dagelijkse praktijk
De wekelijkse check gaat over statistieken die snel kunnen veranderen en snel aandacht nodig hebben. Vaste wekelijkse controles zijn: bezorg- en leespercentages van de campagnes van die week, de prestaties van nieuw gelanceerde sjablonen, de stand en trend van de kwaliteitsscore, het doorverwijspercentage van geautomatiseerde flows en de gemiddelde eerste reactietijd. Geef elke statistiek een drempel: erboven hoef je niets te doen, eronder volgt een vastgelegd onderzoek met een vaste reactie. De wekelijkse check kost niet meer dan 30 minuten als de rapportage goed is ingericht en de drempels vooraf zijn bepaald.
De maandelijkse strategische check: keuzes over het kanaal
De maandelijkse check gaat over trends, toewijzing van omzet en verdeling van capaciteit. Vaste vragen: groeit het aantal contacten met toestemming volgens plan, ligt de aan WhatsApp toegewezen omzet op koers, welke geautomatiseerde flows presteren onder de maat en wat is het plan om ze te verbeteren, welke doelgroepsegmenten reageren het meest en wat betekent dat voor de targeting, en hoe verhouden de kosten per klant via WhatsApp zich deze maand tot andere kanalen? De maandelijkse check levert drie tot vijf concrete beslissingen of acties op voor de maand erna, elk met een eigenaar bij naam en een vaste einddatum.
A/B-testdata gebruiken om sjablonen en flows te verbeteren
De prestatiedata van sjablonen uit de API is het ruwe materiaal voor systematisch A/B-testen. Je test een variant van een sjabloon, bijvoorbeeld met een andere openingszin, een andere oproep tot actie, een ander verzendmoment of een ander mediatype, en vergelijkt de prestaties van voor en na de wijziging. Zo weet je welke versie beter is. Bij gespreksflows test je een aangepaste stap tegen het origineel en vergelijk je de uitval bij precies die stap. Zo kun je de verbetering meten. Elk testresultaat, of de variant nu won of het origineel standhield, vergroot de kennis over wat werkt bij jouw publiek. Met een testlogboek waarin je elk experiment en de uitkomst noteert, voorkom je dat je dingen opnieuw test die je al hebt geprobeerd.
Analytics koppelen aan content- en campagneplanning
WhatsApp-analytics moeten direct meedoen in de planning van content en campagnes. Sjablonen met hoge reactiepercentages in eerdere campagnes zijn de moeite waard om op voort te bouwen. Onderwerpen die de meeste inkomende gesprekken opleverden, laten zien waar je publiek het meest in geïnteresseerd is. Het moment van verzenden met de beste leespercentages bepaalt wanneer je toekomstige campagnes inplant. Vragen van klanten die steeds terugkomen in supportgesprekken wijzen op ontbrekende content, die je vooraf kunt oplossen in broadcasts of flows. De data is het meest waard als doorlopende feedbacklus, niet los gebruikt: elke volgende campagne wordt er relevanter en beter getimed door dan de vorige.
API-analytics rapporteren aan de directie
Rapportage aan de directie over WhatsApp API-analytics vertaalt technische statistieken naar zakelijke taal. Bezorgpercentages en webhook-vertraging zeggen een beslisser op hoog niveau niets. Omzet die aan WhatsApp is toegewezen, kosten per klant ten opzichte van andere kanalen en tevredenheidscijfers uit enquêtes na een gesprek wel. Een samenvatting van één pagina per maand met drie tot vijf zakelijke statistieken, met trendindicatoren die laten zien of elke waarde steeg of daalde ten opzichte van vorige maand, geeft de directie wat ze nodig heeft om de prestaties van het kanaal te beoordelen, zonder dat ze hoeft te weten hoe de API werkt. Het doel is een rapport dat duidelijk maakt of de investering in WhatsApp iets oplevert, en wat er gebeurt om de prestaties te verbeteren waar dat niet zo is.
We gebruiken een WhatsApp Business Solution Provider. Regelt die de analytics voor ons, of moeten we zelf iets bouwen?
De meeste platforms van Solution Providers hebben een ingebouwd analyticsdashboard met de statistieken die ze zelf bijhouden: bezorg- en leespercentages van berichten, aantallen gesprekken per categorie, prestaties van sjablonen en soms voltooiingspercentages van flows. Dat is genoeg om de dagelijkse gang van zaken te volgen. De analytics van de Provider schieten tekort bij rapportage over systemen heen: WhatsApp-data koppelen aan CRM-records, omzet toewijzen aan specifieke gesprekken of de prestaties van WhatsApp vergelijken met andere kanalen. Daarvoor moet je de data van de Provider exporteren en combineren met data uit andere systemen, handmatig of met een BI-tool. Kijk wat het analyticsdashboard van je Provider dekt voordat je besluit of je extra rapportage-infrastructuur gaat bouwen.
Ons leespercentage daalt al drie maanden gestaag. Wat moeten we onderzoeken?
Een dalend leespercentage heeft meestal een van drie oorzaken. Ten eerste raakt het publiek minder betrokken: contacten die zich een tijd geleden aanmeldden en WhatsApp niet meer actief gebruiken, of die het nummer van het merk hebben maar niet meer geïnteresseerd zijn. Ten tweede ontvangen contacten wel berichten maar slaan ze het nummer niet op. Daardoor voelt het bericht minder persoonlijk en is er minder reden om het te openen. Ten derde is de berichtfrequentie zo hoog geworden dat contacten de berichten van het merk minder belangrijk gaan vinden. Controleer de lijst op contacten die de afgelopen 60 dagen geen bericht hebben gelezen, kijk of recente aanmelders het nummer hebben opgeslagen en ga na of de frequentie is veranderd in de periode van de daling.
Hoe zien we welke contacten op een broadcast hebben gereageerd, zonder elk gesprek handmatig na te lopen?
Via het webhooksysteem van de API. Als een contact reageert op een bericht dat deel was van een broadcast, bevat de webhook van het inkomende bericht het bericht-ID van het oorspronkelijke broadcastbericht. Sla je broadcastverzendingen op met hun bericht-ID's en log je inkomende berichten met het ID van het bericht waarop ze reageren, dan kun je in die data opvragen welke contacten op een bepaalde broadcast hebben gereageerd. Daarvoor heb je een webhook-ontvanger en een database nodig om de events op te slaan. Zonder die infrastructuur moet je reacties handmatig volgen via het gesprekkenplatform, en dat is op grote schaal niet haalbaar.
We willen weten welke gespreksflow de meeste uitval heeft. Hoe vinden we dat zonder hulp van een ontwikkelaar?
De meeste WhatsApp-chatbotplatforms hebben flowanalytics in het dashboard, die laten zien hoeveel contacten elke stap van een flow bereikten en hoeveel er doorgingen naar de volgende stap. Met dit trechteroverzicht per stap zie je de uitval zonder eigen analyse. Biedt het platform dit niet, kijk dan of je gespreksdata kunt exporteren: in een spreadsheet met gesprekken en hun uitkomsten kun je zien welke stap als laatste werd bereikt voordat iemand afhaakte. Heb je geen van beide, vraag dan aan de Solution Provider welke flowanalytics er in het platform zitten. Dat is de snelste manier om te weten wat mogelijk is zonder extra ontwikkeling.
Onze WhatsApp-analytics zitten verspreid over drie platforms: het dashboard van de Solution Provider, ons CRM en ons webshopsysteem. Hoe voegen we ze samen?
De opties lopen uiteen van eenvoudig tot complex, afhankelijk van je technische middelen. De eenvoudigste aanpak is een maandelijkse handmatige export uit elk systeem naar een gedeelde spreadsheet, die één persoon bijhoudt en die jullie samen bekijken. Een steviger aanpak gebruikt een tool voor data-integratie die volgens schema data uit de API van elk systeem ophaalt en in een centrale database laadt, waarop je één dashboard bouwt. De handmatige aanpak werkt op kleine schaal. De geautomatiseerde aanpak is nodig als het datavolume of de frequentie van de controle handmatig samenvoegen onwerkbaar maakt. Begin eenvoudig en stap over op automatisering zodra het handmatige proces de bottleneck wordt.
Hoe berekenen we de ROI van onze WhatsApp-aanpak om verdere investering te rechtvaardigen?
Voor ROI heb je twee getallen nodig: wat WhatsApp kostte en wat het opleverde. Aan de kostenkant: API-kosten, platformkosten van de Solution Provider, de tijd van medewerkers die aan WhatsApp wordt besteed (geschat in uren maal een uurtarief) en eventuele kosten voor tools of ontwikkeling. Aan de opbrengstenkant: verkopen die direct aan WhatsApp-gesprekken zijn toegewezen, omzet uit behoud van klanten die via WhatsApp opnieuw zijn bereikt, en besparingen op supportkosten door vragen die via WhatsApp zijn opgelost en anders een duurder kanaal hadden gevraagd (telefoon, persoonlijk contact). De toewijzing is lastiger precies te maken, maar zelfs een voorzichtige schatting van de toegewezen omzet naast de volledige kosten geeft genoeg beeld voor een onderbouwd investeringsvoorstel.