Una plataforma de seguiment d'enllaços registra què ha passat amb els enllaços. Amb un webhook, la plataforma avisa els vostres altres sistemes en el moment que passa, en lloc d'esperar que algú miri un tauler. Amb tots dos, un enllaç de campanya nou apareix al CRM tan bon punt es crea, o l'obertura d'un enllaç secret actualitza un tiquet.
Triar una plataforma de seguiment d'enllaços amb integracions de webhooks vol dir anar més enllà de «té webhooks» i mirar quins esdeveniments envia, com els protegeix i què no envia. Aquesta guia ho explica tot, a més de com construir un receptor fiable i quan l'API és l'eina adequada.
Per a què serveixen els webhooks d'una plataforma d'enllaços
Hi ha tres feines que surten una vegada i una altra.
- Mantenir els sistemes sincronitzats. Un enllaç creat a la plataforma apareix al registre de la campanya al CRM o a l'eina de projectes, amb l'àlies i la destinació, sense que ningú l'hagi de copiar.
- Engegar processos. Un enllaç secret que s'ha obert marca un traspàs com a completat; un que s'ha destruït sense que el destinatari ho confirmi obre una incidència.
- Alimentar un magatzem de dades. Els esdeveniments arriben a una cua i després a una taula, on s'uneixen a la resta de dades.
Per al que no serveixen els webhooks és per comptar. Un tauler que suma u a una xifra per cada webhook deixarà de quadrar amb l'informe de la plataforma la primera vegada que un lliurament es reintenti o s'endarrereixi. Feu servir l'API o una exportació per a les xifres, i els webhooks per a les accions.
Quins esdeveniments cal buscar
Les plataformes no emeten els mateixos esdeveniments. Demaneu la llista, no la funció.
| Família d'esdeveniments | Esdeveniments habituals | Útils per a |
|---|---|---|
| Cicle de vida de l'enllaç | creat, actualitzat, suprimit | Sincronitzar amb el CRM, rastre d'auditoria, detectar edicions accidentals |
| Cicle de vida del secret | creat, vist, destruït | Confirmar traspassos, obrir incidències |
| Esdeveniments de clic | per clic o en lots | Automatització en temps real, amb volum |
| Esdeveniments de domini | verificat, certificat emès | Alertes d'operacions |
Els webhooks de LinkPilot cobreixen el cicle de vida dels enllaços
(link.created, link.updated, link.deleted) i el dels secrets
(secret.created, secret.viewed, secret.burned). Les dades de clics
es poden obtenir amb l'API d'estadístiques i l'exportació a CSV, no
amb un webhook per clic, i per a la majoria d'equips aquesta és la
divisió correcta: els clics són dades d'informe de gran volum, mentre
que els esdeveniments del cicle de vida són els que han de posar
alguna cosa en marxa.
Si el vostre procés necessita de debò una reacció per clic, comproveu que la plataforma els agrupa en lots o en limita el ritme; si no, construireu un receptor que caurà la primera vegada que una publicació es faci viral.
Què més cal avaluar
- Signatura. Cada lliurament ha de portar una signatura calculada amb un secret que tingueu vosaltres, perquè el vostre endpoint pugui rebutjar les falsificacions. Una plataforma que envia webhooks sense signar us demana que confieu en qualsevol petició POST.
- Reintents i ordre. Esbrineu quantes vegades es reintenta un lliurament fallit i durant quant de temps, i doneu per fet que els esdeveniments poden arribar desordenats.
- Identificadors d'esdeveniment. Un identificador únic per esdeveniment és el que fa possible la idempotència.
- Gestió dels endpoints. Diversos endpoints per espai de treball, subscripcions per esdeveniment i un registre de lliuraments que pugueu consultar quan alguna cosa falla.
- L'API al costat. Webhooks per als disparadors, API per a tota la
resta. Comproveu que la creació d'enllaços, les estadístiques i les
exportacions es poden fer per programa i que les claus es poden
limitar a uns permisos concrets. L'API de LinkPilot fa servir claus
bearer
lp_live_i és a tots els plans. - Accés de l'equip. Importa qui pot afegir un endpoint de webhook, perquè un endpoint rep dades. Els rols han de permetre que un administrador gestioni els endpoints i que ningú més hi tingui accés.
Construïu un receptor que no caigui
- Verifiqueu primer la signatura. Calculeu la signatura esperada a partir del cos en brut i del vostre secret, compareu-les en temps constant i rebutgeu tot el que no passi la prova abans d'analitzar-lo.
- Respongueu de pressa. Retorneu un 2xx en un o dos segons. Feu la feina de debò des d'una cua, perquè un CRM lent no provoqui reintents.
- Deseu els identificadors d'esdeveniment i ometeu els que ja hàgiu vist. Els reintents són normals; processar-ho dues vegades és un error vostre.
- Assigneu els camps de manera explícita. Porteu al vostre esquema l'àlies, la destinació, les etiquetes i les marques de temps que necessiteu. No deseu tota la càrrega útil com a font de veritat: és una notificació, no un registre.
- Registreu cada lliurament amb el seu identificador i el resultat, perquè, quan el registre de la plataforma digui «lliurat» i el vostre sistema digui que no ha passat res, pugueu esbrinar on ha anat a parar.
- Poseu una alerta per als silencis. Si un endpoint que sol rebre esdeveniments cada hora queda en silenci durant un dia, alguna cosa s'ha trencat en un dels dos costats.
Abans de la primera campanya real, proveu-ho amb un endpoint de proves i el lliurament de prova de la plataforma. Creeu un enllaç, editeu-lo, suprimiu-lo i comproveu que arriben els tres esdeveniments.
Protegiu les dades
Les càrregues útils dels webhooks descriuen enllaços i secrets, no persones. Mantingueu-ho així.
- No poseu mai dades personals als àlies ni a les etiquetes dels enllaços, perquè viatjaran en cada càrrega útil sobre aquell enllaç.
- Restringiu l'endpoint al trànsit de la plataforma mitjançant la signatura i, si és possible, l'adreça d'origen.
- Deseu el secret de signatura en un gestor de secrets, no al fitxer de configuració del receptor, i roteu-lo periòdicament. Si l'heu de donar a un col·laborador extern que construeix el receptor, envieu-lo amb un enllaç secret d'un sol ús. La guia sobre el secret de signatura de webhooks explica com fer aquest traspàs.
- Tingueu en compte el consentiment quan les dades de clics vagin a un CRM. Un registre de clic unit a un client és una dada personal segons la majoria de normes de privadesa.
Mesureu la integració mateixa
- Taxa de lliuraments correctes, segons el registre de la plataforma.
- Retard de processament, des de la marca de temps de l'esdeveniment fins al registre al vostre sistema.
- Taxa de duplicats, que ha de ser baixa però mai zero.
- Conciliació: una vegada a la setmana, compareu el nombre d'enllaços i els totals de clics de l'API amb el que tenen els vostres sistemes. Una desviació indica un lliurament perdut o un error al receptor.
Una plataforma de seguiment d'enllaços amb webhooks fa que els enllaços s'integrin amb la resta dels vostres sistemes. Trieu-ne una que signi el que envia, que us digui exactament quins esdeveniments hi ha i que us doni una API per a les xifres. Després construïu el receptor com si els reintents fossin el cas normal, perquè ho són.