Webhook na Twoich stronach docelowych
Większość stacków lead gen ma pośrodku podatek: Zapa albo scenariusz, którego jedynym zadaniem jest przenieść leada ze strony na endpoint, który przyjąłby go bezpośrednio. Każdy lead płaci za ten przeskok zadaniami lub kredytami, a każdy przeskok to kolejne miejsce, w którym lead może utknąć, podczas gdy odbiorca czeka.
Integracja Webhook w LanderLab go usuwa. Każda strona wysyła swoje leady prosto na dowolny endpoint HTTPS: posting URL odbiorcy, Twoje własne API do leadów, endpoint CRM-u, postback trackera. To Ty decydujesz o metodzie, formacie, nagłówkach i dokładnym body, więc druga strona dostaje leada tak, jak wymaga tego jej dokumentacja.
To integracja, na której opiera się większość narzędzi na tej stronie, które nie mają własnej pozycji, i to po nią sięgasz, gdy odbiorca przysyła Ci specyfikację.
Dlaczego bezpośredni webhook jest lepszy niż płacenie za pośrednika
Lead, który idzie ze strony do Zapa, a potem do odbiorcy, zależy od dwóch systemów, a jeden z nich wystawia za to rachunek. Na ofercie z dużym wolumenem plan automatyzacji rośnie razem z liczbą leadów, choć pośrodku nie dzieje się nic ciekawego: Zap odbiera leada i wysyła go gdzie indziej.
Bezpośredni webhook to ta sama wysyłka bez przeskoku. Lead idzie ze strony na endpoint po wysłaniu formularza, pod Twoją kontrolą, bez niczego pośrodku, co mogłoby się zatrzymać, wyczerpać limit zadań albo zmienić cennik. Pośrednika zostaw do zadań, które wymagają kilku kroków; resztę niech niesie webhook.
Wysyłaj leady w formacie, jakiego oczekuje druga strona
Odbiorcy i API mają swoje wymagania. Jeden chce płaskiego wysłania formularza z polami nazwanymi dokładnie jak w specyfikacji; inny chce JSON-a z kontaktem zagnieżdżonym w obiekcie leada, trackingiem w drugim obiekcie i stałym tagiem źródła oraz ID kampanii obok. Webhook robi jedno i drugie: prostą listę pól, w której zaznaczasz pola i zmieniasz nazwę każdego klucza, albo body JSON, które piszesz sam, z zagnieżdżonymi obiektami, tablicami i stałymi wartościami.
Dostępne metody to GET, POST i PUT, body idzie jako JSON lub dane formularza URL-encoded, a własne nagłówki niosą klucz API lub token, więc dane uwierzytelniające nigdy nie lądują w URL.
Pola do zgodności i atrybucji przy każdym leadzie
LanderLab dodaje do każdego leada własne pola: pełny URL strony, IP i user agent odwiedzającego, czas wysłania w UTC i pokazany wariant A/B. To pola, które odbiorca sprawdza, gdy lead jest kwestionowany, i te, których potrzebujesz, by udowodnić, skąd lead przyszedł.
Dodaj ukryte pola nazwane jak Twoje parametry URL, np. utm_campaign, gclid czy click ID trackera, a zostaną zapisane przy leadzie i wysłane razem z nim. Odbiorca dostaje atrybucję, a Ty możesz oceniać każdy wariant po zaakceptowanych leadach, a nie po surowych wypełnieniach formularza.
Postbacki i pingi przez GET
Nie każde miejsce docelowe chce body. Postback trackera, URL konwersji sieci afiliacyjnej czy zwykły ping przyjmuje dane w query stringu, a webhook GET wysyła zmapowane pola dokładnie w ten sposób: click ID pod nazwą parametru, jakiej oczekuje tracker, a obok stałą wypłatę lub status. Po wysłaniu formularza konwersja wraca do kampanii, która za nią zapłaciła.
Kiedy lepiej użyć workflow
Webhook wysyła każdego leada ze swojej strony. Gdy mają iść tylko niektóre leady, np. leady z USA do jednego odbiorcy, a reszta do innego, albo follow-up po węźle „Opóźnienie”, Workflows (beta) w LanderLab mają ten sam rodzaj żądania w węźle „Żądanie HTTP”, za węzłami „Filtr”, „Jeśli” i „Przełącznik”, z widokiem uruchomień, który pokazuje ścieżkę każdego leada i każdy krok, który się nie powiódł.
Tak czy inaczej lead jest też zapisany w zakładce Leady w LanderLab, więc endpoint, który nie działał, nie kosztuje Cię leada, chyba że włączona jest opcja „Zgodne dostarczanie leadów”, która z założenia pomija zapisywanie.
