Webhook nas suas landing pages
A maioria das operações de lead gen paga um pedágio no meio: um Zap ou um cenário cujo único trabalho é levar um lead da página para um endpoint que o receberia diretamente. Cada lead paga esse salto em tarefas ou créditos, e cada salto é mais um lugar onde um lead pode travar enquanto um comprador espera.
A integração de Webhook do LanderLab elimina esse pedágio. Cada página envia os leads direto para qualquer endpoint HTTPS: a URL de postagem de um comprador, a sua própria API de leads, o endpoint de um CRM, o postback de um tracker. Você decide o método, o formato, os headers e o body exato, então o outro lado recebe o lead do jeito que a documentação dele pede.
É a integração por trás da maioria das ferramentas deste site que não têm entrada própria, e é a que você usa quando um comprador manda a especificação dele.
Por que um webhook direto é melhor do que pagar por middleware
Um lead que vai da página para o Zap e do Zap para o comprador depende de dois sistemas e é cobrado por um deles. Numa oferta de alto volume, o plano de automação cresce com a sua contagem de leads, mesmo sem nada de interessante acontecer no meio: o Zap recebe um lead e posta em outro lugar.
Um webhook direto é o mesmo post sem o salto. O lead vai da página para o endpoint no envio, sob o seu controle, sem nada no meio para pausar, ficar sem tarefas ou mudar de preço. Deixe o middleware para as tarefas que precisam de várias etapas; deixe o webhook levar as que não precisam.
Envie os leads no formato que o outro lado espera
Compradores e APIs são exigentes. Um quer um post de formulário simples, com os campos nomeados exatamente como na especificação; outro quer JSON com o contato aninhado dentro de um objeto lead, o tracking dentro de outro e uma tag de origem e um ID de campanha fixos ao lado. O webhook faz os dois: uma lista simples em que você marca os campos e renomeia cada chave, ou um body JSON que você mesmo escreve, com objetos aninhados, arrays e valores fixos.
Os métodos cobrem GET, POST e PUT, os bodies vão como JSON ou dados de formulário URL-encoded, e headers personalizados levam uma chave de API ou um token, então as credenciais nunca ficam na URL.
Campos de compliance e atribuição em cada lead
O LanderLab adiciona os próprios campos a cada lead: a URL completa da página, o IP e o user agent do visitante, o horário do envio em UTC e a variação do teste A/B exibida. São esses os campos que um comprador confere quando um lead é contestado, e os que você precisa para provar de onde veio um lead.
Adicione campos ocultos com os nomes dos seus parâmetros de URL, como utm_campaign, gclid ou o click ID de um tracker, e eles são salvos com o lead e enviados junto. O comprador recebe a atribuição, e você pode avaliar cada variação pelos leads aceitos, não pelos formulários preenchidos.
Postbacks e pings com GET
Nem todo destino quer um body. Um postback de tracker, a URL de conversão de uma rede de afiliados ou um ping simples recebe os dados na query string, e um webhook GET envia os campos mapeados exatamente assim: o click ID com o nome de parâmetro que o tracker espera, um payout ou status fixo ao lado. A conversão volta, no envio, para a campanha que pagou por ela.
Quando usar um workflow
Um webhook envia todos os leads da página dele. Quando só alguns leads devem ir, como os leads dos EUA para um comprador e o resto para outro, ou um follow-up depois de uma Espera, os Workflows (beta) do LanderLab têm o mesmo tipo de requisição como um nó Requisição HTTP, depois de nós Filtro, Se e Switch, com uma visão de execuções que mostra o caminho de cada lead e qualquer etapa que falhou.
De qualquer forma, o lead também fica armazenado na aba Leads do LanderLab, então um endpoint fora do ar não custa o lead, a menos que a Entrega de leads em compliance esteja ativada, que por design não armazena o lead.
