Hulp nodig bij deze handleiding?Vraag het DripTell-team
Een betrouwbaar WhatsApp campagnerapport begint met één record voor elk uitgaand bericht aan een ontvanger. Daarna koppel je elk statusevent via het bericht ID aan dat record. Bewaar de eventtijd en de ruwe foutdetails. Bepaal de nieuwste status niet met de volgorde waarin webhooks bij jouw systeem aankwamen, want Meta waarschuwt dat die volgorde van de echte events kan afwijken.
De operationele vraag is eenvoudig. Kan het team uitleggen wat er met ieder bedoeld bericht is gebeurd zonder het bewijs na afloop te herschrijven? Een campagnewerkruimte moet dat zichtbaar maken en niet alleen een paar mooie totalen tonen.
De WhatsApp webhookreferentie van Meta noemt sent het ontvangen door de WhatsApp server, delivered het bezorgen bij de ontvanger, read het lezen en failed een mislukte verzending. Dat zijn verschillende gebeurtenissen.
Begin met één record per bericht
Maak het rapportrecord zodra een uitgaande poging in je verzendproces is geaccepteerd. Bewaar campagne, bedoelde ontvanger, sjabloon of berichttype, tijd van de poging en het WhatsApp bericht ID. Meta documenteert dat berichten unieke ID's hebben en via webhooks te volgen zijn.
Houd je eigen doelgroepbesluit apart van het platformresultaat. Een contact dat vóór indiening wordt uitgesloten wegens toestemming, suppressie, duplicatie of een doelgroepregel is niet bij WhatsApp mislukt. Het is nooit ingediend. Een goed WhatsApp campagneproces toont daarom aangevraagde doelgroep, geschikte doelgroep en ingediende berichten als losse aantallen.
Voeg herhaalde pogingen niet samen. Koppel een gerechtvaardigde nieuwe poging aan dezelfde campagne en ontvanger, maar geef haar een eigen bericht ID. Anders kan één latere bezorging een eerdere fout verbergen en de eerste poging beter laten lijken.
Bewaar de ruwe statusevents
Voeg events toe aan een log in plaats van één statusveld te overschrijven. Sla bericht ID, status, Meta eventtijd, ontvangsttijd en een eventueel foutobject bij failed op. Met het ruwe log kun je het rapport opnieuw opbouwen wanneer een webhook vertraagd of dubbel binnenkomt.
- 1Bewaar het bericht IDKoppel elke poging voor een ontvanger aan het ID dat voor dat bericht terugkomt.
- 2Sla ieder event opBewaar ruwe status, eventtijd en foutdetails zonder eerder bewijs te overschrijven.
- 3Orden op eventtijdGebruik de tijd in de status omdat webhooks in een andere volgorde kunnen aankomen.
- 4Stem totalen afVergelijk doelgroep, geaccepteerde berichten en eindstatussen met benoemde noemers.
- 5Bekijk uitzonderingenOnderzoek ontbrekende en mislukte records vóór een contactwijziging of nieuwe poging.
Maak de verwerking idempotent. Hetzelfde event mag bij herhaling de teller niet nogmaals verhogen. Een bruikbare sleutel combineert bericht ID, status en eventtijd, terwijl een checksum van de oorspronkelijke payload het auditspoor bewaart. Beveilig toegang via je model voor beveiliging en rechten.
De documentatie van Meta over statusupdates zegt dat succesvolle berichten meldingen voor sent, delivered en read opleveren. Ook staat er dat hun aankomstvolgorde in je app niet de echte timing hoeft te volgen. De tijdstempel hoort dus bij het bewijs.
Stem af op de eventtijd
Sorteer events per bericht met de tijd in de statusmelding. Bewaar ontvangsttijd om vertraging in de webhookverwerking te vinden, maar laat die volgorde een bericht niet terugzetten. Komt read eerder in de database dan delivered, bewaar dan beide en toon de chronologie van hun tijdstempels.
Kies een duidelijke rapportgrens. Een live rapport kan voorlopig blijven zolang events binnenkomen. Later kun je een gedateerde momentopname vastzetten zonder late events te verwijderen. Wijzigt een laat event de eindstatus, noteer dan de revisietijd zodat verschillen tussen exports verklaarbaar blijven.
| Bewijs in het rapport | Wat het bewijst | Wat het niet bewijst |
|---|---|---|
| Uitgaand verzoek met bericht ID | WhatsApp gaf het bericht een ID | Bezorging op het apparaat |
| Status sent | De WhatsApp server ontving het bericht | Bezorging of lezen |
| Status delivered | Het bericht bereikte de ontvanger | Begrip of actie van de ontvanger |
| Status read | Er is een leesevent gemeld | Een antwoord of verkoop door de campagne |
| Status failed met fout | De verzending mislukte met vastgelegde details | Dezelfde oorzaak bij elke ontvanger |
| Geen later event op de grens | Het rapport heeft nog geen nieuwer event | Dat je delivered of failed mag aannemen |
Geef iedere verhouding een noemer
Een percentage heeft een benoemde noemer nodig. Bezorging onder ingediende berichten beantwoordt een transportvraag. Reads onder bezorgde berichten beschrijven geregistreerd lezen van wat aankwam. Geen van beide vertelt hoeveel contacten geschikt waren of welk klantresultaat ontstond.
Publiceer aantallen naast percentages. Anders is niet zichtbaar of de doelgroep kromp, uitsluitingen veranderden of late events de noemer verschoven. Toon ook tijdzone en rapportgrens. Een campagne na twaalf uur vergelijken met een campagne na drie dagen is niet eerlijk.
Antwoorden, afspraken en aankopen horen in een aparte uitkomstlaag. Koppel ze via een verdedigbaar campagne of gesprek ID en behandel read niet als conversie. Een gedeelde inbox bewaart het gesprek na bezorging, terwijl automatiseringsregels het werk kunnen routeren. Het statuslog blijft transportbewijs.
Onderzoek fouten zonder historie te wijzigen
Een failed status kan een foutobject bevatten. Bewaar dit, groepeer fouten op de geregistreerde code of details en bekijk een kleine steekproef voordat je handelt. Soms moet een sjabloon of instelling worden hersteld, soms contactdata of suppressie. Een algemene retry kan hetzelfde probleem herhalen.
Zet records zonder vervolgstatus in een aparte uitzonderingswachtrij. Controleer eerst het bericht ID, het webhookabonnement van het juiste WhatsApp Business Account en of je endpoint meldingen aannam. Bekijk daarna verwerking en deduplicatie. Verander onbekend niet stilletjes in sent, delivered of failed om de totalen passend te maken.
Wijs iedere uitzonderingsgroep toe. De campagnemanager kan de doelgroepregels bezitten, een engineer de webhookgaten en klantoperaties de antwoorden. Zo leidt het rapport tot actie zonder de bronhistorie aan te passen.
Maak van het rapport een beslissing
Voer de afstemming uit vóór de beoordeling van creatieve prestaties. Vraag eerst of ieder ingediend bericht een verklaarbare status of open uitzondering heeft. Bekijk daarna foutclusters, eventvertraging en verschillen tussen segmenten. Interpreteer reads, antwoorden en resultaten pas wanneer het transportbewijs stabiel is.
DripTell kan campagneactiviteit, ondersteunde gesprekshistorie en eigenaarschap in één operationeel beeld brengen. Neem één recente campagne en stem de records af met de samenvatting. Zijn de totalen niet uit te leggen, herstel dan de rapportregel vóór de volgende grote send. Gebruik de echte campagne als test in een DripTell demonstratie.
Veelgestelde vragen
Wat is het verschil tussen sent en delivered
Sent betekent dat de WhatsApp server het bericht ontving. Delivered betekent dat het de ontvanger bereikte. Gebruik delivered voor de vraag of het platform bezorging meldde.
Wat als statuswebhooks niet op volgorde aankomen
Bewaar alle events en orden ze op de tijdstempel in de statusmelding. Houd ontvangsttijd apart voor monitoring, maar laat aankomstvolgorde geen later feit wissen.
Moet failed automatisch opnieuw worden geprobeerd
Niet als algemene regel. Bewaar de fout, groepeer oorzaken en herstel eerst het probleem. Een retry is een nieuwe gekoppelde poging met een eigen bericht ID.
DripTell Editorial
Praktische uitleg, gecontroleerd door het product- en klantworkflowteam van DripTell.
Lees hoe DripTell productclaims controleert, primaire bronnen gebruikt en correcties verwerkt.
Redactioneel en bronnenbeleid