WhatsApp Business API: analyse og rapportering

Se, hvilke analyser WhatsApp Business API giver som standard, hvad der skal bygges oven på, hvordan du analyserer samtaleforløb, og gør data til beslutninger.

Kladde

WhatsApp Business API giver flere data end WhatsApp Business-appen, men færre, end de fleste brands tror. Leveringsrater, læserater og svarrater er tilgængelige. Omsætningsattribution, kundens livstidsværdi knyttet til WhatsApp-aktivitet og sammenligninger af ydeevne på tværs af kanaler kræver ekstra arbejde ud over det, API'en leverer som standard. Når du forstår grænsen mellem det, API'en rapporterer automatisk, og det, der skal bygges oven på, undgår du skuffelsen over at forvente mere, end platformen giver, og du undgår at gå glip af det, den faktisk giver.

Hvad WhatsApp Business API rapporterer som standard

API'en giver et fast sæt datapunkter på besked- og samtaleniveau. Når du ved præcis, hvad der er tilgængeligt, kan du bygge realistisk rapportering uden at regne med funktioner, der ikke findes i platformen.

Statusdata på beskedniveau

For hver besked, der sendes gennem API'en, returnerer WhatsApp en statusopdatering på hvert trin i leveringen. De tilgængelige statusser er:

  • Sendt: beskeden har forladt API'en og ligger i WhatsApps leveringssystem
  • Leveret: beskeden er nået frem til modtagerens enhed
  • Læst: modtageren har åbnet beskeden (kun tilgængelig, når modtageren har læsekvitteringer slået til)
  • Mislykket: beskeden kunne ikke leveres, med en fejlkode, der angiver årsagen

Disse statusser returneres som webhooks, hvilket betyder, at API'en sender statusopdateringen til brandets system i realtid i stedet for at kræve en forespørgsel. At opfange og gemme disse webhook-hændelser er grundlaget for analyse på beskedniveau. Uden et system, der modtager og logger webhooks, går dataene tabt.

Målinger på samtaleniveau

Ud over de enkelte beskeders status giver API'en data på samtaleniveau gennem sine analyseendepunkter. Tilgængelige målinger omfatter antal samtaler pr. kategori (marketing, utility, godkendelse og service), pr. tidsperiode og pr. land. Disse data er nyttige til omkostningsstyring (hvor mange betalte samtaler var der i hver kategori) og til analyse af volumentendenser. De giver ikke data om enkelte samtaler: Der er intet API-endepunkt, der returnerer den fulde tekst fra tidligere samtaler eller udfaldet af en bestemt udveksling. Samtaleindhold er tilgængeligt i realtid via webhooks, men gemmes ikke og kan ikke hentes via API'en bagefter, medmindre brandets eget system fanger det.

Målinger for skabelonernes ydeevne

For beskedskabeloner, der bruges i udgående kampagner, giver API'en samlede ydeevnedata: hvor mange gange hver skabelon blev sendt, leveret, læst og besvaret. Disse data findes på skabelonniveau, ikke på niveau med den enkelte modtager. De fortæller, hvordan en skabelon klarede sig samlet set, men ikke hvilke bestemte kontakter der læste eller svarede på den. Data om skabelonernes ydeevne er afgørende for at finde ud af, hvilke beskedformater og indholdstilgange der virker i målgruppen, og de er grundlaget for at beslutte, hvilke skabeloner du beholder, optimerer eller dropper.

Kvalitetsvurdering af telefonnummer

API'en viser kvalitetsvurderingen af virksomhedens telefonnummer, som WhatsApp opdaterer ud fra kundernes interaktioner: Blokeringer, anmeldelser og framelding indgår i vurderingen. Vurderingen har tre niveauer (høj, middel, lav) og påvirker direkte de beskedgrænser, der gælder for kontoen. Når du overvåger kvalitetsvurderingen via API'en eller Business Manager-dashboardet, kan du opdage faldende kvalitet tidligt og finde årsagen, før det giver lavere beskedkapacitet. Et fald fra høj til middel er en advarsel. Et fald til lav kræver øjeblikkelig handling for at finde og rette grundårsagen.

Hvad API'en ikke rapporterer

Bemærkelsesværdige huller i API'ens standardrapportering er:

  • Samtaleindhold: tidligere beskedtekst kan ikke hentes via API'en, når samtalevinduet er lukket, medmindre den er gemt separat
  • Omsætningsattribution: der er ingen indbygget forbindelse mellem en WhatsApp-samtale og et efterfølgende køb
  • Medarbejdernes præstation: de enkelte medarbejderes svartider, løsningsrater og kvalitetsscorer registreres ikke af API'en selv
  • Målgruppens demografi: WhatsApp giver ikke alder, køn eller lokation på kontakter
  • Sammenlignende benchmarks: API'en fortæller ikke, hvordan din ydeevne ligger i forhold til branchens gennemsnit

