Supabase auf Ihren Landingpages
Ernsthafte Lead-Gen-Betreiber wollen irgendwann die Rohdaten in einer Datenbank, die sie kontrollieren: um Leads mit dem Budget zu verknüpfen, SQL auf die Lead-Qualität laufen zu lassen, ein Abnehmerportal oder eine Vertriebs-App zu füttern. Den Endpunkt zu bauen, der die Leads empfängt, ist der Teil, an dem es meist hängt, weil ihn jemand schreiben und am Laufen halten muss.
Supabase nimmt Ihnen diesen Teil ab. Jede Tabelle hat schon einen REST-Endpunkt, und der Webhook von LanderLab postet jeden Lead als flachen Satz aus Spaltennamen und Werten dorthin. Postgres fügt die Zeile ein, Row Level Security entscheidet, was die Anfrage darf, und der Lead ist mit Kampagne und Variante in Ihrer Datenbank.
Eine Postgres-Zeile pro Lead, in Ihrem Schema
Der Request-Body ist flach, ein Key pro Spalte, so wird jeder Lead eine Zeile mit typisierten Spalten, einem created_at-Zeitstempel aus dem Standardwert der Spalte und einer id, auf die Ihre anderen Systeme verweisen können. Keys, die zu keiner Spalte passen, werden abgelehnt, das hält verirrte Daten aus der Tabelle.
Weil es Postgres ist, ist die Zeile bereit für alles, was SQL kann: eine View der Leads pro Kampagne und Tag, ein Join mit Ihrer Kostentabelle, ein Unique-Index auf die E-Mail, wenn Sie wiederholte Absendungen lieber abweisen, als sie doppelt zu speichern.
Abgesichert mit Row Level Security
Der Webhook schreibt mit dem Publishable Key Ihres Projekts, und Row Level Security entscheidet, was dieser Key darf. Erlauben Sie Inserts in die Leads-Tabelle und sonst nichts, und der Key kann Leads hinzufügen, aber nie lesen, ändern oder löschen. Die Lead-Daten bleiben also unerreichbar, auch wenn der Key nicht geheim ist.
Der Secret Key, der Row Level Security umgeht, muss Ihr eigenes Backend nie verlassen: Ein Lead-Formular braucht ihn nicht.
Ihre eigene verlässliche Quelle für Lead-Qualität
Builder, CRMs und Tracker halten jeweils einen Teil der Geschichte. Eine Supabase-Tabelle mit jedem Lead und seiner utm_campaign, Click-ID, Landingpage und Variante ist der Teil, den Sie kontrollieren. Laden Sie das Tagesbudget in eine zweite Tabelle, und eine SQL-View liefert die Kosten pro Lead nach Kampagne und Variante; ergänzen Sie die Ergebnisse, die Ihre Abnehmer oder Vertriebler erfassen, und sie liefert die Kosten pro Verkauf.
So entscheiden Sie einen Split-Test ehrlich: nicht danach, welche Variante mehr Formular-Absendungen bekam, sondern danach, wessen Leads zu Geld wurden.
Leads, die einen fehlgeschlagenen Insert überstehen
Jeder Lead bleibt außerdem im Tab „Interessenten“ von LanderLab, filterbar nach Datum und Variante und ab Grow als CSV exportierbar, außer die „Compliance-konforme Interessenten-Zustellung“ ist aktiv. Schlägt ein Insert einmal fehl, etwa nachdem eine Spalte umbenannt wurde, ist der Lead nicht weg: Korrigieren Sie die Tabelle und füllen Sie aus dem Export nach. Senden Sie stattdessen über LanderLab Workflows (Beta), zeigt die Ausführungsansicht genau, bei welchem Lead die Anfrage fehlschlug.
