En platform til linksporing registrerer, hvad der sker med dine links. En webhook er platformen, der fortæller dine andre systemer om det, mens det sker, i stedet for at vente på, at nogen kigger i et dashboard. Kombinationen gør, at et nyt kampagnelink dukker op i dit CRM i samme øjeblik, det bliver oprettet, eller at et hemmeligt link, der bliver åbnet, opdaterer en sag.
Når du vælger en platform til linksporing med webhook-integrationer, skal du se forbi ”har webhooks” og på, hvilke hændelser den sender, hvordan den sikrer dem, og hvad den ikke sender. Denne guide gennemgår alt det, hvordan du bygger en pålidelig modtager, og hvornår API'et er det bedre værktøj.
Hvad webhooks fra en linkplatform bruges til
Tre opgaver går igen.
- Holde systemer synkroniseret. Et link, der bliver oprettet på platformen, dukker op på kampagnen i dit CRM eller projektværktøj med sin slug og destination, uden at nogen kopierer det.
- Starte arbejdsgange. Et hemmeligt link, der er blevet åbnet, markerer en overdragelse som afsluttet. Et link, der blev slettet, uden at modtageren bekræftede, åbner en hændelsessag.
- Fodre et datavarehus. Hændelser lander i en kø og derefter i en tabel, hvor de bliver koblet med resten af dine data.
Webhooks er ikke gode til at tælle. Et dashboard, der lægger én til et tal for hver webhook, kommer ud af trit med platformens egen rapport, første gang en levering bliver forsinket eller sendt igen. Brug API'et eller en eksport til tal og webhooks til handlinger.
Hvilke hændelser du skal kigge efter
Platformene sender forskellige ting. Bed om listen, ikke om funktionen.
| Hændelsestype | Typiske hændelser | God til |
|---|---|---|
| Linkets livscyklus | oprettet, opdateret, slettet | Synkronisering til CRM, revisionsspor, fange utilsigtede ændringer |
| Hemmelighedens livscyklus | oprettet, vist, slettet efter læsning | Bekræftelse af overdragelse, udløsning af hændelsessager |
| Klikhændelser | pr. klik eller samlet i batches | Automatisering i realtid ved store mængder |
| Domænehændelser | verificeret, certifikat udstedt | Driftsalarmer |
LinkPilots webhooks dækker linkets livscyklus (link.created,
link.updated, link.deleted) og hemmelighedens livscyklus
(secret.created, secret.viewed, secret.burned). Klikdata får du
via statistik-API'et og CSV-eksport i stedet for som en webhook pr.
klik. Det er den rigtige opdeling for de fleste teams: klik er
rapporteringsdata i store mængder, mens livscyklushændelser er dem,
der skal udløse noget.
Hvis din arbejdsgang virkelig har brug for en reaktion på hvert klik, så bekræft, at platformen samler dem i batches eller begrænser hastigheden. Ellers bygger du en modtager, der går ned, første gang et opslag går viralt.
Hvad du ellers skal vurdere
- Signering. Hver levering skal have en signatur, der er beregnet med en hemmelighed, du har, så dit endpoint kan afvise forfalskninger. En platform, der sender usignerede webhooks, beder dig stole på enhver POST-anmodning.
- Nye forsøg og rækkefølge. Find ud af, hvor mange gange en mislykket levering bliver forsøgt igen, og over hvor lang tid, og gå ud fra, at hændelser kan ankomme i forkert rækkefølge.
- Hændelses-id'er. Et unikt id pr. hændelse er det, der gør idempotens mulig.
- Styring af endpoints. Flere endpoints pr. arbejdsområde, abonnement pr. hændelse og en leveringslog, du kan læse, når noget går galt.
- API'et ved siden af. Webhooks til udløsere, API'et til alt
andet. Tjek, at oprettelse af links, statistik og eksport alle kan
styres via kode, og at nøgler kan begrænses. LinkPilots API bruger
bearer-nøgler med
lp_live_og findes på alle planer. - Adgang i teamet. Det betyder noget, hvem der kan tilføje et webhook-endpoint, fordi et endpoint modtager data. Roller skal lade en administrator styre endpoints og holde alle andre ude.
Byg en modtager, der ikke går ned
- Verificer signaturen først. Beregn den forventede signatur ud fra den rå body og din hemmelighed, sammenlign i konstant tid, og afvis alt, der fejler, før du parser det.
- Kvitter hurtigt. Returner en 2xx inden for et sekund eller to. Lav det egentlige arbejde fra en kø, så et langsomt CRM ikke fører til nye forsøg.
- Gem hændelses-id'er, og spring dem over, du har set før. Nye forsøg er normale, dobbeltbehandling er din fejl.
- Map felterne eksplicit. Træk de felter, du har brug for (slug, destination, tags og tidsstempler), over i dit eget skema. Gem ikke hele payloaden som sandheden. Den er en notifikation, ikke en post.
- Log hver levering med id og udfald, så du kan finde ud af, hvor den blev af, når platformens log siger leveret, og dit system siger, at intet skete.
- Slå alarm ved stilhed. Hvis et endpoint, der normalt modtager hændelser hver time, er stille i et døgn, er noget gået i stykker i den ene ende.
Test med et staging-endpoint og platformens testlevering før den første rigtige kampagne. Opret et link, rediger det, slet det, og se de tre hændelser ankomme.
Beskyt dataene
Webhook-payloads beskriver links og hemmeligheder, ikke personer. Hold det sådan.
- Læg aldrig persondata i slugs eller tags, fordi de følger med i hver payload om det link.
- Begræns endpointet til platformens trafik via signaturen og, hvor det er muligt, via afsenderadressen.
- Gem signeringshemmeligheden i en secrets manager, ikke i modtagerens konfigurationsfil, og roter den efter en fast plan. Hvis du skal give hemmeligheden til en konsulent, der bygger modtageren, så send den som et hemmeligt engangslink. Guiden til signeringshemmeligheder til webhooks gennemgår den overdragelse.
- Tænk på samtykke, når klikdata flyder til et CRM. En klikregistrering, der er koblet til en kunde, er persondata efter de fleste regler om databeskyttelse.
Mål selve integrationen
- Andel af vellykkede leveringer fra platformens log.
- Forsinkelse i behandlingen fra hændelsens tidsstempel til registreringen i dit system.
- Andel af dubletter, som skal være lav, men aldrig nul.
- Afstemning: én gang om ugen sammenligner du antal links og samlede klik fra API'et med det, dine systemer har. Afvigelser betyder en tabt levering eller en fejl i modtageren.
En platform til linksporing med webhooks lader dine links tage del i resten af dine systemer. Vælg en, der signerer det, den sender, fortæller dig præcis, hvilke hændelser der findes, og giver dig et API til tallene. Byg derefter modtageren, som om nye forsøg er det normale, for det er de.