Supabase sulle tue landing page
Chi fa lead gen sul serio finisce per volere i dati grezzi in un database che controlla: per collegare i lead alla spesa, per fare SQL sulla qualità dei lead, per alimentare un portale per gli acquirenti o un'app per i commerciali. Costruire l'endpoint che riceve i lead è la parte che di solito si blocca, perché qualcuno deve scriverlo e tenerlo in funzione.
Supabase elimina quella parte. Ogni tabella ha già un endpoint REST, e il webhook di LanderLab ci invia ogni lead come un insieme piatto di nomi di colonna e valori. Postgres inserisce la riga, la Row Level Security decide cosa può fare la richiesta, e il lead è nel tuo database con la campagna e la variante.
Una riga Postgres per lead, nel tuo schema
Il corpo della richiesta è piatto, una chiave per colonna, così ogni lead diventa una riga con colonne tipizzate, un timestamp created_at dal valore predefinito della colonna e un id a cui gli altri tuoi sistemi possono fare riferimento. Le chiavi che non corrispondono a nessuna colonna vengono rifiutate, e così i dati estranei restano fuori dalla tabella.
Visto che è Postgres, la riga è pronta per tutto ciò che fa l'SQL: una vista dei lead per campagna al giorno, un join con la tua tabella dei costi, un indice univoco sull'email se preferisci respingere gli invii ripetuti invece di salvarli due volte.
Protetto con la Row Level Security
Il webhook scrive con la publishable key del tuo progetto, e la Row Level Security decide cosa può fare quella chiave. Consenti gli inserimenti sulla tabella dei lead e nient'altro, e la chiave può aggiungere lead ma mai leggerli, modificarli o eliminarli, così i dati dei lead restano irraggiungibili anche se la chiave non è segreta.
La secret key, che aggira la Row Level Security, non deve mai uscire dal tuo backend: a un form lead non serve.
La tua fonte di verità sulla qualità dei lead
Builder, CRM e tracker hanno ognuno una parte della storia. Una tabella Supabase con ogni lead e il suo utm_campaign, click ID, landing page e variante è la parte che controlli tu. Carica la spesa giornaliera in una seconda tabella e una vista SQL ti dà il costo per lead per campagna e variante; aggiungi gli esiti che registrano i tuoi acquirenti o commerciali e ti dà il costo per vendita.
È il modo onesto di chiudere uno split test: non quale variante ha avuto più form compilati, ma i lead di quale si sono trasformati in soldi.
Lead che sopravvivono a un inserimento fallito
Ogni lead viene conservato anche nella scheda Lead di LanderLab, filtrabile per data e variante ed esportabile in CSV da Grow in su, a meno che non sia attiva Consegna lead compliant. Se un inserimento fallisce, per esempio dopo che una colonna è stata rinominata, il lead non è perso: sistema la tabella e recupera i dati dall'export. Se invece invii tramite i Workflow (beta) di LanderLab, la vista Esecuzioni mostra esattamente la richiesta di quale lead è fallita.
