पहली उपयोगकर्ता प्राप्ति का स्रोत, सत्र का स्रोत और मुख्य इवेंट का श्रेय अलग दृष्टिकोण हैं। उपयोगी रिपोर्ट चैनलों की तुलना से पहले ये दायरे स्पष्ट करती है।
समान आधार तय करें
अवधि, समय क्षेत्र, मुद्रा, रूपांतरण और एट्रिब्यूशन अवधि निर्धारित करें। खरीद में इवेंट को ऑर्डर से मिलाएँ, दोहराव जाँचें और रिफंड का व्यवहार बताएँ। आरोपित राजस्व न लाभ मार्जिन है, न अतिरिक्त लाभ।
GA4 आयामों को दायरे के अनुसार पढ़ें
तालिका ट्रैफ़िक स्रोतों के तीन दायरे अलग करती है। रिपोर्ट का एट्रिब्यूशन मॉडल बदलने से उपयोगकर्ता और सत्र आयाम नहीं बदलते। इस अंतर को अनदेखा करने से दिखावटी विरोधाभास बन सकता है।
| दायरा | प्रश्न | मॉडल चयन का प्रभाव |
|---|---|---|
| उपयोगकर्ता | पहली प्राप्ति का स्रोत | इस दायरे के आयाम नहीं बदलते |
| सत्र | हर सत्र का स्रोत | इस दायरे के आयाम नहीं बदलते |
| इवेंट | मुख्य इवेंट का श्रेय | चुने गए रिपोर्ट एट्रिब्यूशन मॉडल पर निर्भर |
कार्रवाई से पहले अंतर दर्ज करें
टैगिंग, सहमति, कवरेज और रूपांतरण देरी के बदलाव लिखें। रिपोर्ट के साथ परिभाषाएँ और निष्कर्षण तिथियाँ रखें। प्लेटफ़ॉर्मों में अंतर होने पर दायरों का मिलान करें, स्वतः बजट न बदलें।
स्रोत और सत्यापन
- Google Analytics — Scopes of traffic-source dimensions
- Google Analytics — Minimize duplicate key events with transaction IDs
- Google Analytics — Get started with attribution
मल्टीचैनल रिपोर्ट को एक ऑथेंटिक काउंट की ज़रूरत होती है।
कई चैनल एक जर्नी में कंट्रीब्यूट कर सकते हैं। हर रिपोर्ट में क्रेडिट एलोकेशन और यूनिक आउटकम की काउंटिंग के सोर्स को डिफाइन करें। विंडो, इंटरप्टेड ट्रैकिंग और कैंपेन पैरामीटर के बिना लौटने वाले विज़िटर की जांच करें; डायरेक्ट का मतलब ज़रूरी नहीं कि पहले कोई कंट्रीब्यूशन न हो।
- एट्रिब्यूशन मॉडल और विंडो को डॉक्यूमेंट करें।
- चैनल क्रेडिट के साथ यूनिक आउटकम को रिकंसाइल करें।
- अनट्रैक्ड जर्नी की लिमिटेशन बताएं।
क्या प्लेटफ़ॉर्म-एट्रिब्यूटेड सेल्स को एक साथ जोड़ा जाना चाहिए?
यूनिक ऑर्डर की काउंट के तौर पर नहीं। हर रिपोर्ट एक ही सेल को क्रेडिट कर सकती है; मेल-मिलाप और ओवरलैप दिखाएं।
प्राथमिक स्रोत: Google Analytics — Campaign URL data. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
समय क्षेत्र और देर से आए घटनाक्रम
रिपोर्ट अवधि घटना समय और समापन नियमों पर निर्भर है।
- घटना का समय, प्राप्ति का समय और व्यवसाय का समय-क्षेत्र अलग दर्ज करें। काल्पनिक उदाहरण में 23:30 UTC, स्थिर UTC+02:00 अंतर पर अगले दिन 01:30 है। PostgreSQL का समय-क्षेत्र वाला टाइमस्टैम्प मूल क्षेत्र का नाम सुरक्षित नहीं रखता।
- शुरुआत शामिल करें और अंत बाहर रखें। UTC में बदलने से पहले व्यवसाय के क्षेत्र में सीमाएँ निकालें। मौसमी घड़ी परिवर्तन, महीने का बदलाव और बिना समय की तारीख जाँचें; स्थानीय दिन हमेशा 24 घंटे नहीं होता।
- स्वीकार्य विलंब और रिपोर्ट बंद करने का समय तय करें। वही पहचानकर्ता दोहराकर नई घटना को डुप्लिकेट से अलग करें। प्रकाशित संस्करण रखें और सुधार का प्रभाव दर्ज करें; वॉटरमार्क आगमन का अनुमान है, पूर्णता की गारंटी नहीं।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}अपेक्षित निर्णय
बताए समय क्षेत्र में घटना 9 अक्टूबर की है। UTC का क्षण भी सुरक्षित रखें।
सत्यापन प्रक्रिया
- रिपोर्ट समय क्षेत्र और संदर्भ क्षण तय करें।
- आधी रात के पास घटना दोहराएँ।
- UTC, स्थानीय तारीख़ और समाप्ति नियम रखें। घड़ी बदलते समय की अस्पष्ट स्थानीय घड़ी का उदाहरण जोड़ें; किसी क्षण का अनुमान लगाने के बजाय ऑफ़सेट और समय क्षेत्र सुरक्षित रखें।
क्या प्राप्ति की तारीख को घटना की तारीख मान सकते हैं?
केवल जब रिपोर्ट की परिभाषा ऐसा कहती हो। दोनों समय रखें और देर से आई घटनाओं का व्यवहार समझाएँ।
प्राथमिक स्रोत: PostgreSQL — Date/time types. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.