एक साथ कई रिपोर्ट जनरेट करते समय, यह ज़रूरी है कि रिपोर्ट जनरेट करने की रणनीतियों को ऑप्टिमाइज़ किया जाए, ताकि निजता से जुड़ी सीमाओं का उल्लंघन न हो. एग्रीगेशन सेवा को रिपोर्ट के बैच भेजने के लिए, यहां कुछ रणनीतियां सुझाई गई हैं.
रिपोर्ट इकट्ठा करना
बैच में शामिल करने के लिए रिपोर्ट इकट्ठा करते समय, इन बातों का ध्यान रखें:
रिपोर्ट अपलोड करने की कोशिशें
ध्यान दें: फिर से कोशिश करने की शर्तों में बदलाव किया जा सकता है. ऐसे में, इस सेक्शन में दी गई जानकारी अपडेट कर दी जाएगी.
वेब और ओएस, दोनों प्लैटफ़ॉर्म पर, कोई प्लैटफ़ॉर्म रिपोर्ट को तीन बार भेजने की कोशिश करेगा. अगर तीसरी बार कोशिश करने के बाद भी रिपोर्ट नहीं भेजी जाती है, तो उसे नहीं भेजा जाएगा. रिपोर्ट कब भेजी जाती है, इससे कोई फ़र्क़ नहीं पड़ता. scheduled_report_time की ओरिजनल वैल्यू हमेशा बनी रहती है. फिर से कोशिश करने की समयसीमा, हर प्लैटफ़ॉर्म के लिए अलग-अलग होती है:
- वेब ब्राउज़र, ऑनलाइन होने पर रिपोर्ट भेजता है. अगर रिपोर्ट नहीं भेजी जा सकी, तो दूसरी बार कोशिश करने के लिए पांच मिनट और तीसरी बार कोशिश करने के लिए 15 मिनट इंतज़ार किया जाएगा. अगर ब्राउज़र ऑफ़लाइन हो जाता है, तो इसके ऑनलाइन होने के एक मिनट बाद, फिर से कोशिश की जाएगी. वेब पर रिपोर्ट भेजने में कोई ज़्यादा देरी नहीं होती. इसका मतलब है कि अगर ब्राउज़र ऑफ़लाइन हो जाता है, तो रिपोर्ट जनरेट होने के समय से कोई फ़र्क़ नहीं पड़ता. ब्राउज़र के फिर से ऑनलाइन होने पर, वह फिर से कोशिश करने की नीति के मुताबिक रिपोर्ट भेजने की कोशिश करेगा.
- Android फ़ोन में इंटरनेट कनेक्शन ठीक से काम कर रहा हो. इसलिए, यह हर घंटे में एक बार रिपोर्ट भेजने का काम करेगा. इसका मतलब है कि अगर कोई रिपोर्ट नहीं भेजी जा पाती है, तो उसे अगले घंटे में फिर से भेजने की कोशिश की जाएगी. इसके बाद, अगले घंटे में फिर से कोशिश की जाएगी. अगर डिवाइस कनेक्ट नहीं है, तो डिवाइस अगली रिपोर्टिंग जॉब के साथ रिपोर्ट भेजने की कोशिश करेगा. यह जॉब, डिवाइस के नेटवर्क से फिर से कनेक्ट होने के बाद शुरू होगी. डेटा भेजने में ज़्यादा से ज़्यादा 28 दिनों की देरी हो सकती है. इसका मतलब है कि डिवाइस, 28 दिन से ज़्यादा पुरानी रिपोर्ट नहीं भेजेगा.
रिपोर्ट के लिए इंतज़ार करना
बैचिंग के लिए रिपोर्ट इकट्ठा करते समय, देर से आने वाली रिपोर्ट का इंतज़ार करने का सुझाव दिया जाता है. रिपोर्ट देर से सबमिट हुई है या नहीं, यह इस बात से पता चलता है कि रिपोर्ट कब मिली और scheduled_report_time की वैल्यू क्या है. इन रिपोर्ट के बीच के समय के अंतर से यह तय करने में मदद मिलेगी कि आपको देर से आने वाली रिपोर्ट के लिए कितना इंतज़ार करना है. उदाहरण के लिए, देरी से मिलने वाली रिपोर्ट इकट्ठा होने पर, scheduled_report_time फ़ील्ड की जांच करें. साथ ही, रिपोर्ट के 90%, 95%, और 99% मिलने में लगने वाले समय को घंटों में नोट करें. इस डेटा का इस्तेमाल यह तय करने के लिए किया जा सकता है कि देर से आने वाली रिपोर्ट के लिए कितना इंतज़ार करना है.
तुरंत एग्रीगेट की गई रिपोर्ट का इस्तेमाल करके, रिपोर्ट में देरी होने की आशंका को कम किया जा सकता है.
इस इमेज में दिखाया गया है कि रिपोर्ट जनरेट होने के तय समय के हिसाब से, देर से मिलने वाली रिपोर्ट को सही बैच में कैसे सेव किया जाता है. बैच टी, scheduled_report_time को दिखाता है. वहीं, टी+एक्स, देरी से मिलने वाली रिपोर्ट के लिए इंतज़ार में लगने वाले समय को दिखाता है. इससे खास जानकारी वाली रिपोर्ट जनरेट होती है. इसमें बैच में शामिल ज़्यादातर रिपोर्ट शामिल होती हैं. ये रिपोर्ट, शेड्यूल की गई रिपोर्ट के समय के हिसाब से होती हैं.
एग्रीगेट की जा सकने वाली रिपोर्टिंग
एग्रीगेशन सेवा, "कोई डुप्लीकेट नहीं" नियम का पालन करती है. इस नियम के तहत, शेयर किए गए एक ही आईडी वाली सभी एग्रीगेट की जा सकने वाली रिपोर्ट को एक ही बैच में शामिल करना ज़रूरी है.
रिपोर्ट इकट्ठा होने के बाद, उन्हें इस तरह से बैच में रखा जाना चाहिए कि एक ही शेयर किए गए आईडी वाली सभी रिपोर्ट, एक बैच में हों.
अगर किसी रिपोर्ट को पहले ही किसी दूसरे बैच में प्रोसेस किया जा चुका है, तो उसे प्रोसेस करने पर प्राइवसी बजट खत्म होने की गड़बड़ी हो सकती है. रिपोर्ट को सही तरीके से बैच करने पर, "कोई डुप्लीकेट नहीं" नियम का उल्लंघन होने की वजह से बैच अस्वीकार नहीं किए जाते.
शेयर किया गया आईडी एक कुंजी होती है. इसे हर रिपोर्ट के लिए जनरेट किया जाता है, ताकि एग्रीगेट की जा सकने वाली रिपोर्ट की जवाबदेही को ट्रैक किया जा सके. शेयर किए गए आईडी से यह पक्का होता है कि एक ही शेयर किए गए आईडी वाली रिपोर्ट, सिर्फ़ एक खास जानकारी वाली रिपोर्ट में शामिल हों. इसका मतलब है कि एक ही शेयर किए गए आईडी से मैप होने वाली सभी रिपोर्ट को एक ही बैच में शामिल किया जाना चाहिए. उदाहरण के लिए, अगर रिपोर्ट X और रिपोर्ट Y, दोनों का शेयर किया गया आईडी एक ही है, तो उन्हें एक ही बैच में शामिल किया जाना चाहिए. ऐसा इसलिए, ताकि डुप्लीकेट होने की वजह से रिपोर्ट न हटाई जाएं.
यहां दी गई इमेज में, shared_info कॉम्पोनेंट दिखाए गए हैं. इन्हें एक साथ हैश करके, शेयर किया गया आईडी जनरेट किया जाता है.
यहां दी गई इमेज में दिखाया गया है कि दो अलग-अलग रिपोर्ट का शेयर किया गया आईडी एक जैसा कैसे हो सकता है:
ध्यान दें: scheduled_report_time को घंटे के हिसाब से और source_registration_time को दिन के हिसाब से काटा जाता है. इसके अलावा, शेयर किए गए आईडी बनाने में report_id का इस्तेमाल नहीं किया जाता है. आने वाले समय में, समय के हिसाब से डेटा को अपडेट किया जा सकता है.
बैच में डुप्लीकेट रिपोर्ट
एग्रीगेट की जा सकने वाली रिपोर्ट के shared_info फ़ील्ड में, report_id फ़ील्ड में मौजूद यूयूआईडी होता है. इसका इस्तेमाल, बैच में मौजूद डुप्लीकेट रिपोर्ट की पहचान करने के लिए किया जाता है. अगर किसी बैच में एक ही report_id वाली एक से ज़्यादा रिपोर्ट हैं, तो सिर्फ़ पहली रिपोर्ट को एग्रीगेट किया जाएगा. बाकी रिपोर्ट को डुप्लीकेट माना जाएगा और उन्हें हटा दिया जाएगा. एग्रीगेशन सामान्य तरीके से जारी रहेगा और कोई गड़बड़ी नहीं भेजी जाएगी.
हालांकि, ऐसा करना ज़रूरी नहीं है, लेकिन विज्ञापन टेक्नोलॉजी, एग्रीगेशन से पहले एक जैसे रिपोर्ट आईडी वाली डुप्लीकेट रिपोर्ट को फ़िल्टर करके, परफ़ॉर्मेंस में कुछ सुधार देख सकती है.
report_id हर रिपोर्ट के लिए यूनीक होता है.
बैच में डुप्लीकेट रिपोर्ट
हर रिपोर्ट को एक शेयर किया गया आईडी असाइन किया जाता है. यह आईडी, रिपोर्ट के shared_info फ़ील्ड से मिले डेटा पॉइंट को मिलाकर जनरेट किया जाता है. एक से ज़्यादा रिपोर्ट का शेयर किया गया आईडी एक ही हो सकता है. साथ ही, हर बैच में शेयर किए गए कई आईडी हो सकते हैं. एक ही शेयर किए गए आईडी वाली सभी रिपोर्ट, एक ही बैच में होनी चाहिए. अगर एक ही शेयर किए गए आईडी वाली रिपोर्ट कई बैच में शामिल हो जाती हैं, तो सिर्फ़ पहले बैच को स्वीकार किया जाएगा. बाकी बैच को डुप्लीकेट के तौर पर अस्वीकार कर दिया जाएगा. इससे बचने के लिए, बैच सही तरीके से बनाए जाने चाहिए.
यहां दी गई इमेज में एक उदाहरण दिखाया गया है. इसमें बताया गया है कि अलग-अलग बैच में एक ही शेयर किए गए आईडी वाली रिपोर्ट की वजह से, बाद वाला बैच फ़ेल हो सकता है. इमेज में, एक ही शेयर किए गए आईडी e679aa वाली दो या उससे ज़्यादा रिपोर्ट को अलग-अलग बैच #1 और #2 में बैच किया गया है. शेयर किए गए आईडी e679aa वाली सभी रिपोर्ट का बजट, बैच #1 की खास जानकारी वाली रिपोर्ट जनरेट करने के दौरान इस्तेमाल हो जाता है. इसलिए, बैच #2 की अनुमति नहीं है और गड़बड़ी की वजह से यह काम नहीं करता.
बैच रिपोर्ट
डुप्लीकेट रिपोर्ट से बचने और एग्रीगेट रिपोर्ट के हिसाब को ऑप्टिमाइज़ करने के लिए, रिपोर्ट को बैच करने के ये तरीके सुझाए जाते हैं.
विज्ञापन देने वाले व्यक्ति या कंपनी के हिसाब से बैच
ध्यान दें: इस रणनीति का सुझाव सिर्फ़ एट्रिब्यूशन रिपोर्टिंग एग्रीगेशन के लिए दिया जाता है.
Private Aggregation में attribution_destination फ़ील्ड नहीं होता है. यह फ़ील्ड, विज्ञापन देने वाले व्यक्ति या कंपनी के लिए होता है. हमारा सुझाव है कि विज्ञापन देने वाले व्यक्ति या कंपनी के हिसाब से बैच बनाएं. इसका मतलब है कि एक ही विज्ञापन देने वाले व्यक्ति या कंपनी से जुड़ी रिपोर्ट को एक ही बैच में शामिल करें, ताकि हर बैच के लिए एग्रीगेट की जा सकने वाली रिपोर्ट के खाते की सीमा न पहुंचे. विज्ञापन देने वाला व्यक्ति या कंपनी, शेयर किए गए आईडी जनरेट करने के लिए इस्तेमाल किया जाने वाला फ़ील्ड है. इसलिए, विज्ञापन देने वाले एक ही व्यक्ति या कंपनी की रिपोर्ट में शेयर किया गया एक ही आईडी हो सकता है. गड़बड़ियों से बचने के लिए, इन रिपोर्ट को एक ही बैच में होना चाहिए.
समय के हिसाब से बैच बनाना
हमारा सुझाव है कि बैचिंग करते समय, रिपोर्ट के शेड्यूल किए गए समय (shared_info.scheduled_report_time) को ध्यान में रखें. शेयर किए गए आईडी जनरेशन में, शेड्यूल की गई रिपोर्ट के समय को घंटे के हिसाब से छोटा कर दिया जाता है. इसलिए, रिपोर्ट को कम से कम हर घंटे के अंतराल पर बैच में रखा जाना चाहिए. इसका मतलब है कि एक ही घंटे में शेड्यूल की गई रिपोर्ट के समय वाली सभी रिपोर्ट को एक ही बैच में रखा जाना चाहिए, ताकि कई बैच में एक ही शेयर किया गया आईडी वाली रिपोर्ट न हों. इससे जॉब में गड़बड़ियां होंगी.
बैच फ़्रीक्वेंसी और नॉइज़
हमारा सुझाव है कि आप इस बात पर ध्यान दें कि नॉइज़ का असर, एग्रीगेट की जा सकने वाली रिपोर्ट को प्रोसेस करने की फ़्रीक्वेंसी पर किस तरह पड़ता है. अगर एग्रीगेट की जा सकने वाली रिपोर्ट को ज़्यादा बार बैच किया जाता है, तो कम कन्वर्ज़न इवेंट शामिल किए जाएंगे. उदाहरण के लिए, अगर रिपोर्ट को हर घंटे में एक बार प्रोसेस किया जाता है, तो कम कन्वर्ज़न इवेंट शामिल किए जाएंगे. साथ ही, नॉइज़ का रिलेटिव असर ज़्यादा होगा. अगर रिपोर्ट को हफ़्ते में एक बार प्रोसेस किया जाता है, तो नॉइज़ का असर कम होगा. बैच पर नॉइज़ के असर को बेहतर तरीके से समझने के लिए, नॉइज़ लैब का इस्तेमाल करें.