सभी डेटा प्राप्त करने के लिए ई-कॉमर्स लेआउट प्रक्रिया का निर्माण कैसे करें

परिचय

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

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

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

यह लेख Google Analytics ई-कॉमर्स को एक बड़ी परियोजना में एकीकृत करने के लिए एक प्रभावी प्रक्रिया का निर्माण करने पर ध्यान केंद्रित करेगा। एक बड़ी परियोजना से, हमारा मतलब है कि किसी भी आकार की साइट जो कम से कम ऐसी टीम के साथ काम करती है: वेब एनालिटिक्स, फ्रंटएंड और बैकेंड डेवलपर्स, बिजनेस एनालिस्ट और प्रोडक्ट ओनर। और, ज़ाहिर है, इस परियोजना को निर्णय लेने के लिए वेब एनालिटिक्स डेटा की आवश्यकता है, न कि केवल इसके विकास बैकलॉग से कार्य को बंद करने के लिए।

त्याग

लेख में वर्णित सब कुछ विशेष रूप से हमारा अनुभव है। यदि आपने इसे अलग तरीके से किया है, तो इसका मतलब है कि आपने इसे अलग तरीके से किया है।

कई, ई-कॉमर्स बाजार के बड़े खिलाड़ी भी अब तक सफल नहीं हुए हैं। ई-कॉमर्स डेटा मोर्चे पर प्रसारित किया जाता है, इसलिए आप इसे कंसोल या GET अनुरोधों जैसे https : //www.google-analytics.com/r/collect / ..., या Google Chrome में Google Analytics डीबगर एक्सटेंशन के साथ थोड़ा और आसानी से देख सकते हैं। । इसलिए, आप जल्दी से चेक कर सकते हैं कि DataInsight के अनुसार, रूस के सबसे बड़े ऑनलाइन स्टोरों में से कौन - सा टॉप -100 सभी डेटा पर नज़र रखता है।

एक चरण: हितधारकों की पहचान करें और उनकी डेटा आवश्यकताओं को एकत्र करें

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

1. व्यापार प्रतिनिधि

उपयोग किए गए डेटा के आधार पर, व्यापार प्रतिनिधियों के वेब एनालिटिक्स सिस्टम को कई भागों में विभाजित किया जा सकता है:

1. विभिन्न ट्रैफ़िक चैनलों में इंटरनेट मार्केटिंग और विशेषज्ञ वे हैं जो ट्रैफ़िक का विश्लेषण और अनुकूलन करने के लिए वेब एनालिटिक्स सिस्टम का उपयोग करते हैं। इस समूह की इलेक्ट्रॉनिक वाणिज्य डेटा के लिए कोई विशेष आवश्यकता नहीं है। यह पर्याप्त है कि लेनदेन और आय पर डेटा प्रेषित किया जाएगा।
2. श्रेणी प्रबंधक और खरीद - वे जो सामान पर डेटा का विवरण करने के लिए मौलिक हैं। इस समूह की मुख्य आवश्यकता उत्पाद विशेषताओं द्वारा इलेक्ट्रॉनिक वाणिज्य के प्रमुख संकेतक प्राप्त करने की क्षमता है।
3. व्यक्तिगत परियोजनाओं या क्षेत्रों के नेता आमतौर पर अपने कार्यों में बहुत सार्वभौमिक होते हैं, इसलिए वे पिछले दो समूहों की आवश्यकताओं को जोड़ते हैं।

2. उत्पाद टीम

एक उत्पाद टीम में विभिन्न भूमिकाएं हो सकती हैं: डेवलपर्स, व्यापार विश्लेषक, परियोजना प्रबंधक, डिजाइनर, उत्पाद के मालिक। लेकिन हर किसी का एक काम है: उत्पाद को बेहतर बनाना। और यदि संभव हो, तो सुधार करें, न केवल उनकी प्राथमिकताओं को समझना, बल्कि एक या दूसरे कार्यात्मक के उपयोग की आवृत्ति भी।

यह एनालिटिक्स डेटा की मुख्य आवश्यकता है। लेकिन यह मत भूलो कि डेटा प्राप्त करने के बाद, उत्पाद टीम ए / बी परीक्षणों के ढांचे में परिकल्पना उत्पन्न करती है और परीक्षण करती है।

3. उत्पाद विश्लेषिकी (या वेब विश्लेषिकी)

उत्पाद निर्णय लेने के लिए आवश्यक इन वेब विश्लेषिकी प्रणालियों की अखंडता और स्थिरता के लिए जिम्मेदार टीम। इस प्रक्रिया में उत्पाद विश्लेषकों का कार्य डेटा गुणवत्ता है। इसके अलावा, वे समझते हैं कि Google Analytics डेटा कैसे एकत्र और संसाधित करता है। इसलिए, यह वह है जो बाकी टीमों से सभी आवश्यकताओं को इकट्ठा करना चाहिए।

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

