रेवेन्यू अट्रिब्यूशन के लिए एक सिंगल सोर्स ऑफ ट्रुथ बनाना

एक रेवेन्यू संगठन में तीन लोगों से पूछें कि पिछले क्वार्टर कितनी डील्स बंद हुईं और आपको शायद तीन नंबर मिलेंगे। मार्केटिंग ऑटोमेशन प्लेटफॉर्म से खींचती है, सेल्स CRM से, फाइनेंस बिलिंग से, और उनमें से हर एक अपने नंबर का बीस मिनट तक बचाव कर सकता है। हम उस मीटिंग में बैठे हैं। बिल्कुल तौर पर कोई गलत नहीं है। लेकिन एक बार जब बेसिक काउंट असहमत हो जाते हैं, हर अट्रिब्यूशन मॉडल जो उनके ऊपर बना है उस असहमति को विरासत में पाता है, और कोई भी मॉडलिंग सोफिस्टिकेशन एक ऐसे विश्लेषण को ठीक नहीं कर सकता जो परस्पर विरोधी तथ्यों से शुरू होता है।

अट्रिब्यूशन के लिए एक सिंगल सोर्स ऑफ ट्रुथ वह उबाऊ इंफ्रास्ट्रक्चर है जो बाकी सब कुछ विश्वसनीय बनाता है। यह कोई डैशबोर्ड नहीं है, और न ही वह स्प्रेडशीट है जिसे कोई महीने के आखिरी शुक्रवार को हाथ से मिलान करता है। यह एक गवर्न्ड डेटा लेयर है जहां आइडेंटिटी, इवेंट्स, और रेवेन्यू हर बार एक ही तरीके से जोड़े जाते हैं। यहां है इसे बनाने में असल में क्या लगता है।

नंबर क्यों अलग हो जाते हैं

फ्रैगमेंटेशन इस बात का संकेत नहीं है कि किसी ने बुरा काम किया। यह उसी के साथ होता है जो कोई भी बढ़ता हुआ स्टैक झेलता है। हर टूल जिसे आप अपनाते हैं, वह अपनी वास्तविकता के अपने हिस्से के लिए सिस्टम ऑफ रिकॉर्ड है, अपने आइडेंटिफायर्स, अपने टाइमस्टैंप, और चीज़ क्या है इसकी अपनी परिभाषाओं के साथ।

• CRM अकाउंट्स और अवसर जानता है, लेकिन कंपनी रिकॉर्ड पुराने या डुप्लिकेट हैं।
• मार्केटिंग प्लेटफॉर्म कॉन्टैक्ट्स और एंगेजमेंट जानता है, और अक्सर एक व्यक्ति को सही अकाउंट से नहीं जोड़ पाता।
• प्रोडक्ट डेटाबेस यूसेज जानता है, एक इंटरनल यूज़र ID से जुड़ा हुआ जो सेल्स साइड पर कुछ भी मैप नहीं करता।
• बिलिंग जानता है असल में क्या इनवॉइस हुआ, एक अकाउंट हायरार्की पर जो CRM की से मेल नहीं खाती।

इनमें से हर एक आंतरिक रूप से सुसंगत है और दूसरों के साथ असंगत है। यह वही स्थिति है जो आपका रेवेन्यू स्टैक क्यों फ्रैगमेंट हो रहा है के पीछे है। अट्रिब्यूशन वहां है जहां दर्द सबसे ज़ोर से बोलता है, क्योंकि अट्रिब्यूशन को इन सब को एक साथ जोड़ना पड़ता है।

तीन जॉइन पूरी चीज़ को संभालते हैं

एक काम करने वाला SSOT तीन आइडेंटिटी समस्याओं को हल करने पर आता है। इन्हें सही करें और ज़्यादातर डाउनस्ट्रीम एनालिसिस काबू में आ जाता है। इन्हें गलत करें और हर मॉडल चुपचाप भ्रष्ट हो जाता है, और आपको आमतौर पर तब तक पता नहीं चलता जब तक कोई सीनियर एक तीखा सवाल न पूछ ले।

