स्थानांतरण से पहले प्रवाह बनाएँ
ब्राउज़र में संग्रह, फिर सर्वर और गंतव्य को भेजना रह सकता है। Consent Mode स्थितियाँ भेजकर कुछ व्यवहार बदलता है; अकेले विकल्प बैनर या कानूनी सत्यापन नहीं देता।
| चरण | नियंत्रण | अपेक्षित प्रमाण |
|---|---|---|
| ब्राउज़र या ऐप | एकत्र फील्ड और विकल्प। | वास्तव में भेजे अनुरोध। |
| संग्रह सर्वर | सत्यापन, फिल्टर और पहुँच। | स्वीकृत या अस्वीकृत इवेंट। |
| गंतव्य | वास्तव में आगे भेजा डेटा। | पेलोड और सहमति नियम। |
| संचालन | भंडारण, अधिकार और पुनर्प्राप्ति। | मिटाने, विफलता और पहुँच की जाँच। |
वास्तव में भेजा डेटा जाँचें
- हर उद्देश्य के अनुमत फील्ड और प्राप्तकर्ता तय करें। भेजने से पहले URL, पैरामीटर, पहचानकर्ता और लॉग देखें; डिफॉल्ट फिल्टर मानकर न चलें।
- स्वीकृति, इनकार और विकल्प बदलाव पूरी श्रृंखला में जाँचें। ब्राउज़र, सर्वर कंटेनर और हर गंतव्य देखें।
- मिले, स्वीकृत और आगे भेजे इवेंट मिलाएँ। डुप्लिकेट, नुकसान, विफलता और पुनर्प्राप्ति जाँचें; फिर सर्वर लागत और भार मापें।
लाभ और दायित्व अलग आँकें
समान यात्राओं पर प्रदर्शन जाँचें; शुरुआती ब्राउज़र संग्रह जरूरी रह सकता है। अपना डोमेन छूट नहीं है। फ्रांस में कुछ दर्शक-मापन उपकरणों की छूट शर्तों वाली है और विज्ञापन टैगिंग को अपने आप नहीं ढकती।
प्राथमिक स्रोत
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
सर्वर-साइड टैगिंग के लिए अभी भी फ्लो टेस्टिंग की ज़रूरत है।
टैग को सर्वर पर ले जाने से मेज़रमेंट अपने आप कम्प्लायंट या मिनिमम नहीं हो जाता है। असल डिप्लॉयमेंट में मना करने के बाद एमिटेड रिक्वेस्ट, रिसीवर, आइडेंटिफायर और बिहेवियर को इंस्पेक्ट करें।
- ब्राउज़र, कलेक्शन सर्वर, वेंडर और ट्रांसमिटेड फील्ड को मैप करें।
- चुनने से पहले, मना करने के बाद और सहमति वापस लेने के बाद टेस्ट करें।
- बताए गए मकसद और रिलेवेंट CNIL कंडीशन के साथ सेटिंग्स को कम्पेयर करें।
प्राथमिक स्रोत: CNIL — Outils de mesure d’audience et traceurs. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
API कोटा और दर सीमाएँ
सीमाएँ क्षमता, पुनः प्रयास और ग्राहकों के बँटवारे को प्रभावित करती हैं।
- दर्ज करें कि कोटा खाते, कुंजी या संसाधन पर लागू है और क्लाइंट कितने समानांतर कार्य स्वीकार करता है। औसत दर कम होने पर भी असीमित कतार सेवा पर अधिक भार डाल सकती है।
- 429 में Retry-After हो तो उसे समझें और अगली माँग से पहले प्रतीक्षा करें। बढ़ती प्रतीक्षा और क्लाइंट के बीच समय वितरण को अधिकतम प्रयास और कुल समय सीमा से जोड़ें।
- लेखन का उत्तर खो जाए तो दोहराने से पहले स्थिति जाँचें। अनुकरण में कोटा, देर से उत्तर और रद्द करना मिलाएँ; कतार बिना दोहराए प्रभाव के समाप्त होनी चाहिए।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"http_status": 429,
"retry_after_seconds": 30,
"workers": 20,
"retry_budget": 3,
"retry_budget_scope": "per_worker_retries_excluding_initial_request",
"scheduling_example": {
"response_received_at_seconds": 0,
"illustrative_retry_seconds": [
30,
31,
32,
33,
34
],
"workers_per_second": 4,
"alternative_deadline_seconds": 25,
"total_attempts_if_all_retries_used": 80
}
}अपेक्षित निर्णय
30 सेकंड प्रतीक्षा करें, 20 वर्करों के प्रयास अलग समय पर करें और पुनः प्रयास सीमित रखें।
बीस क्लाइंट: पुनः प्रयास बाँटें और गिनें
काल्पनिक उदाहरण: 20 वर्कर +0 s पर अलग-अलग 429 उत्तर और Retry-After: 30 प्राप्त करते हैं। समय-सारणी एक संभावित वितरण है, सर्वर क्षमता की गारंटी नहीं। हर वर्कर के पास शुरुआती अनुरोध के अलावा 3 पुनः प्रयास हैं।
| नीति | गणना या समय-सारणी | प्रभाव और सीमा |
|---|---|---|
| एक साथ पुनः प्रयास | 20 × 1 = 20 @ +30 s | 30 सेकंड प्रतीक्षा करने से समय का निर्देश पूरा होता है, लेकिन सभी 20 अनुरोध साथ लौटते हैं और भार फिर बढ़ सकता है। |
| फैले हुए पुनः प्रयास | 4 × 5 = 20 @ +30…+34 s | पाँच सेकंड तक प्रति सेकंड चार अनुरोध भेजने से 20 पुनः प्रयास फैलते हैं, उनकी संख्या घटती नहीं। यह उदाहरण क्रमिक प्रतीक्षा और यादृच्छिक अंतर वाली नीति का विकल्प नहीं है। |
| 25 सेकंड की समय-सीमा | 25 s < 30 s → 0 | यदि बचा समय आवश्यक 30 सेकंड से कम है, तो अनुबंध के अनुसार रोकें या स्थगित करें। समय-सीमा के लिए प्रतीक्षा कम न करें। |
| अधिकतम बजट | 20 × (1 + 3) = 80 | सभी प्रयास इस्तेमाल करने पर 20 शुरुआती अनुरोध और 60 पुनः प्रयास, कुल 80 अनुरोध होते हैं। सीमा सफलता या सुरक्षित दोहराव की गारंटी नहीं है। |
सत्यापन प्रक्रिया
- कोटा दायरा और पुनः प्रयास बजट दर्ज करें।
- केवल अधिकृत परीक्षण में कोटा खत्म करें।
- 429, Retry-After और सीमित समयक्रम रखें। तकनीकी सीमा और व्यावसायिक परिणाम में अंतर करें; समाप्त कोटे को शून्य स्टॉक बताने वाले उत्तर में न बदलें।
- बाहरी भार बिना चार परतों के तीन कुल कॉल का अनुकरण कर प्रयास गिनें।
- काल्पनिक कतार कार्य समाप्त करें और नया कार्य न शुरू होने की पुष्टि करें।
- काल्पनिक विफलता बाद अधिकृत काम धीरे लौटाएँ और कॉल, सीमा तथा विशिष्ट परिणाम बचाएँ।
क्या 429 साबित करता है कि पिछला लेखन नहीं हुआ?
नहीं। खोए उत्तर वाले कार्य का अलग मिलान आवश्यक है; दूसरी कोशिश के उत्तर से उसकी स्थिति न निकालें।
प्राथमिक स्रोत: IETF — RFC 6585, HTTP 429. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
कार्बन मापन की सीमाएँ
तुलना के लिए समान सीमा और कार्यात्मक इकाई चाहिए।
- घटक, क्षेत्र, अवधि और कार्यात्मक इकाई लिखें, जैसे एक पूरी कार्रवाई। समान सेवा देने वाले परिदृश्यों की तुलना करें।
- ऊर्जा, उत्सर्जन गुणक और हार्डवेयर का आवंटित हिस्सा लिखें। माप और अनुमान अलग रखें; बाहर रखे घटक का प्रभाव शून्य न मानें।
- काल्पनिक उदाहरण: (12 + 3) gCO2e / 5 कार्रवाइयाँ = प्रति कार्रवाई 3 gCO2e। अनिश्चित मान्यताएँ बदलें और कुल उत्सर्जन भी तुलना करें।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}अपेक्षित निर्णय
(2 × 100 + 50)/100 = प्रति कार्य 2.5 gCO2e है, केवल घोषित दायरे में।
सत्यापन प्रक्रिया
- दायरा, कार्य इकाई और कारक तय करें।
- ऊर्जा, निहित उत्सर्जन और परिणाम अलग करें।
- स्रोत और बिना छिपे ऑफ़सेट की गणना रखें।
प्राथमिक स्रोत: Green Software Foundation — Software Carbon Intensity. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
API: परतों में गुणा होते पुनः प्रयास रोकें
ऐप, SDK, प्रॉक्सी और सेवा एक कॉल फिर कर सकते हैं। चार काल्पनिक परतों में हर एक के तीन कुल प्रयास अंतिम विफल निर्भरता पर अधिकतम81 कॉल देते हैं। कोटा नियंत्रण में साझा बजट और उपयोगी समय सीमा जोड़ें।
- ऐप, SDK, प्रॉक्सी और निर्भरता के स्वतः प्रयास लिखें। जिम्मेदार परत चुनें और अनुबंध अनुसार अतिरिक्त प्रयास बंद या समन्वित करें। पहला प्रयास कुल बजट में गिनें। कार्य ID बचाएँ और गैर-इडेम्पोटेंट पुनः प्रयास से पहले अनिश्चित असर जाँचें।
- क्लाइंट की असली सीमा अनुसार प्रतीक्षा, कनेक्शन और प्रक्रिया सहित कुल अंतिम समय तय करें। कतार में प्रवेश से पहले समाप्त कार्य अस्वीकार करें। स्थानीय रद्द करना सर्वर रोकना साबित नहीं करता; स्थिति मिलाएँ। सारी कतारें एक साथ चालू किए बिना धीरे वापसी जाँचें।
हर परत पर तीन प्रयास क्या कुल तीन हैं?
नहीं। चार काल्पनिक परतों पर तीन कुल प्रयास से अंतिम निर्भरता पर अधिकतम3⁴ = 81 कॉल होते हैं।
समाप्त कार्य दूर का असर रद्द करता है?
जरूरी नहीं। नया बेकार काम रोके; शुरू दूर कार्य की स्थिति और संभव क्षतिपूर्ति जाँचें।
प्राथमिक स्रोत: AWS — Timeouts, retries, and backoff with jitter. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.