इस प्रक्रिया के अंत में, आपको स्पष्ट रूप से समझना चाहिए:

1. श्रेणी प्रबंधकों के कार्यों को हल करने के लिए उपयोगकर्ता पैरामीटर और संकेतक बनाने की आवश्यकता है।
2. उत्पाद टीम को किन प्रमुख संकेतकों की आवश्यकता है और यह कहाँ असंभव है और अन्य लेखा प्रणालियों के डेटा का उपयोग करना होगा।

स्टेज दो: उत्पाद टीम के साथ डेटा कार्यान्वयन की चर्चा

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

स्टेज तीन: डेटा ट्रांसफर समाधान का विवरण

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

Google Analytics कोड को सीधे साइट कोड में डालें

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

इस विकल्प के प्लस:

• यह बहुत सरल दिखता है और एकत्र किए गए डेटा की स्थिरता की भावना देता है।

इस विकल्प के विपक्ष:

• किसी भी विकास त्रुटि डेटा हानि की ओर जाता है;
• उसी डेटा को दूसरे एनालिटिक्स सिस्टम में ट्रांसफर करने का कोई तरीका नहीं है।

सामान्य तौर पर, हम किसी को भी इस विकल्प का उपयोग करने की सलाह नहीं देते हैं।

साइट पर रखें Google टैग प्रबंधक और डेटा को डेटालेयर में स्थानांतरित करें

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

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

इस दृष्टिकोण के किसी भी संस्करण में, विकास टीम पर सबसे बड़ा बोझ पड़ता है। वेब विश्लेषकों के लिए डेटा को लगभग उस रूप में पढ़ना और संचारित करना पर्याप्त है जिसमें वे हैं। लेकिन Google टैग प्रबंधक का उपयोग किए बिना मार्कअप के मामले में पहले से ही डेटा को थोड़ा अधिक लचीले ढंग से संभालने का अवसर है।

इसके कार्यान्वयन में क्या समस्याएं उत्पन्न हो सकती हैं? साइट से डेटा भेजने में कोई भी त्रुटि Google टैग प्रबंधक की ओर से डेटा को बदलना मुश्किल बना देती है। उदाहरण के लिए, अक्सर इस तथ्य के साथ एक समस्या होती है कि Google Analytics सर्वर 8 केबी से अधिक के अनुरोधों को स्वीकार नहीं करता है। और जब उत्पाद सूचियों में उत्पाद छापों पर डेटा भेजते हैं, तो अनुरोध बहुत बड़ा होता है। वेब विश्लेषकों के लिए Google टैग प्रबंधक में डेटा को पुनः एकत्रित करना और Google Analytics को भेजना आसान नहीं है। और इस समस्या की जड़ यह है कि भेजे गए डेटा की संरचना इसका मतलब नहीं है।

इस विकल्प के प्लस:

• एक ही डेटा को विभिन्न प्रणालियों में स्थानांतरित किया जा सकता है;
• वेब विश्लेषिकी योग्यता की आवश्यकताएं न्यूनतम हैं।

इस विकल्प के विपक्ष:

• डेटा में कोई त्रुटि डेटा भेजने के साथ समस्याओं की ओर ले जाती है;
• डेटालेयर में डेटा बहुमुखी प्रतिभा की खोज में, आप डेटा प्रबंधन के लचीलेपन में खो सकते हैं।

साइट पर रखें Google टैग प्रबंधक और डेटा को जेएस-ऑब्जेक्ट पर स्थानांतरित करें

हमारे अनुभव में, यह सबसे सुविधाजनक और लचीला विकल्प है। यह इस तथ्य में समाहित है कि डेवलपर्स एक नियमित डेटालेयर ई-कॉमर्स की संरचना के समान संरचना के साथ एक निश्चित js- वस्तु के लिए सभी आवश्यक डेटा के हस्तांतरण को लागू करते हैं। मोर्चे पर प्रत्येक उपयोगकर्ता कार्रवाई के साथ, जो इलेक्ट्रॉनिक कॉमर्स की क्रियाओं से जुड़ा हुआ है, जेएस-ऑब्जेक्ट में डेटा को बदल दिया जाता है और डेटालेयर को एक पुश भेजा जाता है, जो इंगित करता है कि क्या परिवर्तन हुआ है (उदाहरण के लिए, कार्ट में एक आइटम जोड़ा गया है)।

यह कार्यान्वयन वेब विश्लेषिकी को प्रत्येक महत्वपूर्ण उपयोगकर्ता कार्रवाई और Google टैग प्रबंधक में एक अलग HTML टैग या चर बनाकर Google Analytics ई-कॉमर्स डेटा के लिए js ऑब्जेक्ट से डेटा एकत्र करने की क्षमता के लिए ट्रिगर का एक सेट देता है।

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

