Supabase nas suas landing pages
Operadores de lead gen sérios acabam querendo os dados brutos em um banco de dados que eles controlam: para cruzar leads com investimento, rodar SQL sobre a qualidade dos leads, alimentar um portal de compradores ou um app de vendedores. Criar o endpoint que recebe os leads é a parte que costuma travar, porque alguém precisa escrevê-lo e mantê-lo funcionando.
O Supabase elimina essa parte. Cada tabela já tem um endpoint REST, e o webhook do LanderLab posta cada lead nele como um conjunto plano de nomes de coluna e valores. O Postgres insere a linha, o Row Level Security decide o que a requisição pode fazer, e o lead está no seu banco de dados com a campanha e a variação.
Uma linha no Postgres por lead, no seu schema
O corpo da requisição é plano, uma chave por coluna, então cada lead vira uma linha com colunas tipadas, um timestamp created_at vindo do valor padrão da coluna e um id que os seus outros sistemas podem referenciar. Chaves que não correspondem a nenhuma coluna são rejeitadas, o que mantém dados soltos fora da tabela.
Como é Postgres, a linha está pronta para tudo o que o SQL faz: uma view de leads por campanha por dia, um join com a sua tabela de custos, um índice único no e-mail se você preferir recusar envios repetidos em vez de guardá-los duas vezes.
Protegido com o Row Level Security
O webhook escreve com a chave publicável do seu projeto, e o Row Level Security decide o que essa chave pode fazer. Permita inserções na tabela de leads e nada mais, e a chave pode adicionar leads, mas nunca lê-los, alterá-los ou apagá-los, então os dados dos leads ficam fora de alcance mesmo que a chave não seja secreta.
A chave secreta, que ignora o Row Level Security, nunca precisa sair do seu próprio backend: um formulário de leads não precisa dela.
A sua própria fonte de verdade sobre a qualidade dos leads
Builders, CRMs e trackers guardam cada um uma parte da história. Uma tabela no Supabase com cada lead e a utm_campaign, o click ID, a landing page e a variação dele é a parte que você controla. Carregue o investimento diário em uma segunda tabela e uma view em SQL dá o custo por lead por campanha e variação; adicione os resultados que os seus compradores ou vendedores registram e ela dá o custo por venda.
Essa é a forma honesta de decidir um teste A/B: não qual variação recebeu mais formulários preenchidos, mas os leads de qual delas viraram dinheiro.
Leads que sobrevivem a uma inserção que falhou
Cada lead também fica na aba Leads do LanderLab, filtrável por data e variação e exportável em CSV a partir do Grow, a menos que a Entrega de leads em compliance esteja ativada. Se uma inserção falhar, por exemplo depois que uma coluna foi renomeada, o lead não se perde: corrija a tabela e preencha o que faltou a partir da exportação. Envie pelos Workflows (beta) do LanderLab e a visão de execuções mostra exatamente qual requisição de lead falhou.