Samtaleanalyse: forstå, hvordan forløb klarer sig

For brands, der kører automatiserede samtaleforløb (chatbots, velkomstsekvenser, kvalificeringsforløb), er det afgørende at forstå, hvordan kontakter bevæger sig gennem forløbene, for at se, hvor de virker, og hvor de fejler.

Gennemførselsrater for forløb

Gennemførselsraten er andelen af kontakter, der startede et samtaleforløb og nåede det definerede slutpunkt uden at hoppe fra undervejs. En høj gennemførselsrate viser, at forløbet er klart, relevant og nemt at følge. En lav rate betyder, at kontakter falder fra, før de når en løsning. Når du følger gennemførselsraten pr. forløb og over tid, kan du se, om ændringer i forløbet forbedrede eller forværrede resultatet. Slutpunktet bør defineres, før forløbet bygges: For et supportforløb kunne det være "problem løst". For et kvalificeringsforløb kunne det være "kontakt overdraget til salgsteamet".

Analyse af frafald: hvor kontakter hopper fra

Frafaldsanalysen viser præcis, hvilket trin i et samtaleforløb kontakter oftest forlader. Højt frafald på et bestemt trin er et pålideligt tegn på, at noget er galt netop der: Beskeden er uklar, de viste valgmuligheder matcher ikke det, kontakten har brug for, det krævede svar er for besværligt, eller ventetiden på et svar (i hybride forløb) er for lang. Løsningen afhænger af diagnosen. En uklar besked skal skrives om. En menu med de forkerte valgmuligheder skal omstruktureres. Et for kompliceret handlingskrav skal forenkles. Hvis du kører frafaldsanalyse på hvert forløb efter de første to uger live og derefter hver måned, bliver forløbene ved med at blive bedre i stedet for at forfalde over tid.

Eskaleringsrate og årsager til eskalering

Eskaleringsraten er andelen af automatiserede samtaler, hvor en menneskelig medarbejder skulle overtage. En lav eskaleringsrate er ikke automatisk god: Hvis chatbotten håndterer henvendelser, den burde eskalere (komplekse klager, salgssamtaler af høj værdi, følsomme kontosager), betyder en lav rate, at automatiseringen rækker for langt. En høj eskaleringsrate betyder, at automatiseringen yder for dårligt i de situationer, den er bygget til. Det mest nyttige datapunkt er ikke selve raten, men årsagerne til eskalering. Hvis du kategoriserer årsagerne hver uge, kan du se, hvilke situationer chatbotten skal blive bedre til, og hvilke der for altid skal blive hos mennesker.

Fordeling af svartid gennem samtalen

I hybride forløb, hvor automatiske trin skifter med menneskelige svar, viser måling af svartiden på hvert trin, hvor forsinkelserne opstår. Et automatisk trin, der tager tre sekunder, og et menneskeligt trin, der tager 45 minutter, i samme forløb giver en uens oplevelse. Fordelingen af svartid pr. trin viser, hvilke trin der er langsomme, så du kan målrette forbedringer af bemanding, routing eller automatiseringsdækning. Målet er ikke ens svartid på alle trin (automatisering er hurtigere end mennesker af natur), men at sikre, at de menneskelige trin ikke skaber forsinkelser, der ødelægger den hurtighed, kunden oplevede i de automatiske trin.

Sammenligning af forløb på tværs

Brands kører typisk flere samtaleforløb samtidig: et velkomstforløb til nye kontakter, et supportforløb til indgående henvendelser, et kvalificeringsforløb til salgsforespørgsler og et genaktiveringsforløb til inaktive kontakter. Når du sammenligner gennemførselsrater, frafaldsmønstre og eskaleringsrater på tværs af forløb, ser du, hvilke forløb der kræver mest opmærksomhed, og hvilke der yder så godt, at de er værd at kopiere. Et supportforløb med 85 procent gennemførelse og et salgskvalificeringsforløb med 40 procent gennemførelse viser, hvor du skal lægge forbedringsindsatsen, før et af forløbene skaleres op.

Sådan bygger du en komplet WhatsApp-analysestak

API'ens standardrapportering kombineret med data fra samtaleplatformen, CRM-systemet og webshoppen eller ordresystemet giver et komplet billede af WhatsApp-ydeevnen. At bygge denne stak kræver beslutninger om dataopsamling, lagring og integration.

