आपकी landing pages पर Supabase
गंभीर lead gen ऑपरेटर्स आख़िरकार कच्चा डेटा ऐसे डेटाबेस में चाहते हैं जो उनके कंट्रोल में हो: leads को ख़र्च से जोड़ने के लिए, lead क्वालिटी पर SQL चलाने के लिए, किसी बायर पोर्टल या rep ऐप को डेटा देने के लिए। Leads लेने वाला endpoint बनाना वह हिस्सा है जो आमतौर पर अटक जाता है, क्योंकि किसी को उसे लिखना और चालू रखना पड़ता है।
Supabase वह हिस्सा हटा देता है। हर टेबल का पहले से एक REST endpoint होता है, और LanderLab का webhook हर lead को कॉलम नामों और वैल्यू के एक सपाट सेट के रूप में उस पर पोस्ट करता है। Postgres row डालता है, Row Level Security तय करती है कि रिक्वेस्ट क्या कर सकती है, और lead कैंपेन और वेरिएंट के साथ आपके डेटाबेस में होता है।
हर lead की एक Postgres row, आपके schema में
रिक्वेस्ट body सपाट है, हर कॉलम के लिए एक key, इसलिए हर lead एक row बनता है जिसमें typed कॉलम्स होते हैं, कॉलम के default से एक created_at टाइमस्टैम्प, और एक id जिसका आपके दूसरे सिस्टम हवाला दे सकें। जो keys किसी कॉलम से मैच नहीं करतीं, वे रिजेक्ट होती हैं, जिससे भटका हुआ डेटा टेबल से बाहर रहता है।
क्योंकि यह Postgres है, row हर उस काम के लिए तैयार है जो SQL करता है: हर दिन हर कैंपेन के leads का view, आपकी cost टेबल के साथ join, या ईमेल पर unique index, अगर आप दोहराए गए सबमिट को दो बार सेव करने के बजाय लौटाना पसंद करें।
Row Level Security से सुरक्षित
Webhook आपके प्रोजेक्ट की publishable key से लिखता है, और Row Level Security तय करती है कि वह key क्या कर सकती है। Leads टेबल पर सिर्फ़ inserts की इजाज़त दें, और कुछ नहीं, तो key leads जोड़ सकती है पर उन्हें कभी पढ़, बदल या डिलीट नहीं कर सकती, इसलिए key गुप्त न होने पर भी lead डेटा पहुंच से बाहर रहता है।
Secret key, जो Row Level Security को बायपास करती है, को कभी आपके अपने बैकएंड से बाहर नहीं जाना पड़ता: lead फ़ॉर्म को इसकी ज़रूरत नहीं।
Lead क्वालिटी के लिए आपका अपना भरोसेमंद स्रोत
Builders, CRMs और ट्रैकर्स, हर एक के पास कहानी का एक हिस्सा होता है। हर lead और उसके utm_campaign, click ID, landing page और वेरिएंट वाली Supabase टेबल वह हिस्सा है जिस पर आपका कंट्रोल है। रोज़ का ख़र्च दूसरी टेबल में लोड करें और एक SQL view कैंपेन और वेरिएंट के हिसाब से cost per lead देता है; आपके बायर्स या reps के दर्ज नतीजे जोड़ें, तो वह cost per sale देता है।
स्प्लिट टेस्ट का फ़ैसला करने का यही सच्चा तरीक़ा है: यह नहीं कि किस वेरिएंट को ज़्यादा फ़ॉर्म मिले, बल्कि यह कि किसके leads पैसे में बदले।
Leads जो फ़ेल हुए insert के बाद भी बचे रहते हैं
हर lead LanderLab के लीड्स टैब में भी रहता है, तारीख़ और वेरिएंट से फ़िल्टर होने लायक़ और Grow और उससे ऊपर CSV में एक्सपोर्ट होने लायक़, जब तक “Compliance लीड Delivery” चालू न हो। अगर कभी कोई insert फ़ेल हो, जैसे किसी कॉलम का नाम बदलने के बाद, तो lead खोता नहीं: टेबल ठीक करें और एक्सपोर्ट से backfill करें। इसके बजाय LanderLab Workflows (बीटा) से भेजें, तो Runs व्यू ठीक-ठीक दिखाता है कि किस lead की रिक्वेस्ट फ़ेल हुई।
