PostHog nas suas landing pages
A maioria dos projetos no PostHog começa no cadastro, o que significa que o anúncio que trouxe o usuário é um palpite. O webhook do LanderLab recua a linha de partida até o anúncio. Cada lead é postado no endpoint de captura do PostHog como um evento, com as respostas do formulário, a página, as UTMs e o IP do visitante como propriedades, e o e-mail e o nome da pessoa definidos no perfil dela.
É para times product-led que compram tráfego: trials de SaaS, apps com lista de espera, marketplaces recrutando oferta. Quando o lead e o uso do produto pertencem à mesma pessoa no PostHog, o funil do anúncio à ativação é um relatório, não uma planilha.
Leads de landing page como eventos no PostHog
Cada envio vira um evento “Lead submitted” no PostHog, com os campos do formulário e as respostas do quiz como propriedades. As propriedades do próprio PostHog também são preenchidas: a página como $current_url e o IP do visitante como $ip, então a localização vem da pessoa, não do servidor do LanderLab.
Os endpoints de captura do PostHog são públicos e só de escrita, e o token do projeto foi feito para ser compartilhado, então postar a partir de um webhook não precisa de chave secreta nenhuma.
Propriedades da pessoa a partir do formulário
Dentro do evento, $set grava o e-mail e o nome no perfil da pessoa, e $set_once guarda a primeira landing page em que ela converteu, mesmo que envie de novo depois. Se o seu app identifica os usuários pelo mesmo e-mail, o lead e tudo o que o usuário faz no produto pertencem a uma só pessoa.
Funis que começam no anúncio
Com utm_source, utm_campaign e a variação do teste A/B no evento de lead, um funil do PostHog pode começar na landing page e terminar na ação que importa para você: primeiro projeto criado, primeira fatura enviada, upgrade de plano. Divida por campanha e você vê quais conjuntos de anúncios trazem usuários que se ativam, não só usuários que se cadastram.
Esse é o teste que o LanderLab não consegue rodar sozinho: os relatórios dele julgam uma variação pelos leads, e o PostHog estende o julgamento ao que esses leads fazem depois.
Só os leads que valem rastrear, com Workflows
Nem todo envio pertence ao analytics de produto. Um Workflow pode ficar entre a página e o PostHog: um Filtro que deixa passar só os quizzes concluídos, um nó Se que deixa os leads de teste de fora e depois um nó Requisição HTTP que posta o evento. A visão de execuções mostra o caminho de cada lead, então um envio que falhou fica visível em vez de sumir em silêncio de um funil.
