Google Analytics से Matomo में माइग्रेशन

Google Analytics से Matomo में कैसे जाएँ

Google Analytics से Matomo पर जाना सिर्फ़ दिखने में बदलाव नहीं है। यह रिपोर्टिंग में ऐसा बदलाव है जिसके नतीजे होते हैं, और सबसे सुरक्षित तरीका छोटे दायरे से शुरू होता है: एक साइट, एक प्रॉपर्टी, या एक कैंपेन सेट। अगर आप पहले ही दिन सब कुछ शिफ्ट करने की कोशिश करेंगे, तो पहला हफ़्ता पुराने टैग सुलझाने और आँकड़ों पर बहस करने में निकल जाएगा। इसी तरह का GA से Matomo माइग्रेशन तभी सफल होता है जब दायरा पहले से साफ़ हो।

शुरू करने से पहले तय करें कि “काम पूरा” का मतलब क्या है। ट्रैकिंग कोड छूने से पहले सफलता की परिभाषा लिख लें। एक व्यावहारिक लक्ष्य सीधा होता है: Matomo में मुख्य रिपोर्टें मौजूद हों, टीम उन्हें बिना मदद के पढ़ सके, और GA सिर्फ़ तुलना के लिए कटओवर के दौरान उपलब्ध रहे। इतना काफ़ी है। अगर आप एक वाक्य में मंज़िल नहीं बता सकते, तो माइग्रेशन का दायरा बहुत ढीला है। यही वजह है कि कई टीमें Matomo setup in Hindi जैसे सरल, साझा संदर्भ से शुरुआत करना पसंद करती हैं।

एक बात साफ़ शब्दों में कहनी चाहिए: Google Analytics से Matomo में कैसे जाएँ, यह टूल से कम और आपके सुरक्षित रखे गए रिपोर्ट दायरे से ज़्यादा जुड़ा है। एक छोटा ई-कॉमर्स साइट चेकआउट, प्रोडक्ट व्यू और कूपन उपयोग पर ध्यान दे सकती है; एक कंटेंट साइट लेख पढ़ने, स्क्रॉल की गहराई और न्यूज़लेटर साइनअप पर। साइट अलग, cutover अलग। अनुशासन वही।

1. तय करें कि इस माइग्रेशन के लिए “काम पूरा” क्या है

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

ऐसी सफलता-शर्तें लिखें जिन्हें 10 मिनट में जाँचा जा सके, 10 दिनों तक बहस नहीं करनी पड़े। उदाहरण के लिए: “Matomo में Site A के sessions, conversions और top landing pages दिख रहे हैं,” और “GA 2 हफ़्तों तक सिर्फ़ तुलना के लिए live रहेगा।” ये दो लाइनें टीम को सीमा देती हैं। इनके बिना कोई न कोई सबसे खराब समय पर एक और dashboard माँग ही लेगा।

एक failure line भी तय करें। अगर Matomo सेटअप मुख्य conversion पकड़ नहीं रहा, या overlap अवधि में बिज़नेस आँकड़े सत्यापित नहीं कर पा रहा, तो cutover तैयार नहीं है। यह सख़्त लगता है। लेकिन समय बचाता है।

2. उस Google Analytics डेटा की सूची बनाएँ जिसे खोना नहीं है

कुछ भी शिफ्ट करने से पहले GA की उन चीज़ों की सूची बनाइए जो महत्वपूर्ण हैं। उन dashboard को शामिल करें जिन्हें लोग हर सुबह खोलते हैं, custom dimensions जिन्हें business meaning है, revenue से जुड़े events, conversions, audiences, filters, और attribution-सम्बंधी settings। इस सूची के बिना माइग्रेशन बस अनुमान है, बस नाम थोड़ा अच्छा है।

नाम लिखिए, विवरण नहीं। “Paid search dashboard” “marketing stuff” से बेहतर है। “Lead form submit event” “contact actions” से बेहतर है। अगर किसी report का असली owner है, तो उसके नाम के साथ लिखें। यह छोटा कदम तब काम आता है जब बाद में कोई कहे, “मुझे लगा sales team वह filter इस्तेमाल करती थी।”

