Matomo से गोपनीयता-प्रथम एनालिटिक्स में एनालिटिक्स कैसे माइग्रेट करें

Matomo के साथ माइग्रेट करने की आवश्यकता क्यों है

प्राइवेसी-फर्स्ट एनालिटिक्स पर स्विच करना आमतौर पर इंटरफेस से नहीं, बल्कि इस सवाल से शुरू होता है: Matomo को बदलने की आवश्यकता क्यों है। इसके तीन उत्तर हैं। पहला - प्राइवेसी की आवश्यकताएँ, दूसरा - डेटा संग्रह को सरल बनाना, तीसरा - कुकीज़ पर निर्भरता को कम करना। यदि आपकी वेबसाइट की ऑडियंस EU से है, चिकित्सा परियोजना है या बस एक टीम है जो उपयोगकर्ता सहमति को बार-बार छूना नहीं चाहती, तो आपके पास पहले से ही एक कारण है।

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

एक व्यावहारिक तर्क भी है। जब डेटा संग्रह कुकीज़ पर कम निर्भर होता है, तो मार्केटर्स, वकीलों और डेवलपर्स को लॉजिक समझाना आसान होता है। सभी के लिए नहीं। लेकिन अक्सर - हाँ।

यदि Matomo का उपयोग केवल बुनियादी घटनाओं के लिए किया जाता है, गहन अनुकूलन नहीं है, और रिपोर्ट 5-7 नियमित निर्णयों के लिए आवश्यक हैं, तो माइग्रेशन आमतौर पर नाटकीय नुकसान के बिना होता है। जब Matomo में खंड, ईकॉमर्स और लंबी लक्ष्य श्रृंखलाएँ शामिल होती हैं, तो वहाँ एक योजना की आवश्यकता होती है, न कि उत्साह की।

स्थानांतरण से पहले क्या तैयार करें

स्थानांतरण से पहले 5 डेटा समूह एकत्र करें: लक्ष्य, घटनाएँ, ट्रैफ़िक स्रोत, Matomo रिपोर्ट, एकीकरण और साइट तक पहुँच। इसके बिना, माइग्रेशन एक अनुमान में बदल जाता है। और हाँ, अनुमान लगभग हमेशा महंगा होता है।

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

फिर घटनाओं पर जाएँ। Matomo में इन्हें विभिन्न तरीकों से चिह्नित किया जा सकता है: कुछ JavaScript के माध्यम से, कुछ GTM के माध्यम से, कुछ सर्वर कॉल के माध्यम से। यहाँ एक तालिका या कम से कम एक दस्तावेज़ जिसमें 'घटना', 'श्रेणी', 'क्रिया', 'लेबल', 'पृष्ठ', 'नोट' के कॉलम हों, उपयोगी होगा। ऐसी सूची पुराने सेटिंग्स को समझने में घंटों की बचत करती है।

अलग ब्लॉक — ट्रैफ़िक स्रोत। यह सहेजें कि आपके पास वास्तव में कौन से UTM-टैग का उपयोग किया जा रहा है, कौन से चैनल विज्ञापन खातों से जुड़े हैं, कौन सी अभियान छोटे लिंक या रीडायरेक्ट के साथ आते हैं। इसके बिना, नई प्रणाली विज़िट इकट्ठा कर सकती है, लेकिन आप नहीं समझेंगे कि उपयोगकर्ता कहाँ से आया। और यह पहले से ही विश्लेषण का नहीं, बल्कि निर्णयों का मुद्दा है।

इंटीग्रेशन के बारे में न भूलें। CRM, कॉल ट्रैकिंग, फॉर्म, चैट, सर्वर-साइड इवेंट भेजना, BI-पैनल — इन सभी को शुरू करने से पहले सूचीबद्ध करना आवश्यक है। यदि साइट, GTM, CMS या CDN के लिए पहुंच की कमी है, तो उन्हें पहले से अनुरोध करना बेहतर है। अन्यथा, स्थानांतरण दूसरे चरण पर रुक जाएगा।

