एजेंसियाँ
एक फ़नल, बीस ग्राहक, बीस अलग-अलग प्रतिष्ठाएँ
बीस स्थानीय व्यवसायों के लिए मार्केटिंग चलाने वाली तीन-सदस्यीय एजेंसी को वही समस्या बीस बार होती है, और वही समाधान बीस बार — सिवाय इसके कि हर ग्राहक की सूची, भेजने की पहचान, डोमेन और सहमति अभिलेख पूरी तरह उसका अपना रहना चाहिए। दिलचस्प काम उसी "सिवाय" में है।
प्रति ग्राहक एक प्रोजेक्ट, और सीमा डेटाबेस का काम है
यहाँ सब कुछ एक टेनेंट और एक प्रोजेक्ट के साथ सीमित है — संपर्क, फ़नल, क्रिएटिव, अभियान, भेजने की पहचान, रिपोर्ट। यह सीमन डेटाबेस में पंक्ति-स्तरीय सुरक्षा द्वारा लागू होता है, किसी क्वेरी में जोड़ना याद रखने वाले खंड द्वारा नहीं। भुला हुआ प्रोजेक्ट कुछ नहीं देखता, पहले प्रोजेक्ट की पंक्तियाँ नहीं।
इसका अर्थ है कि किसी ग्राहक की सूची गलती से दूसरे ग्राहक के अभियान में नहीं टपक सकती, और इसका अर्थ यह भी कि कोई रिपोर्ट एक ग्राहक की होती है क्योंकि संरचनात्मक रूप से वह दो की नहीं हो सकती।
हर ग्राहक अपनी पहचान से भेजता है
भेजने की पहचान एक प्रोजेक्ट से संबंधित होती है: उनका डोमेन, उनकी DKIM कुंजियाँ, उनका मेलबॉक्स या प्रदाता खाता, उनकी दर सीमा। एक ग्राहक का खराब अभियान दूसरे ग्राहक की डिलीवरेबिलिटी को नुकसान नहीं पहुँचा सकता, क्योंकि उनके पास कभी कोई साझा चीज़ थी ही नहीं।
यह एक अजीब बातचीत को भी जल्दी सुलझा देता है। ग्राहक का भेजना, उसकी सूची और उसका सहमति अभिलेख उसी का होता है। जब वह जाता है — और कुछ जाएँगे — तो वह सब कुछ अपने साथ ले जाता है, और आपने कोई ऐसी बंधक स्थिति नहीं बनाई जिसका आपको बाद में उत्तर देना पड़े।
- 1संपर्कप्रति प्रोजेक्ट। डेटाबेस में लागू, किसी याद रखने वाली क्वेरी द्वारा नहीं।
- 2भेजनाउनका डोमेन, उनकी DKIM, उनका मेलबॉक्स या प्रदाता, उनकी दर सीमा।
- 3सहमतिउनका अभिलेख। वह उनके साथ जाता है, प्रमाण सहित, यदि वे जाएँ।
- 4रिपोर्टसंरचना से ही प्रति प्रोजेक्ट। दो ग्राहकों को गलती से मिलाने का कोई रास्ता नहीं है।
- iआप क्या रखते हैंफ़नल परिभाषाएँ और आपका काम करने का तरीका। वही आपका उत्पाद है, और वही पुनः उपयोग योग्य हिस्सा है।
कोई साझा प्रतिष्ठा नहींकोई साझा सूची नहीं
कॉपी-पेस्ट के बिना पुनः उपयोग
फ़नल एक बार बनाएँ। जितने ग्राहक हैं, उतनी बार तैनात करें।
फ़नल एक ग्राफ़ है, और ग्राफ़ प्रकाशित स्कीमा वाला JSON है। इसका अर्थ है कि आप जो पुनः उपयोग करते हैं वह एक दस्तावेज़ है, किसी स्क्रीन का स्क्रीनशॉट नहीं जिसे आपको हर खाते में हाथ से फिर से बनाना पड़े।
आपके अपने फ़नल
स्वागत, छोड़ी हुई टोकरी, न आना, अंतराल, वापस जीतना। जो सबसे अच्छा कर सकता है वह एक बार लिखे, आपके अपने भंडार में रखे जाएँ, और एक API कॉल से ग्राहक प्रोजेक्ट में बनाए जाएँ।
हर जगह एक ही तरह से जाँचे गए
सत्यापक आपके फ़नल पर उसके हर प्रोजेक्ट में चलता है जहाँ वह पहुँचता है। बिना प्रतीक्षा के लूप बनाने वाला, या बिना विषय के भेजने वाला ग्राफ़ वहीं अस्वीकृत होता है, जैसा यहाँ होता।
चलने से पहले सिम्युलेटेड
उस ग्राहक की सूची के एक वास्तविक संपर्क को फ़नल से ड्राई-रन करें और देखें कि उसे क्या भेजा जाता। हर तैनाती पर यह एक बार करें और "गलत चला गया" वाली बातचीत बंद हो जाती है।
एक जगह सुधारे गए
जब आप कुछ सीखते हैं — दूसरा अनुस्मारक सुबह दस बजे बेहतर काम करता है — तो अपनी परिभाषा बदलें और उसे आगे बढ़ाएँ। पुराना संस्करण चला रहे ग्राहक पुराने संस्करण पर पूरे होते हैं; बीच में चल रहे किसी को परेशानी नहीं होती।
क्रिएटिव भी
क्रिएटिव मर्ज वेरिएबल वाला दस्तावेज़ है। वही स्वागत ईमेल, हर ग्राहक के ब्रांड, रंगों और लोगो के साथ प्रस्तुत — पहली बार चलने पर उनकी अपनी वेबसाइट से लिया गया।
या एजेंट से करवाएँ
एक असिस्टेंट को MCP सर्वर की ओर इंगित करें, एक प्रोजेक्ट तक सीमित रखें, और उससे उस क्लाइंट के लिए फ़नल तैयार करवाएँ व जाँचवाएँ। जो कुछ भी किसी वास्तविक व्यक्ति तक पहुँचता है उसे अभी भी स्पष्ट पुष्टि चाहिए और वह कोटा के भीतर ही रहता है।
ग्यारह क्लाइंट, ग्यारह सेंडर, देखने के लिए एक ही जगह।
मासिक रिपोर्ट की समस्या
किसी एजेंसी की रिपोर्टिंग की पीड़ा ज़्यादातर आँकड़े बनाने की नहीं होती। यह ऐसे आँकड़े बनाने की होती है जो क्लाइंट के किसी अनुवर्ती प्रश्न का उत्तर देने के बाद भी टिक जाएँ, और उन्हें महीने की पहली तारीख़ को तीन घंटे स्क्रीनशॉट लेने में बिताए बिना बनाने की।
यहाँ दो चीज़ें मदद करती हैं। रिपोर्ट API रूट होती हैं, इसलिए मासिक पैक एक स्क्रिप्ट से तैयार करके PDF के रूप में निर्यात किया जा सकता है, न कि किसी व्यक्ति और स्प्रेडशीट से। और आँकड़े बॉट्स के बारे में ईमानदार होते हैं: कच्चे और फ़िल्टर किए गए दोनों उपलब्ध होते हैं, लेबल के साथ, ताकि जब कोई क्लाइंट पूछे कि उसके स्थानांतरण के बाद ओपन रेट क्यों गिरा, तो आप उसे एक वाक्य में समझा सकें न कि चार वाक्यों में बचाव करें।
वही टाइलें dash-b में पहुँचती हैं — कैंपेन प्रदर्शन, फ़नल ड्रॉप-ऑफ़, लिस्ट वृद्धि, डोमेन के अनुसार डिलिवरेबिलिटी — ताकि जो क्लाइंट लाइव बोर्ड चाहे, उसे मिल सके, उसके अपने खाते पर, उसके अपने क्रेडेंशियल्स के साथ और पेज पर आपकी कोई कुंजी नहीं।
- 1प्रत्येक प्रोजेक्ट के लिएएक टोकन, एक प्रोजेक्ट स्कोप, वही स्क्रिप्ट।
- 2पुल करेंकैंपेन प्रदर्शन, फ़नल ड्रॉप-ऑफ़, लिस्ट वृद्धि, डोमेन के अनुसार डिलिवरेबिलिटी।
- 3रेंडर करेंउनका क्रिएटिव दस्तावेज़ रिपोर्ट पेज के रूप में, फिर PDF में।
- 4भेजेंया उनके बोर्ड में डाल दें। जो उस क्लाइंट वास्तव में पढ़ता है, वही।
- iक्या बदलास्क्रीनशॉट के तीन घंटे एक निर्धारित जॉब बन गए, क्योंकि रिपोर्ट शुरू से रूट ही थीं।
कच्चे और फ़िल्टर किए गए, दोनों लेबल के साथ
सहमति की बातचीत, जल्दी ही हो जाती है
हर एजेंसी उस क्लाइंट से मिली है जो चार हज़ार पतों की स्प्रेडशीट और उनके स्रोत के बारे में एक अस्पष्ट उत्तर लेकर आता है। यहाँ यह कोई बहस नहीं है जिसे आपको जीतना है; यह एक फ़ील्ड है।
इंपोर्ट सबसे अधिक वैध हित (legitimate interest) के रूप में दर्ज होता है, कभी भी सहमति के रूप में नहीं, और आधारों का मिश्रण किसी भी कैंपेन के भेजे जाने से पहले दिखाया जाता है। यदि किसी लिस्ट को नहीं भेजा जा सकता, तो यह शिकायत के समय नहीं, बल्कि इंपोर्ट के समय ही बताया जाता है। इससे एक असहज निर्णय उसी स्क्रीन को साझा रूप से पढ़ने में बदल जाता है — जब क्लाइंट ज़िद करता है तो यह आपके लिए कहीं बेहतर स्थिति है।
क्लाइंट को स्पष्ट रूप से यह कहने लायक है: ख़राब लिस्ट से जो प्रतिष्ठा जोखिम में पड़ती है वह उसकी है, उसके अपने डोमेन पर, क्योंकि प्रत्येक प्रोजेक्ट अपने नाम से भेजता है। यह किसी भी नियम से अधिक प्रबल तर्क है, और यही वह है जो आमतौर पर असर करता है।