कॉन्टैक्ट-टू-अकाउंट पहला है। हर व्यक्ति को सही कंपनी से रिज़ॉल्व होना चाहिए, ईमेल डोमेन, सब्सिडियरी, और वह पर्सनल Gmail एड्रेस जिससे एक VP ने एक वेबिनार के लिए साइन अप किया था, इन सबके पार। इसके बिना आप यह नहीं देख सकते कि एक अकाउंट के छह लोग सब आपका मूल्यांकन कर रहे हैं, जिसका मतलब है बाइंग-कमेटी एनालिसिस टेबल से बाहर है।

अकाउंट हायरार्की दूसरा है। पैरेंट, चाइल्ड, अधिग्रहीत ब्रांड, क्षेत्रीय डिवीज़न। अगर ये लगातार रोल अप नहीं होते, एक ग्लोबल अकाउंट एक दर्जन असंबंधित छोटे अकाउंट्स जैसा दिखता है और इसका रेवेन्यू ऐसे रिकॉर्ड्स में बिखर जाता है जिन्हें कोई नहीं जोड़ता।

टच-टू-रेवेन्यू तीसरा है। हर मार्केटिंग और सेल्स इंटरैक्शन को उस अवसर से जुड़ना चाहिए जिससे यह संबंधित है और, आखिरकार, उस रेवेन्यू से जो बिल किया गया, एक परिभाषा का उपयोग करते हुए कि एक अवसर के रूप में क्या गिना जाता है और यह कब शुरू होता है।

यहीं असली इंजीनियरिंग रहती है। फज़ी मैचिंग, डिटरमिनिस्टिक की, एनरिचमेंट, डीड्यूप। यह सब एक लक्ष्य की सेवा करते हैं: हर अकाउंट और व्यक्ति के लिए एक स्थिर, कैनोनिकल आइडेंटिटी जिस पर हर सिस्टम सहमत हो।

गवर्नेंस स्मार्ट SQL को हराता है

सहज विचार है इसे एक तकनीकी प्रोजेक्ट की तरह ट्रीट करना। सब कुछ वेयरहाउस में पाइप करें, कुछ मॉडल लिखें, हो गया। लेकिन हमारे अनुभव में प्लंबिंग शायद ही कभी फेल होती है। परिभाषाएं फेल होती हैं। अगर मार्केटिंग एक MQL को एक तरह से गिनती है और सेल्स एक क्वालिफाइड अवसर को दूसरी तरह से, स्टोरेज को एकीकृत करना बहस को बस एक अलग कमरे में ले जाता है।

तो एक टिकाऊ SSOT को इंजीनियरिंग के साथ गवर्नेंस चाहिए। इसका मतलब है अकाउंट, अवसर, स्टेज, और रेवेन्यू का एक सहमत मतलब, लिखा हुआ और किसी के स्वामित्व में। इसका मतलब है यह तय करना कि कौन सा सिस्टम किस तथ्य के लिए आधिकारिक है (रेवेन्यू के लिए बिलिंग, स्टेज के लिए CRM) और अब हर सिस्टम के वर्ज़न को बराबर मान्य नहीं मानना। इसका मतलब है कंज़्यूमर देख सकते हैं कि हर फील्ड कितनी ताज़ा है और यह कहां से आई, क्योंकि पिछले हफ्ते के स्नैपशॉट पर बना अट्रिब्यूशन गुमराह करेगा। और इसका मतलब है यूनिफाइड लेयर तक व्यापक पहुंच स्पष्ट स्वामित्व के साथ जोड़ी गई, ताकि परिभाषाएं एक क्वार्टर के भीतर वापस अलग न हो जाएं।

यह वह अनुशासन भी है जो नंबरों को फाइनेंस के संपर्क में जीवित रहने देता है, जो आपका CFO आपके अट्रिब्यूशन पर भरोसा क्यों नहीं करता का पूरा विषय है। CFO एक ज़्यादा सुंदर चार्ट नहीं चाहता। वे जानना चाहते हैं कि नंबर जनरल लेजर से मेल खाता है।