Matomo और नई प्रणाली के मेट्रिक्स का मिलान

मेट्रिक्स की तुलना सरल से शुरू करें: पृष्ठ, घटनाएँ, रूपांतरण, UTM-टैग और उपयोगकर्ता खंड। सब कुछ तुरंत मिलाने की कोशिश न करें। पहले बुनियादी चीजें, फिर बारीकियाँ। इस तरह से विधियों के बीच अंतर में उलझने की संभावना कम होती है।

Matomo और नई प्रणाली में पृष्ठ आमतौर पर URL के अनुसार मेल खाते हैं, लेकिन हमेशा सामान्यीकरण के नियमों के अनुसार नहीं। जांचें कि स्लैश, पैरामीटर, एंकर और रीडायरेक्ट कैसे ध्यान में रखे जाते हैं। यदि नियम भिन्न हैं, तो एक ही पथ तीन अलग-अलग स्ट्रिंग्स के रूप में दिखाई दे सकता है। ई-कॉमर्स के लिए, यह विशेष रूप से उत्पाद कार्ड और फ़िल्टर पर स्पष्ट होता है।

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

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

UTM-टैग को 2 स्तरों पर जांचें: वे प्रणाली में कैसे आते हैं और फिर रिपोर्ट में कैसे प्रदर्शित होते हैं। कभी-कभी अंतर अक्षरों के केस के कारण होता है, कभी-कभी अभियानों के ऑटोफिल के कारण, कभी-कभी पैरामीटर को काटने वाले रीडायरेक्ट के कारण। आंतरिक खंडों का भी वर्णन करना चाहिए: नए उपयोगकर्ता, लौटने वाले, ईमेल से ट्रैफिक, किसी विशेष देश के उपयोगकर्ता। बिना विवरण के खंड लगभग हमेशा भविष्य की गलती होती है।

प्राइवेसी-फर्स्ट एनालिटिक्स सेटअप

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

आंतरिक विज़िट की फ़िल्टरिंग तुरंत आवश्यक है। यदि 12 लोगों की टीम दिन में 20 बार साइट खोलती है, तो एनालिटिक्स जल्दी ही अर्थ खो देती है। कार्यालय के आईपी, परीक्षण उपकरण, स्टेजिंग-डोमेन और यदि आवश्यक हो, तो कर्मचारियों के अलग-अलग खातों को बाहर करें। अन्यथा, आप उन लोगों से 'वृद्धि' देखेंगे जिन्होंने बस बटन की जांच की।

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

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

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

घटनाओं, लक्ष्यों और फ़नल का स्थानांतरण

इवेंट्स को प्राथमिकता के अनुसार स्थानांतरित करें: पहले 5-10 सबसे मूल्यवान क्रियाएँ, फिर बाकी। यदि आपके पास ईकॉमर्स है, तो add to cart, begin checkout, purchase से शुरू करें, और फिर फ़िल्टर व्यूज़ और सिफारिशी ब्लॉक्स पर क्लिक जोड़ें। लॉजिक सरल है: जो पैसे पर प्रभाव डालता है, वह पहले स्थानांतरित होता है।

Matomo में लक्ष्य अक्सर धन्यवाद पृष्ठों या विशिष्ट URL के चारों ओर बनाए जाते थे। नई प्रणाली में यह दृष्टिकोण भी संभव है, लेकिन इसे तकनीकी कार्यान्वयन के साथ फिर से देखना बेहतर है। कभी-कभी फॉर्म AJAX के माध्यम से भेजा जाता है और उपयोगकर्ता एक अलग पृष्ठ पर नहीं जाता — तब इवेंट का रिकॉर्डिंग आवश्यक है, न कि पृष्ठ का। इससे अधिक सटीक और शांतिपूर्ण होता है।

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

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

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

माइग्रेशन के बाद डेटा की गुणवत्ता की जांच

लॉन्च के पहले 3-7 दिन 'निगरानी' नहीं, बल्कि मिलान करने का समय है। पुराने और नए रिपोर्ट को पास में खोलें और पृष्ठों, घटनाओं, रूपांतरणों, स्रोतों की तुलना करें। भिन्नताएँ लगभग अनिवार्य हैं। सवाल केवल यह है कि क्या आप उन्हें समझा सकते हैं।

