Webhook sulle tue landing page
Quasi tutti gli stack di lead gen hanno una tassa nel mezzo: uno Zap o uno scenario il cui unico compito è spostare un lead dalla pagina a un endpoint che l'avrebbe accettato direttamente. Ogni lead paga quel passaggio in task o crediti, e ogni passaggio è un punto in più dove un lead può bloccarsi mentre un acquirente aspetta.
L'integrazione Webhook di LanderLab la elimina. Ogni pagina invia i suoi lead direttamente a qualsiasi endpoint HTTPS: l'URL di posting di un acquirente, la tua API per i lead, l'endpoint di un CRM, il postback di un tracker. Decidi tu metodo, formato, header e body esatto, così dall'altra parte il lead arriva come lo chiede la sua documentazione.
È l'integrazione dietro la maggior parte degli strumenti di questo sito che non hanno una voce propria, ed è quella da usare quando un acquirente ti manda le sue specifiche.
Perché un webhook diretto batte un middleware a pagamento
Un lead che va dalla pagina allo Zap e poi all'acquirente dipende da due sistemi e viene fatturato da uno dei due. Su un'offerta ad alto volume, il piano di automazione cresce con il numero di lead anche se nel mezzo non succede niente di interessante: lo Zap riceve un lead e lo invia da un'altra parte.
Un webhook diretto è lo stesso invio senza il passaggio. All'invio del form il lead va dalla pagina all'endpoint, sotto il tuo controllo, senza niente nel mezzo che si metta in pausa, finisca i task o cambi i prezzi. Tieni il middleware per i lavori che richiedono più step; lascia al webhook quelli che non li richiedono.
Invia i lead nel formato che si aspetta l'altra parte
Acquirenti e API sono pignoli. Uno vuole un invio di form piatto con i campi chiamati esattamente come nelle sue specifiche; un altro vuole un JSON con il contatto annidato in un oggetto lead, il tracking in un altro e accanto un tag della sorgente e un ID campagna fissi. Il webhook fa entrambe le cose: un semplice elenco in cui spunti i campi e rinomini ogni chiave, o un body JSON che scrivi tu con oggetti annidati, array e valori statici.
I metodi coprono GET, POST e PUT, i body partono come JSON o come dati di form URL-encoded, e gli header personalizzati portano una API key o un token, così le credenziali non stanno mai nell'URL.
Campi di compliance e attribuzione su ogni lead
LanderLab aggiunge i propri campi a ogni lead: l'URL completo della pagina, l'IP e lo user agent del visitatore, l'ora dell'invio in UTC e la variante A/B mostrata. Sono i campi che un acquirente controlla quando un lead viene contestato, e quelli che ti servono per dimostrare da dove arriva un lead.
Aggiungi campi nascosti con lo stesso nome dei tuoi parametri URL, come utm_campaign, gclid o il click ID di un tracker, e vengono salvati con il lead e inviati insieme a lui. L'acquirente riceve l'attribuzione, e tu puoi giudicare ogni variante sui lead accettati invece che sui form compilati.
Postback e ping con GET
Non ogni destinazione vuole un body. Il postback di un tracker, l'URL di conversione di un network di affiliazione o un semplice ping prendono i dati nella query string, e un webhook GET invia i campi mappati esattamente così: il click ID con il nome di parametro che si aspetta il tracker, accanto un payout o uno stato statico. All'invio la conversione torna alla campagna che l'ha pagata.
Quando usare invece un workflow
Un webhook invia ogni lead della sua pagina. Quando devono partire solo alcuni lead, per esempio i lead USA a un acquirente e gli altri a un altro, o un follow-up dopo un Ritardo, i Workflow (beta) di LanderLab hanno lo stesso tipo di richiesta come nodo Richiesta HTTP, dietro nodi Filtro, Se e Switch, con una vista Esecuzioni che mostra il percorso di ogni lead e qualsiasi step non riuscito.
In entrambi i casi, il lead è salvato anche nella scheda Lead di LanderLab, quindi un endpoint che non rispondeva non ti fa perdere il lead, a meno che non sia attiva Consegna lead compliant, che per scelta salta il salvataggio.