कुछ GA items का one-to-one rebuild करना ज़रूरी नहीं होगा। यह सामान्य है। पिछले साल का कोई कम इस्तेमाल हुआ audience segment अगर कभी निर्णय में काम नहीं आया, तो उसे Matomo में दोबारा बनाना शायद लायक नहीं। मक़सद हर object को बचाना नहीं; मक़सद उस 20% को बचाना है जो लोग सच में इस्तेमाल करते हैं।

अगर सूची बनाते समय आपको एक आसान संदर्भ चाहिए, तो odd pages और niche reports के लिए अलग checklist रखें। यही आदत दूसरी जगह भी काम आती है; उदाहरण के लिए, साइट पेज सत्यापित करने वाली टीम वेबसाइट कैसे जाँचें को quick reference pattern की तरह इस्तेमाल कर सकती है। नाम बदलता है, नियम वही रहता है: खोजने से पहले जानिए क्या ढूँढना है।

3. GA की अवधारणाओं को Matomo के समकक्ष से मिलाएँ

दो कॉलम वाली translation sheet बनाएँ: GA term और Matomo term या method. जो सीधे match होते हैं और जो नहीं होते, दोनों लिखें। page views, events, goals, segments, custom dimensions, और campaign tracking सब इस शीट में होने चाहिए। यहीं माइग्रेशन सैद्धांतिक से व्यावहारिक बनता है।

कुछ mapping आसान होती हैं। कुछ नहीं। GA audiences को Matomo segments या किसी अलग reporting rule में बदलना पड़ सकता है। GA की कोई attribution setting Matomo में वैसा व्यवहार न करे, इसलिए हो सकता है आपको पुराने जवाब को नए टूल में ठूँसने के बजाय सवाल ही बदलना पड़े। यह लिखें, क्योंकि dashboards स्क्रीन पर आते ही लोग जल्दी भूल जाते हैं।

एक कॉलम “same idea, different logic” के लिए रखें। यह कॉलम महत्वपूर्ण है। अगर GA किसी metric को एक तरह से निकालता था और Matomo दूसरी तरह से, तो टीम को आँकड़े देखने से पहले यह पता होना चाहिए। वरना उन्हें लगेगा माइग्रेशन टूट गया है, जबकि असली समस्या definition बदलने की है।

जिन टीमों के पास पहले से structured reference pages होती हैं, उनके लिए यह mapping उसी तरह काम करती है जैसे p से शुरू होने वाले स्वप्न शब्दकोशमें सावधानी से lookup करना: एक term, एक जगह, एक मतलब। टूल अलग हो सकता है, आदत जानी-पहचानी है। पहले मिलान करें, बाद में बहस।

4. कम जोखिम वाले transition के लिए cutover की योजना बनाएँ

माइग्रेशन की तारीख सोच-समझकर चुनें। product launch, campaign peak, और reporting deadlines से बचें। सोमवार सुबह का cutover अक्सर शोर पैदा करता है; शांत midweek slot आमतौर पर जाँचना आसान होता है। एक नाटकीय बदलाव से बेहतर है कम जोखिम वाला transition।

तय करें कि overlap period 3 दिन चलेगा, 1 हफ़्ता, या उससे ज़्यादा। overlap इतना लंबा होना चाहिए कि results की तुलना हो सके, लेकिन इतना नहीं कि आदत में लोग दो सिस्टम ज़िंदा रखें। उस अवधि में तय करें कि रिपोर्ट कौन जाँचता है, कौन sign-off देता है, और आँकड़े गलत दिखें तो कौन move रोक सकता है।

validation के लिए एक ही owner तय करें। तीन नहीं। एक व्यक्ति analytics, product, और marketing से feedback इकट्ठा कर सकता है, लेकिन call उसी की होनी चाहिए। अगर cutover का owner सब हैं, तो असल में कोई नहीं। तभी छोटे tracking issues महीनों तक बने रहते हैं।