Opfang og lagring af webhook-hændelser

API'en leverer beskedstatusser som webhooks i realtid. Hvis disse hændelser ikke opfanges og gemmes, går dataene tabt. En webhook-modtager, der logger hver statushændelse i en database, er grundlaget for analysestakken. Loggen bør som minimum registrere beskedens ID, modtagerens telefonnummer, tidsstemplet, status og eventuel fejlkode for mislykkede beskeder. Denne rålog er sandhedskilden, som alle målinger på beskedniveau beregnes ud fra. Uden den er lever- og læserater kun tilgængelige gennem API'ens forhåndsaggregerede analyseendepunkter, som giver sammendrag, men ikke de detaljerede data, der skal til for en grundig analyse.

Kobling af WhatsApp-data til CRM-systemet

Når du kobler WhatsApp-samtaledata til kontaktposter i CRM-systemet, får du grundlaget for analyse på kontaktniveau: Hvor mange samtaler har en bestemt kontakt haft, hvad blev udfaldet af hver af dem, og hvordan ser kontaktens købshistorik ud i forhold til engagementet på WhatsApp. Koblingen kræver en fast identifikator, typisk telefonnummeret, som findes i begge systemer og gør det muligt at matche poster. Når posterne er matchet, kan du lave forespørgsler på tværs af systemer: Hvilke kontakter på WhatsApp-listen har også købt inden for de seneste 90 dage, hvilke kontakter har haft en WhatsApp-samtale, men ikke er konverteret endnu, og hvilke kontakter har den højeste engagementsrate på udsendelser.

Omsætningsattribution gennem datastakken

For at tilskrive omsætning til WhatsApp-samtaler skal der være en kobling mellem samtalehændelsen og købshændelsen. Den reneste løsning bruger et samtale-ID, som sendes videre til kassen, når et salg startes fra en WhatsApp-samtale, så købet kan mærkes med WhatsApp som kilde i ordresystemet. Hvor det ikke er teknisk muligt, giver erstatningsmetoder en tilnærmelse: unikke rabatkoder pr. udsendelse, betalingslinks med UTM-mærkning og kilder til salg, som medarbejdere logger i CRM-systemet. Hvis du hver måned gennemgår den omsætning, der tilskrives WhatsApp, op imod omkostningerne ved at drive kanalen (API-gebyrer, teamets tid, platformsomkostninger), får du den ROI-beregning, der retfærdiggør fortsat investering.

Analyseplatforme og dashboards

Rå data i databaser er ikke tilgængelige for marketing- eller kundeoplevelsesteamet uden et rapporteringslag ovenpå. Muligheder for at bygge et rapporteringslag er:

  • Det analysedashboard, der er indbygget i WhatsApp Business-løsningsudbyderens platform, og som dækker de målinger, udbyderen følger
  • Et business intelligence-værktøj koblet til det datalager, hvor webhook-hændelser og CRM-data ligger, så du kan lave egne rapporter og forespørgsler på tværs af systemer
  • Rapportering i regneark til mindre virksomheder, hvor data eksporteres fra API'ens analyseendepunkter og samles manuelt

Det rigtige valg afhænger af datamængden, de tekniske ressourcer og hvor ofte data skal opdateres. En stor API-drift med tusindvis af samtaler om dagen har brug for et ordentligt BI-værktøj. En mindre virksomhed kan klare sig med planlagte eksporter og et velstruktureret regneark.

Dataopbevaring og privatlivsforpligtelser

WhatsApp-samtaledata, der gemmes i et brands egen analysestak, er underlagt de samme privatlivsforpligtelser som andre kundedata. Opbevaringsperioder for samtalelogs, kontaktposter og ydeevnedata bør fastsættes ud fra den gældende privatlivslovgivning i hvert marked, du opererer i. Data, der ikke længere er nødvendige, bør slettes efter en fast plan i stedet for at blive opbevaret på ubestemt tid. Når en kontakt beder om at få sine data slettet, skal sletningen dække analysestakken lige så vel som CRM-systemet og alle andre tilsluttede systemer. Det er markant nemmere at vedligeholde, hvis du bygger datasletning ind i analyseinfrastrukturen fra starten i stedet for bagefter.

Sådan bliver data til beslutninger

En analysestak, der producerer data, men ikke ændrer beslutninger, er dyr infrastruktur uden afkast. Når du skal omsætte WhatsApp-analysedata til operationelle og strategiske beslutninger, har du brug for en fast gennemgangsrytme og en klar kobling mellem datasignaler og handlinger.

