एक फनेल, वीस ग्राहक, वीस स्वतंत्र प्रतिष्ठा

प्रत्येक ग्राहकासाठी एक प्रोजेक्ट, आणि ती सीमा राखणे हे डेटाबेसचे काम

येथे सर्व काही टेनंट आणि प्रोजेक्ट या दोघांच्या व्याप्तीत असते — संपर्क, फनेल, क्रिएटिव्ह्ज, मोहिमा, पाठवण्याच्या ओळखी, अहवाल. ही व्याप्ती डेटाबेसमधील रो-लेव्हल सुरक्षेने लागू केली जाते; क्वेरीमध्ये कोणी लक्षात ठेवून जोडावी अशा अटीने नाही. विसरलेला प्रोजेक्ट पहिल्या प्रोजेक्टच्या पंक्ती न पाहता काहीही पाहू शकत नाही.

याचा अर्थ असा की एका ग्राहकाची यादी चुकून दुसऱ्या ग्राहकाच्या मोहिमेत जाऊ शकत नाही, आणि अहवाल एका ग्राहकाविषयीच असतो कारण तो रचनेतूनच दोघांविषयी असू शकत नाही.

प्रत्येक ग्राहक स्वतःच्या नावाने पाठवतो

पाठवण्याची ओळख एका प्रोजेक्टशी संबंधित असते: त्यांचे डोमेन, त्यांच्या DKIM कीज, त्यांचे मेलबॉक्स किंवा त्यांचे प्रोव्हायडर खाते, त्यांची दरमर्यादा. एका ग्राहकाची बिघडलेली मोहीम दुसऱ्या ग्राहकाच्या वितरणक्षमतेस इजा करू शकत नाही, कारण इजा करण्याजोगे काहीही ते कधी शेअर करत नव्हते.

यामुळे एक अवघड संवाद लवकरच सुटतो. पाठवणे, यादी आणि संमतीचा नोंदीकरण ग्राहकाचाच असतो. जेव्हा तो निघून जातो — आणि काही जाणारच — तेव्हा तो सर्वस्व घेऊन जातो, आणि तुम्ही असे विनंतीचे स्थान उभे केलेले नसते जे स्पष्ट करावे लागेल.

मासिक अहवालाची समस्या

एजन्सीच्या अहवालाच्या वेदनेचा बहुतेक भाग आकडे तयार करणे नसतो. तो असे आकडे तयार करणे असतो जे ग्राहकाच्या पुढील प्रश्नाला टिकतात, आणि महिन्याच्या पहिल्या दिवशी तीन तास स्क्रीनशॉट घेता घेता नव्हे तर तयार करणे असतो.

येथे दोन गोष्टी मदत करतात. अहवाल API रूट्स असतात, त्यामुळे मासिक संच स्क्रिप्टने जोडता येतो आणि PDF म्हणून निर्यात करता येतो; व्यक्ती आणि स्प्रेडशीटने नाही. आणि आकडे बॉट्सबाबत प्रामाणिक असतात: कच्चे आणि गाळलेले दोन्ही उपलब्ध असतात, लेबलसह, त्यामुळे ग्राहक जेव्हा विचारतो की त्यांचे स्थलांतर झाल्यावर उघडण्याचा दर का घसरला, तेव्हा तुम्ही ते एका वाक्यात स्पष्ट करू शकता, चार वाक्यांत बचाव करावे लागत नाही.

तेच टायल dash-b मध्ये येतात — मोहिमेची कामगिरी, फनेलमधील गळती, यादीची वाढ, डोमेननुसार वितरणक्षमता — त्यामुळे जिवंत बोर्ड हवा असलेल्या ग्राहकाला तो मिळू शकतो, त्यांच्याच खात्यावर, त्यांच्याच क्रेडेन्शियल्ससह आणि पानावर तुमची कोणतीही की नसताना.