Hoe meet ik annuleringen van hotelboekingen in GA4?

GA4 registreert een directe hotelboeking doorgaans als een purchase-event. Wordt die boeking later geannuleerd, dan verdwijnt de oorspronkelijke aankoop niet automatisch uit GA4. Zonder terugkoppeling blijven omzet en boekingen dus te hoog staan. Dat vertekent vooral de beoordeling van campagnes en kanalen met relatief veel annuleringen. Wij lossen dit op door iedere annulering vanuit het boekingssysteem aan het oorspronkelijke transaction_id te koppelen en als refund naar GA4 te sturen.

Waarom GA4 annuleringen niet automatisch verwerkt

Een annulering vindt vaak dagen of weken na de boeking plaats. De gast hoeft daarbij niet opnieuw op de hotelwebsite te komen. Een normale webtag kan de wijziging daardoor niet waarnemen. Het property management system, central reservation system of de booking engine kent de actuele boekingsstatus wel. Dat systeem moet daarom de bron zijn voor de terugkoppeling.

GA4 gebruikt voor terugbetalingen het aanbevolen ecommerce-event refund. De sleutel is transaction_id: dezelfde unieke boekingsreferentie die bij purchase is verstuurd. Daarmee kan GA4 de terugbetaling relateren aan de eerdere transactie. Gebruik hiervoor geen nieuw ordernummer en geen persoonlijk gegeven zoals een e-mailadres. Een boekingsreferentie hoort bovendien uniek en stabiel te zijn.

Welke gegevens moeten worden vastgelegd?

Controleer eerst of iedere purchase een bruikbare transaction_id bevat. Leg daarnaast in de reserveringsdatabase vast wanneer de status verandert en welk bedrag werkelijk wordt terugbetaald. Bij een niet-restitueerbare boeking kan de reservering wel geannuleerd zijn terwijl geen refund plaatsvindt. Stuur dan niet automatisch de volledige oorspronkelijke omzet als terugbetaling weg.

• transaction_id: exact dezelfde boekingsreferentie als bij het purchase-event;
• value: het werkelijk terugbetaalde bedrag, niet standaard de oorspronkelijke boekingswaarde;
• currency: dezelfde valuta als waarin het bedrag wordt terugbetaald;
• items: de terugbetaalde onderdelen, als deelannuleringen per kamer, arrangement of product worden bijgehouden;
• timestamp: het moment waarop de annulering of terugbetaling definitief is verwerkt;
• status: intern onderscheid tussen volledige annulering, gedeeltelijke annulering, no-show en wijziging.

Stuur geen namen, e-mailadressen, telefoonnummers of andere persoonsgegevens naar GA4. Voor de technische koppeling zijn identifiers nodig, geen gastgegevens. Bewaar daarnaast een verzendstatus, zodat dezelfde annulering niet meerdere keren als refund wordt doorgestuurd.

Hoe stuur je een annulering naar GA4?

De betrouwbaarste route is een server-side koppeling vanuit de booking engine, het reserveringssysteem of een eigen database. Zodra een terugbetaling definitief is, stuurt de server via GA4 Measurement Protocol een refund-event. Daarbij horen de Measurement ID, een API secret en een geldige client_id of user_id. Het transaction_id verbindt de refund inhoudelijk aan de aankoop; client_id of user_id blijft nodig voor een geldig Measurement Protocol-verzoek.

Kan het reserveringssysteem geen webhook of API leveren, dan kan een periodieke export een alternatief zijn. Een integratie vergelijkt nieuwe annuleringen met eerder verwerkte records en stuurt alleen ontbrekende refunds door. Een browser-event op een annuleringspagina is minder betrouwbaar: niet iedere gast bezoekt zo'n pagina en annuleringen via receptie, telefoon of e-mail worden dan gemist.

Bij een volledige annulering stuur je het volledig terugbetaalde bedrag. Bij een gedeeltelijke annulering stuur je alleen het verschil. Wordt bijvoorbeeld één nacht verwijderd maar blijft de reservering bestaan, dan is alleen de waarde van die nacht relevant. Annuleringskosten die het hotel behoudt, zijn geen terugbetaalde omzet en worden dus niet opgenomen in value.

Netto omzet en kanaalprestaties beoordelen

Controleer in GA4 zowel purchases als refunds. Netto omzet is conceptueel de aankoopomzet minus terugbetaalde omzet. Houd er rekening mee dat GA4 de refund registreert op de datum waarop het refund-event binnenkomt. Een boeking uit januari die in februari wordt geannuleerd, kan daardoor in verschillende rapportageperioden vallen. Voor financiële aansluiting per verblijfs- of boekingsmaand blijft het reserverings- of financiële systeem leidend.

Voor kanaalbeoordeling is alleen bruto omzet onvoldoende. Exporteer bij voorkeur de GA4-data naar BigQuery of combineer ze in een rapportageomgeving met reserveringsdata. Koppel iedere annulering op transaction_id terug aan de bron, het medium en de campagne van de oorspronkelijke boeking. Zo bereken je per kanaal bruto boekingswaarde, terugbetaalde waarde en netto boekingswaarde. Dat voorkomt dat een kanaal met veel vroege boekingen maar ook veel latere annuleringen te gunstig lijkt.

• Vergelijk bruto omzet, refunds en netto omzet per kanaal naast elkaar.
• Toon ook aantallen geboekte, gedeeltelijk geannuleerde en volledig geannuleerde reserveringen.
• Gebruik één vaste definitie voor netto omzet, inclusief de omgang met belastingen en annuleringskosten.
• Scheid boekingsdatum, annuleringsdatum en verblijfsdatum in de onderliggende rapportage.
• Beoordeel recente boekingsperiodes voorzichtig: een deel van de annuleringen moet dan nog plaatsvinden.

Controleer de implementatie en voorkom dubbeltellingen

Test eerst met afzonderlijke scenario's: volledige annulering, gedeeltelijke annulering, annulering zonder terugbetaling en een reserveringswijziging. Controleer in DebugView of via de Measurement Protocol-validatieserver of eventnaam en parameters correct zijn. Vergelijk daarna per dag de verzonden refunds met de bronadministratie.

Let vooral op dubbele verzending. Een webhook kan opnieuw worden aangeboden en een nachtelijke synchronisatie kan dezelfde annulering nogmaals vinden. Gebruik daarom een unieke combinatie van transaction_id, terugbetaald bedrag en wijzigingsmoment, of sla per refund een eigen unieke sleutel op. Corrigeer ook niet zowel via een volledige refund als via meerdere deel-refunds voor hetzelfde bedrag. Met een vaste statuslogica en een controleerbaar verzendregister blijft GA4 bruikbaar voor marketinganalyse, terwijl het reserveringssysteem de financiële waarheid bewaart.