Den ugentlige datagennemgang: operationelle beslutninger

Den ugentlige gennemgang dækker de målinger, der kan ændre sig hurtigt og kræver hurtig opmærksomhed. Vigtige ugentlige kontroller er: lever- og læserater for ugens kampagner, skabelonernes ydeevne for nye skabeloner, status og tendens for kvalitetsvurderingen, eskaleringsrate på automatiserede forløb og gennemsnitlig første svartid. Hver måling bør have en tærskel: over tærsklen kræver ingen handling, under tærsklen udløser en fastlagt undersøgelse og reaktion. Den ugentlige gennemgang bør højst tage 30 minutter, hvis rapporteringen er sat rigtigt op, og tærsklerne er defineret på forhånd.

Den månedlige strategiske gennemgang: kanalbeslutninger

Den månedlige gennemgang dækker tendenser, attribution og fordeling af ressourcer. Vigtige månedlige spørgsmål: Vokser målgruppen med tilmeldte i det ønskede tempo, følger WhatsApp-omsætningen målet, hvilke automatiserede forløb yder dårligt, og hvad er planen for at forbedre dem, hvilke målgruppesegmenter giver de højeste svarrater, og hvad betyder det for målretningen, og hvordan ligger WhatsApp-prisen pr. erhvervelse i forhold til andre kanaler denne måned? Resultatet af den månedlige gennemgang bør være tre til fem konkrete beslutninger eller handlinger for den kommende måned, hver med en navngiven ansvarlig og en fast færdigdato.

Brug A/B-testdata til at forbedre skabeloner og forløb

Data om skabelonernes ydeevne fra API'en er råstoffet til systematisk A/B-test. Når du tester en skabelonvariant (ændret åbningslinje, handlingsopfordring, sendetidspunkt eller medietype) og sammenligner ydeevnedata før og efter ændringen, får du belæg for, hvilken version der er bedst. For samtaleforløb kan du teste et revideret trin mod originalen og sammenligne frafaldet på netop det trin, så forbedringen kan måles. Hvert testresultat, uanset om varianten vandt, eller originalen holdt, øger den viden, I har om, hvad der virker for netop jeres målgruppe. Hvis du fører en testlog over hvert eksperiment og dets resultat, undgår du at teste det samme igen.

Kobling af analyse til indholds- og kampagneplanlægning

WhatsApp-analysedata bør indgå direkte i planlægningen af indhold og kampagner. Skabeloner med høje svarrater i tidligere kampagner er værd at bygge videre på. Emner, der gav flest indgående samtaler, viser, hvad målgruppen er mest interesseret i. Kampagnetidspunkter, der gav de bedste læserater, siger noget om, hvornår fremtidige kampagner bør planlægges. Kundespørgsmål, der gik igen i supportsamtaler, peger på indholdshuller, som kan løses proaktivt i udsendelser eller forløb. Analysedata er mest værdifulde ikke isoleret, men som en løbende feedbackloop, der gør hver ny kampagne mere relevant og bedre timet end den forrige.

Rapportering af API-analyse til ledelsen

Ledelsesrapportering om WhatsApp API-analyse bør oversætte tekniske målinger til forretningssprog. Leveringsrater og webhook-latens er ikke relevante for en øverste beslutningstager. Omsætning tilskrevet WhatsApp, pris pr. erhvervelse sammenlignet med andre kanaler og kundetilfredshedsscorer fra undersøgelser efter samtaler er det. Et månedligt resumé på én side, der dækker tre til fem målinger på forretningsniveau med tendensindikatorer, der viser, om hver måling er forbedret eller faldet siden forrige måned, giver ledelsen den information, de skal bruge til at vurdere kanalens ydeevne, uden at de behøver forstå, hvordan API'en virker. Målet er en rapport, der gør det klart, om investeringen i WhatsApp giver afkast, og hvad der gøres for at forbedre resultatet, hvor det ikke gør.

Vi bruger en WhatsApp Business-løsningsudbyder. Klarer den analysen for os, eller skal vi bygge vores egen?

De fleste udbyderplatforme har et indbygget analysedashboard, der dækker de målinger, de følger: lever- og læserater, antal samtaler pr. kategori, skabelonernes ydeevne og somme tider gennemførselsrater for forløb. Det er nok til operationel overvågning. Hvor udbyderens analyser kommer til kort, er rapportering på tværs af systemer: at koble WhatsApp-data til CRM-poster, tilskrive omsætning til bestemte samtaler eller sammenligne WhatsApp med andre kanaler. Til det skal udbyderens data eksporteres og kombineres med data fra andre systemer, enten manuelt eller gennem et BI-værktøj. Tjek, hvad din udbyders analysedashboard dækker, før du beslutter, om du skal bygge ekstra rapporteringsinfrastruktur.