access changes पर तब तक हाथ न डालें जब तक overlap स्थिर न हो जाए। अगर आप GA access बहुत जल्दी कम कर देंगे, लोग घबरा कर side spreadsheets बनाने लगेंगे। अगर बहुत देर करेंगे, वे Matomo इस्तेमाल करना ही बंद कर देंगे। यहाँ timing, ceremony से ज़्यादा मायने रखती है।

5. सबसे महत्वपूर्ण reports पहले Matomo में बनाइए

हर GA view की नकल करने की कोशिश मत कीजिए। पहले daily reports फिर से बनाइए: source के हिसाब से traffic, top pages, मुख्य conversions, और वे कुछ segments जिन्हें टीम हर हफ़्ते जाँचती है। अगर कोई report किसी निर्णय को प्रभावित नहीं करता, उसे बाद के लिए छोड़ दें। यही वह जगह है जहाँ कई migrations बेवजह धीमे पड़ जाते हैं।

जहाँ संभव हो Matomo-native settings का इस्तेमाल करें। GA की हूबहू नकल आरामदेह लग सकती है, लेकिन इससे बाद में अतिरिक्त maintenance हो सकता है। बेहतर कदम है पुराने screenshot की नकल नहीं, बल्कि business question को फिर से बनाना। अगर GA में चार tabs थे और Matomo वही सवाल दो panels में सुलझा सकता है, तो दो panels लें।

सबसे ज़्यादा दिखाई देने वाली reports पहले लाएँ, उससे पहले कि कोई माँग करे। अगर sales हर सुबह lead quality पूछती है और marketing हर दोपहर campaign traffic, तो इन्हीं दो reports को पहले फिर से बनाएँ। बाकी इंतज़ार कर सकती हैं। लोग Monday report गुम होने को edge case से ज़्यादा गंभीरता से लेते हैं।

कुछ टीमों को reports की सूची के बीच काम करते समय दूसरे site-reference workflows जाँचना उपयोगी लगता है, खासकर अगर उनका content कई पेजों में फैला हो। एक व्यावहारिक उदाहरण है वेबसाइट कैसे जाँचें, जो ठीक उस page को verify करने का महत्व दिखाता है जिसकी उपयोगकर्ता को उम्मीद होती है। Reporting भी ऐसी ही है: report वही होना चाहिए जिसे लोग सच में इस्तेमाल करते हैं।

6. वास्तविक user actions के साथ event और goal tracking की पुष्टि करें

सिर्फ़ page load नहीं, असली actions टेस्ट करें। फ़ॉर्म submit करें, purchase पूरा करें, file डाउनलोड करें, और outbound link पर क्लिक करें। फिर जाँचें कि Matomo ने हर action को उस तरह दर्ज किया या नहीं जैसा business को चाहिए। तेज़ testing उपयोगी है, लेकिन व्यवस्थित testing rework बचाती है।

Test cases छोटे और विशिष्ट रखें। “Pricing page से contact form submit” “funnel टेस्ट” से बेहतर है। “Coupon code के साथ checkout complete” “purchase test” से बेहतर है। साफ़ action साफ़ bug देता है। धुँधला testing सौम्य भ्रम पैदा करता है।

Overlap अवधि में GA के साथ results की तुलना करें, लेकिन एकदम identical output की उम्मीद न करें। अलग tools consent handling, timing, या setup details के कारण थोड़ा अलग count कर सकते हैं। अहम सवाल यह है कि क्या Matomo वही business action भरोसेमंद तरीके से पकड़ रहा है। अगर नहीं, तो cutover से पहले tag या goal rule ठीक करें।

यह edge cases लिखने का भी अच्छा समय है। उदाहरण के लिए, जो download नए tab में खुलता है, उसे standard link click से अलग trigger चाहिए हो सकता है। एक rule अक्सर हर behavior को पहली बार में नहीं पकड़ता। यह सामान्य है, और इसी वजह से test list इतनी छोटी होनी चाहिए कि उसे एक ही दोपहर में दोहराया जा सके।