पर्याप्त आर्किटेक्चर, ज़्यादा नहीं

आपको शुरू करने के लिए दो साल की डेटा प्लेटफॉर्म इनिशिएटिव की ज़रूरत नहीं है, लेकिन आपको सही आकार चाहिए। व्यावहारिक वर्ज़न लेयर्ड है: हर सोर्स से रॉ इनजेशन, एक आइडेंटिटी-रिज़ॉल्यूशन स्टेप जो कैनोनिकल की असाइन करता है, एक मॉडल्ड लेयर जहां इवेंट्स गवर्न्ड परिभाषाओं के तहत अकाउंट्स और रेवेन्यू से जुड़ते हैं, और एक सर्विंग लेयर जो रिपोर्टिंग और एक्टिवेशन दोनों को फीड करती है। पूरा ब्लूप्रिंट रेवेन्यू प्लेटफॉर्म के लिए रेफरेंस आर्किटेक्चर में है।

दो चीज़ें इसे फूलने से रोकती हैं।

एक्टिवेशन के लिए भी मॉडल बनाएं, सिर्फ रिपोर्टिंग के लिए नहीं। एक SSOT जो सिर्फ डैशबोर्ड फीड करता है वह आधा बना है। वही यूनिफाइड लेयर रेप्स को लाइव सिग्नल्स और नेक्स्ट बेस्ट एक्शन फीड करनी चाहिए, जो बिखरे डेटा को नेक्स्ट बेस्ट एक्शन में बदलने का आधार है। अगर इकलौता कंज़्यूमर एक साप्ताहिक रिपोर्ट है, तो लेयर क्षय हो जाएगी क्योंकि कोई इस पर रोज़ निर्भर नहीं है।

और आइडेंटिटी रिज़ॉल्यूशन खरीदें। स्केल पर कॉन्टैक्ट-टू-अकाउंट मैचिंग इतनी हल हो चुकी समस्या है कि इसे खुद बनाना शायद ही कभी इंजीनियरों के लायक हो। Revnewo जैसे ऑर्केस्ट्रेशन प्लेटफॉर्म इस यूनिफिकेशन लेयर को नेटिव रूप से शिप करते हैं, ताकि टीम का समय प्लंबिंग के बजाय परिभाषाओं और एक्शन में जाए।

मुख्य बातें

• अगर बेसिक काउंट असहमत हैं, अट्रिब्यूशन मॉडल पहले से गलत है। वेटिंग पर बहस करने से पहले फाउंडेशन ठीक करें।
• फ्रैगमेंटेशन सामान्य है। हर टूल अपने हिस्से के लिए एक अच्छा सिस्टम ऑफ रिकॉर्ड है और बाकी सब के लिए एक बुरा।
• तीन जॉइन ज़्यादातर काम करते हैं: कॉन्टैक्ट से अकाउंट, अकाउंट हायरार्की, और टच से रेवेन्यू।
• परिभाषाएं और स्वामित्व मॉडलिंग की चालाकी से ज़्यादा मायने रखते हैं। असहमत परिभाषाओं के साथ यूनिफाइड स्टोरेज बहस को बस स्थानांतरित कर देती है।
• लेयर को इस तरह बनाएं कि यह रिपोर्ट के साथ एक्शन भी फीड करे, और आइडेंटिटी रिज़ॉल्यूशन को शुरू से फिर से न बनाएं।

इनमें से कुछ भी अट्रिब्यूशन का रोमांचक हिस्सा नहीं है। यह वह हिस्सा है जिस पर बाकी सब कुछ खड़ा है। अगर आप हर विश्लेषण से पहले परस्पर विरोधी नंबरों का मिलान कर रहे हैं, तो एक रेवेन्यू ऑर्केस्ट्रेशन प्लेटफॉर्म जो आइडेंटिटी और रेवेन्यू यूनिफिकेशन संभालता है, वही है जिससे आप यह रोक सकते हैं।