Webhooks og serverside tracking: 50 % flere målte events for Handyhand og HappyHelper

Super graphic that is round with blue and green tones

CASE · SERVERSIDE TRACKING

Når kunden booker på websitet, men betaler først, når opgaven er løst, går sporet ofte tabt. På Stapes infrastruktur har vi bygget en webhook-baseret serverside-opsætning for de danske markedspladser Handyhand og HappyHelper, der har givet 50 % flere målte events og for første gang et retvisende billede af ROAS.
Obsidians tracking-team arbejder med serverside tracking og dashboards

To markedspladser – ét målingsproblem

Handyhand forbinder folk med lokale hjælpere til hverdagsopgaver, og HappyHelper formidler fast rengøring i private hjem – tusindvis af besøg hver måned. Begge forretninger lever af betalt annoncering, og begge har den samme udfordring: Kunden klikker på en annonce og booker på websitet, men selve værdien opstår senere. Opgaven bliver løst, og betalingen bliver gennemført af serviceudbyderen – ofte dage senere og på en helt anden enhed.

Med traditionel browserbaseret tracking ender annonceplatformene derfor med kun at se den første halvdel af kunderejsen. Den reelle omsætning og de gennemførte opgaver bliver aldrig koblet tilbage til den kampagne, der skabte dem.

Safari gør problemet større

Ifølge casen udgjorde Safari omkring 25,5 % af brugerne – og i nogle perioder op mod 48 % af trafikken og over 50 % af salget. Safaris Intelligent Tracking Prevention kan slette cookies efter blot 24 timer. For en forretning, hvor der går dage fra booking til betaling, betyder det, at koblingen mellem klik og konvertering forsvinder netop hos en af de mest værdifulde brugergrupper.

Løsningen: Webhooks og serverside GTM på Stape

Vi byggede en cookieless serverside-opsætning i Google Tag Manager, hostet på Stapes infrastruktur. Kerneelementerne var:

  • En dedikeret serverside GTM-container, der samler data fra flere kilder: website, apps, CRM og offline-hændelser.
  • Webhooks via Stapes Data Client, så backend-systemerne sender en POST-request, når en opgave er udført, eller en betaling er gennemført – uanset hvilken enhed serviceudbyderen bruger.
  • Stape Store til at gemme krypterede bruger-ID'er, så den senere hændelse kan kobles til den oprindelige booking og dermed til annonceklikket.
  • Stape User ID som stabil identifikator, der ikke er afhængig af kortlivede browser-cookies.
  • Samtykke først: Kun førstepartsdata fra brugere, der har givet samtykke, bliver sendt videre – i overensstemmelse med GDPR.

Resultater

  • 50 % flere målte events sammenlignet med opsætningen uden webhooks.
  • End-to-end attribution fra annonceklik til gennemført og betalt opgave.
  • Reel ROAS for første gang – baseret på faktisk omsætning frem for bookinger.
  • Bedre optimering, fordi annonceplatformenes algoritmer nu får signaler om de konverteringer, der rent faktisk skaber værdi.
  • Robusthed over for Safari og andre browserbegrænsninger.
  • Måling af hændelser, som tidligere var umulige at tracke.

Hvad kan andre lære af det?

Casen er relevant for alle forretninger, hvor konverteringen ikke sker i browseren: markedspladser, abonnementer, leadgenerering med salg via telefon eller CRM, og services hvor betalingen falder efter levering. Hvis jeres vigtigste hændelser sker i backend, skal målingen også starte der. Webhooks og serverside tracking gør det muligt at sende de rigtige signaler til Meta, Google og andre platforme – uden at gå på kompromis med samtykke og datasikkerhed.

Obsidian er top partner hos Stape, og casen er også beskrevet på Stapes blog. Vil I vide, hvordan en tilsvarende opsætning kan se ud hos jer? Læs mere om serverside tracking hos Obsidian, eller tag fat i vores tracking-team.