7. टीम को Matomo के reporting workflow पर प्रशिक्षित करें

Analysts और stakeholders को 30 मिनट की walkthrough दें, फिर उन 3 या 4 reports के लिए लिखित रास्ता दें जिन्हें वे सबसे ज़्यादा इस्तेमाल करते हैं। दिखाइए कि segments कहाँ हैं, annotations कैसे संभाली जाती हैं, और कौन-सी GA आदतें अब लागू नहीं होतीं। लोगों को हर menu पर lecture नहीं चाहिए। उन्हें बस यह जानना है कि Monday का जवाब कहाँ मिलेगा।

Migrated site के असली examples का इस्तेमाल करें। lead report, product report, और landing page report खोलें। filters पर क्लिक करके दिखाएँ। अगर आप marketing team द्वारा GA में इस्तेमाल किए गए exact नाम के साथ campaign report दिखा सकें, तो सीखने की रफ़्तार तुरंत बढ़ जाती है। Screenshot मदद करते हैं, लेकिन live clicks और बेहतर हैं।

फर्क साफ़-साफ़ समझाएँ। अगर GA-style audience अब Matomo segment है, तो यह कहें। अगर saved report की जगह बदल गई है, तो यह भी कहें। अगर कोई stakeholder उस metric के बारे में पूछे जो अब उसी रूप में मौजूद नहीं है, तो पुराने tool की कहानी नहीं, नया workflow बताइए। लोग सीधे जवाब से तेज़ी से ढलते हैं।

कुछ टीमों के पास बार-बार होने वाले lookups के लिए छोटा reference होता है, और उसमें content pages भी शामिल हो सकती हैं। अगर टीम knowledge pages के साथ काम करती है, तो k से शुरू होने वाला स्वप्न शब्दकोश जैसा लिंक इस बात की याद दिलाता है कि व्यवस्थित categories search time घटाती हैं। Reporting training भी ऐसा ही है: एक काम के लिए एक जगह।

8. Handoff के बाद GA dependencies बंद करें

जब सहमत reporting scope Matomo में स्थिर हो जाए, तब बची हुई हर GA dependency की सूची बनाएँ। इसमें dashboards, tags, alerts, docs, SOPs, browser bookmarks, और वे scripts शामिल हैं जो अभी भी GA की ओर इशारा कर रहे हैं। इनमें से किसी को भी अनदेखा न छोड़ें। पुराने links “done” होने के बाद भी काफ़ी समय तक ज़िंदा रहते हैं।

Items को एक-एक करके हटाएँ या फिर से लिखें। Dashboard note जो कहती है “GA जाँचें” उसे “Matomo जाँचें” बनना चाहिए। Runbook जो किसी को हर सुबह GA से तुलना करने को कहता है, उसे नई प्रक्रिया के अनुसार अपडेट करें, या अगर वह अब उपयोगी नहीं है तो archive कर दें। यहाँ छोटे cleanup tasks मायने रखते हैं क्योंकि वे पुरानी आदतों को वापस आने से रोकते हैं।

एक आख़िरी comparison checkpoint रखें, फिर migrated scope के लिए GA window बंद करें। अगर टीम को historical reference के लिए अभी भी GA चाहिए, तो उसे read-only उपयोग तक सीमित करें और review date तय करें। अगर नहीं, तो access कम करें और routine checks हटा दें। जितना लंबा GA रोज़मर्रा के workflow का हिस्सा रहेगा, उतना ही कठिन होगा यह बताना कि truth source कौन-सा सिस्टम है।

इस चरण में एक साधारण maintenance आदत मदद करती है: active reports की समीक्षा हर महीने करें, हर quarter नहीं। 15 मिनट की समीक्षा पुरानी dashboards को अगले campaign owner को भ्रमित करने से पहले पकड़ लेती है। अभी की गई छोटी सफ़ाई बाद में दूसरी migration से सस्ती पड़ती है।