Vores læserate er faldet støt de seneste tre måneder. Hvad skal vi undersøge?

Faldende læserate har typisk en af tre årsager. For det første bliver målgruppen mindre engageret: kontakter, der tilmeldte sig for noget tid siden og ikke længere bruger WhatsApp aktivt, eller som har brandets nummer, men ikke længere er interesserede. For det andet modtager kontakter beskeder, men gemmer ikke nummeret, hvilket mindsker den personlige følelse og lysten til at åbne dem. For det tredje er beskedfrekvensen steget så meget, at kontakter nedprioriterer brandets beskeder. Gennemgå listen for kontakter, der ikke har læst en besked de seneste 60 dage, tjek, om de seneste tilmeldte har gemt nummeret, og se, om frekvensen har ændret sig i den periode, hvor raten faldt.

Hvordan kan vi følge, hvilke bestemte kontakter der svarede på en udsendelse, uden manuelt at gennemgå hver samtale?

Gennem API'ens webhook-system. Når en kontakt svarer på en besked, der var en del af en udsendelse, indeholder webhooken for den indgående besked ID'et på den oprindelige udsendelsesbesked. Hvis dit system gemmer udsendelser med deres besked-ID'er og logger indgående beskeder med ID'et på den besked, de svarer på, kan du forespørge disse data og se præcis, hvilke kontakter der svarede på en bestemt udsendelse. Det kræver en webhook-modtager og en database til at gemme hændelserne. Uden denne infrastruktur skal svarsporing gøres manuelt via samtaleplatformen, hvilket ikke er praktisk i stor skala.

Vi vil gerne vide, hvilket af vores samtaleforløb der har det højeste frafald. Hvordan finder vi det uden udviklerhjælp?

De fleste WhatsApp-chatbotplatforme har forløbsanalyse i deres dashboard, der viser, hvor mange kontakter der kom ind på hvert trin i et forløb, og hvor mange der gik videre til næste trin. Denne tragtvisning på trinniveau gør frafaldet synligt uden særlig analyse. Hvis platformen ikke har det som standard, så tjek, om den tillader eksport af samtaledata: Et regneark med samtaler og deres udfald kan analyseres for at finde det sidste trin, kontakten nåede, før den hoppede fra. For brands uden adgang til nogen af delene er det hurtigste at spørge løsningsudbyderen, hvilke forløbsanalyser platformen tilbyder, så du ved, hvad der er muligt uden ekstra udvikling.

Vores WhatsApp-analyser er spredt på tre platforme: udbyderens dashboard, vores CRM og vores webshop. Hvordan samler vi dem?

Mulighederne spænder fra enkle til komplekse, afhængigt af de tekniske ressourcer. Den enkleste måde er en månedlig manuel eksport fra hvert system til et fælles regneark, som én person vedligeholder, og som I gennemgår sammen. En mere robust måde bruger et dataintegrationsværktøj, der henter data fra hvert systems API efter en plan og lægger dem i en central database, hvor du bygger ét samlet dashboard. Den manuelle metode virker i lille skala. Den automatiserede er nødvendig, når datamængden eller hyppigheden af gennemgangen gør manuel samling upraktisk. Start enkelt og gå over til automatisering, når den manuelle proces bliver flaskehalsen.

Hvordan beregner vi ROI på vores WhatsApp-drift, så vi kan retfærdiggøre fortsat investering?

ROI kræver to tal: hvad WhatsApp kostede, og hvad det gav. På omkostningssiden: API-gebyrer, gebyrer til løsningsudbyderens platform, medarbejdertid afsat til WhatsApp (anslået som timer ganget med en timesats) og eventuelle omkostninger til værktøjer eller udvikling. På indtægtssiden: salg, der direkte er tilskrevet WhatsApp-samtaler, fastholdelsesomsætning fra kunder, der blev genaktiveret via WhatsApp, og besparelser i support fra henvendelser, der blev løst via WhatsApp, og som ellers ville have krævet en dyrere kanal (telefon, personligt fremmøde). Attributionen er sværere at gøre præcis, men selv et forsigtigt skøn over tilskrevet omsætning sammenlignet med de fulde omkostninger giver nok af et billede til at lave en holdbar investeringsbegrundelse.

Brug det med det samme
på din egen hjemmeside.

Start gratis med WEMASY, og byg din side på få minutter.