इस विकल्प के प्लस:

• व्यक्तिगत ट्रिगर और js- वस्तु की पूरी सामग्री के कारण संचरित डेटा को लचीले ढंग से नियंत्रित करने की क्षमता;
• जेएस वस्तु लिंग कर सकते हैं

बैकएंड द्वारा उत्पन्न, सामने की ओर भार के बिना।

इस विकल्प के विपक्ष:

• वेब विश्लेषिकी के लिए योग्यता सभी पिछले कार्यान्वयन की तुलना में अधिक है;
• सभी डेटा ट्रांसफ़र को ट्रिगर और js- ऑब्जेक्ट फिलिंग से जोड़ा जाता है।

Google टैग प्रबंधक को साइट पर रखें और सामने से js टैग के साथ डेटा एकत्र करें

वेब एनालिटिक्स की उपयुक्त योग्यता या वेब एनालिटिक्स की टीम के सामने के छोर को जोड़ने के साथ, आप HTML टैग और Google टैग प्रबंधक चर के साथ सभी आवश्यक डेटा एकत्र कर सकते हैं।

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

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

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

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

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

इस विकल्प के प्लस:

• सबसे तेज और सबसे लचीला लेआउट विकल्प।

इस विकल्प के विपक्ष:

• वेब एनालिटिक्स के लिए उच्च योग्यता
• लेआउट और उसके परिवर्तनों पर मार्कअप गुणवत्ता की एक मजबूत निर्भरता।

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

चौथा चरण: डेवलपर्स के लिए एक गाइड तैयार करना

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

गाइड में क्या वर्णित किया जाना चाहिए:

1. डेटा संग्रह की विशेषताएं

• यदि किसी विशेष क्षेत्र पर कोई डेटा नहीं है तो क्या प्रसारित करना है: 0, एक खाली फ़ील्ड या कुछ विशेष मूल्य;
• खेतों में से कौन सा स्ट्रिंग होना चाहिए, और जो संख्यात्मक मान होना चाहिए;
• क्या विशेष वर्णों का उपयोग नहीं किया जा सकता है;
• और इसी तरह।

2. वे न्यूनतम फ़ील्ड कौन से हैं जिन्हें डेटा संग्रह की प्रमुख संस्थाओं पर पारित किया जाना चाहिए

• पृष्ठ के अनुसार;
• उत्पाद द्वारा;
• बैनर के अनुसार।

3. Google Analytics की प्रत्येक ई-कॉमर्स गतिविधि के लिए डेटा कब और किस रूप में प्रेषित किया जाना चाहिए।

4. कब और किस रूप में साइट पर अन्य उपयोगकर्ता कार्यों पर डेटा प्रेषित किया जाना चाहिए।

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

पांचवां चरण: मार्कअप कार्यान्वयन और बाद की समीक्षा

डेवलपर्स द्वारा मार्कअप के प्रत्येक भाग के कार्यान्वयन के बाद, प्रेषित डेटा की शुद्धता को सत्यापित करना आवश्यक है। सबसे पहले, यह प्रक्रिया अभी तक परीक्षकों को नहीं दी जा सकती है, उन्हें वेब विश्लेषक द्वारा अंत में मार्कअप के संबंधित हिस्से को स्वीकार करने के बाद कनेक्ट करने की आवश्यकता है।

ऑडिट में दो चरण होने चाहिए: गुणात्मक और मात्रात्मक। गुणात्मक चरण वेब एनालिटिक्स द्वारा प्रेषित डेटा को सत्यापित करना है, जो अपने ब्राउज़र में प्रीप्रोड चेक पर बताता है कि डेटा मानक पृष्ठों और उपयोगकर्ता कार्यों पर कैसे प्रसारित किया जाता है। इस चेक का कार्य स्पष्ट त्रुटियों को पकड़ना और पहले से ही जांचे गए संस्करण को ठेस पहुंचाना है। अगला चरण एक मात्रात्मक जांच है। यह Google Analytics के अनुसार मार्कअप का सत्यापन है। यह आपको एक बड़े डेटा नमूने पर कम स्पष्ट त्रुटियों और मार्कअप बग को पकड़ने की अनुमति देता है।

जांच करने के बाद, डेटा को उपयोग के लिए व्यावसायिक ग्राहकों को हस्तांतरित किया जा सकता है। और उसके बाद, परीक्षकों की एक टीम के साथ, मार्कअप की जाँच के लिए मामलों का एक सेट तैयार करें। ताकि नई रिलीज टूट न जाए जो पहले से ही परीक्षण और काम कर चुकी है।

निष्कर्ष

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

मुझे उम्मीद है कि यह लेख कुछ त्रुटियों से बचने और Google Analytics ई-कॉमर्स मार्कअप को जल्द से जल्द लागू करने में मदद करता है।