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