Supabase sur vos landing pages
Les opérateurs de lead gen sérieux finissent par vouloir les données brutes dans une base qu'ils contrôlent : pour croiser leads et dépenses, faire du SQL sur la qualité des leads, alimenter un portail acheteurs ou une app pour leurs commerciaux. Construire l'endpoint qui reçoit les leads est l'étape qui bloque en général, parce que quelqu'un doit l'écrire et le faire tourner.
Supabase supprime cette étape. Chaque table a déjà un endpoint REST, et le webhook de LanderLab y poste chaque lead sous forme d'un ensemble plat de noms de colonnes et de valeurs. Postgres insère la ligne, la Row Level Security décide de ce que la requête a le droit de faire, et le lead est dans votre base avec la campagne et la variante.
Une ligne Postgres par lead, dans votre schéma
Le corps de la requête est plat, une clé par colonne : chaque lead devient une ligne avec des colonnes typées, un horodatage created_at issu de la valeur par défaut de la colonne et un id que vos autres systèmes peuvent référencer. Les clés qui ne correspondent à aucune colonne sont rejetées, ce qui garde les données parasites hors de la table.
Comme c'est du Postgres, la ligne est prête pour tout ce que fait le SQL : une vue des leads par campagne et par jour, une jointure avec votre table de coûts, un index unique sur l'e-mail si vous préférez refuser les envois répétés plutôt que de les stocker deux fois.
Verrouillé avec la Row Level Security
Le webhook écrit avec la publishable key de votre projet, et la Row Level Security décide de ce que cette clé a le droit de faire. Autorisez les insertions sur la table des leads et rien d'autre : la clé peut ajouter des leads mais jamais les lire, les modifier ou les supprimer, et les données des leads restent hors d'atteinte même si la clé n'est pas secrète.
La clé secrète, qui contourne la Row Level Security, n'a jamais à quitter votre propre backend : un formulaire de leads n'en a pas besoin.
Votre propre source de vérité sur la qualité des leads
Builders, CRM et trackers détiennent chacun une partie de l'histoire. Une table Supabase avec chaque lead et son utm_campaign, son click ID, sa landing page et sa variante, c'est la partie que vous contrôlez. Chargez les dépenses quotidiennes dans une seconde table, et une vue SQL donne le coût par lead par campagne et par variante ; ajoutez les résultats que vos acheteurs ou vos commerciaux enregistrent, et elle donne le coût par vente.
C'est la façon honnête de trancher un split test : non pas quelle variante a eu le plus de formulaires remplis, mais de laquelle les leads ont rapporté de l'argent.
Des leads qui survivent à une insertion en échec
Chaque lead est aussi conservé dans l'onglet Prospects de LanderLab, filtrable par date et par variante et exportable en CSV à partir de Grow, sauf si l'option « Livraison des prospects conforme » est activée. Si une insertion échoue, par exemple après le renommage d'une colonne, le lead n'est pas perdu : corrigez la table et complétez depuis l'export. Passez plutôt par les workflows LanderLab (bêta), et la vue des exécutions montre exactement quelle requête de lead a échoué.