जांच को मैनुअल परीक्षणों से शुरू करें। वेबसाइट पर जाएं, 2-3 पृष्ठ खोलें, कुछ बटन दबाएं, फॉर्म भेजें, UTM लिंक पर जाएं। फिर देखें कि क्या नई प्रणाली में घटनाएँ आईं और क्या उपयोगकर्ता का मार्ग टूट गया। ऐसा परीक्षण साधारण लगता है, लेकिन यही 80% त्रुटियों को पकड़ता है।

अलग से रेफरल ट्रैफ़िक की जांच करें। अक्सर यह रीडायरेक्ट, गलत अपवाद सूची या कुकी-लेस मोड सेटिंग के कारण गायब हो जाता है। विज्ञापन क्लिक के साथ भी गलतियाँ होती हैं: UTM पढ़े जाते हैं, लेकिन चैनल 'direct' में चला जाता है मध्यवर्ती पृष्ठ के कारण। यदि ऐसा हुआ है, तो प्लेटफ़ॉर्म को दोष देने में जल्दी न करें; पहले ट्रैफ़िक के प्रवाह को देखें।

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

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

पारगमन के बाद पुराने Matomo के साथ क्या करें

पारगमन के बाद Matomo को तुरंत हटाना आवश्यक नहीं है। अक्सर 3 विकल्प छोड़े जाते हैं: आर्काइव, संग्रह को स्थिर करना या पूरी तरह से बंद करना। चयन कानूनी आवश्यकताओं, भंडारण की अवधि और यह कि टीम कितनी बार पुराने रिपोर्टों पर लौटती है, पर निर्भर करता है।

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

पुरानी स्थापना का पूर्ण रूप से बंद करना सभी के लिए उपयुक्त नहीं है। कभी-कभी Matomo 30-60 दिनों के लिए एक बैकअप के रूप में रहता है, ताकि छूटे हुए घटनाओं या विवादास्पद भिन्नताओं को पकड़ सके। फिर इसे हटा दिया जा सकता है, जब नई विश्लेषण स्थिरता से सभी आवश्यक क्रियाओं को एकत्रित करती है।

शुरुआत चेकलिस्ट और स्थानांतरण के बाद की निगरानी

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

स्थानांतरण के पहले दिनों में, विश्लेषण के लिए एक व्यक्ति को जिम्मेदार नियुक्त करें। एक टीम नहीं, बल्कि एक व्यक्ति। वह लॉग देखता है, रिपोर्टों की तुलना करता है, त्रुटियों को एकत्र करता है और सवाल का जवाब देता है कि 'संपर्क' पृष्ठ पर अचानक 0 घटनाएँ क्यों हैं। यह मोड विशेष रूप से उपयोगी होता है, जब प्रोजेक्ट में एक साथ रिलीज और विज्ञापन अभियान चल रहा हो।

फिर एक नियमित समीक्षा शुरू करें - हर 2 सप्ताह में या हर महीने, ट्रैफ़िक के आधार पर। नए फॉर्म, नए बटन, नए लैंडिंग पृष्ठ, नए विज्ञापन UTM और सहमति बैनर में बदलाव की जांच करें। वेबसाइट पर कोई भी संशोधन विश्लेषण को प्रभावित कर सकता है, भले ही डेवलपर कसम खाए कि "हमने केवल पाठ बदला है।"

और एक और छोटा, लेकिन सामान्य बिंदु: सभी परिवर्तनों की सूची एक ही स्थान पर रखें। जब 3 महीने बाद आपको यह समझाना होगा कि क्यों प्राइवेसी-फर्स्ट एनालिटिक्स में घटनाओं का प्रवाह बदल गया है, तो आप खुश होंगे कि आप चैट, टिकट और एक थके हुए मार्केटर की याददाश्त में इतिहास की खोज नहीं कर रहे हैं।