API रिपोर्ट: पूर्णता, कोटा और डेटा की उम्र

संक्षेप में

प्रतिक्रिया मिलना और स्क्रिप्ट पूरा होना सभी पंक्तियाँ मिलने का प्रमाण नहीं है। सीमाएँ और देरी API पर निर्भर हैं।

काल्पनिक उदाहरण: अवलोकन 08:00, उपलब्धता 08:10, निकासी 08:15, प्रदर्शन 08:20; डेटा 20 मिनट और निकासी 5 मिनट पुरानी विधि का आरेख · चरण पाठ में समझाए गए हैं
इस लेख में

प्रतिक्रिया मिलना और स्क्रिप्ट पूरा होना सभी पंक्तियाँ मिलने का प्रमाण नहीं है। सीमाएँ और देरी API पर निर्भर हैं।

निकासी का परिणाम जाँचें

अवधि, समय क्षेत्र, फ़िल्टर, फ़ील्ड, पृष्ठांकन और मेटाडेटा जाँचें। GA4 Data API में rowCount पूरे क्वेरी परिणाम की पंक्तियाँ बताता है, केवल एक पृष्ठ की नहीं। यह सारी वास्तविक गतिविधि का कवरेज सिद्ध नहीं करता; कोटा मानें और आंशिक निकासी दिखाएँ।

चार समय अलग रखें

काल्पनिक उदाहरण, एक दिन और समय क्षेत्र: अवलोकन 08:00, उपलब्धता 08:10, निकासी 08:15, प्रदर्शन 08:20। डेटा अवलोकन से 20 मिनट पुराना है, भले निकासी केवल 5 मिनट पुरानी हो। Data Studio और अन्य उपकरणों में स्रोत की देरी और कैश बने रहते हैं।

काल्पनिक उदाहरण: चार अलग समय
बिंदुसमय
अवलोकन08:00
उपलब्धता08:10
निकासी08:15
प्रदर्शन08:20

स्रोत और सत्यापन

कम्प्लीटनेस एविडेंस के साथ एक्सट्रैक्शन को ऑटोमेट करें

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

  • वर्शन फिल्टर, डाइमेंशन, यूनिट, टाइम ज़ोन और पेजिनेशन।
  • एक्सट्रैक्ट किए गए सैंपल की तुलना उसी पीरियड के सोर्स से करें।
  • इंटरप्टेड एक्सट्रैक्शन को रीप्ले करें और लॉस और डुप्लीकेट चेक करें।

प्राथमिक स्रोत: Google SRE — Data Processing Pipelines. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.

समय क्षेत्र और देर से आए घटनाक्रम

रिपोर्ट अवधि घटना समय और समापन नियमों पर निर्भर है।

  • घटना का समय, प्राप्ति का समय और व्यवसाय का समय-क्षेत्र अलग दर्ज करें। काल्पनिक उदाहरण में 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 का क्षण भी सुरक्षित रखें।

सत्यापन प्रक्रिया

  1. रिपोर्ट समय क्षेत्र और संदर्भ क्षण तय करें।
  2. आधी रात के पास घटना दोहराएँ।
  3. UTC, स्थानीय तारीख़ और समाप्ति नियम रखें। घड़ी बदलते समय की अस्पष्ट स्थानीय घड़ी का उदाहरण जोड़ें; किसी क्षण का अनुमान लगाने के बजाय ऑफ़सेट और समय क्षेत्र सुरक्षित रखें।

PostgreSQL — Date/time types

क्या प्राप्ति की तारीख को घटना की तारीख मान सकते हैं?

केवल जब रिपोर्ट की परिभाषा ऐसा कहती हो। दोनों समय रखें और देर से आई घटनाओं का व्यवहार समझाएँ।

प्राथमिक स्रोत: PostgreSQL — Date/time types. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.