एक साथ कई बैच बनाने की रणनीतियां

एग्रीगेट की जा सकने वाली रिपोर्ट का बैच बनाते समय, एक साथ कई रिपोर्ट तैयार करने की रणनीतियों को ऑप्टिमाइज़ करना ज़रूरी है, ताकि निजता की सीमाएं पार न हों. एग्रीगेशन सेवा में रिपोर्ट के बैच भेजने के लिए, यहां कुछ सुझाई गई रणनीतियां दी गई हैं.

रिपोर्ट इकट्ठा करना

किसी बैच में शामिल करने के लिए रिपोर्ट इकट्ठा करते समय, इन बातों का ध्यान रखें:

रिपोर्ट अपलोड करने की कोशिशें

ध्यान दें: फिर से कोशिश करने की शर्तों में बदलाव हो सकता है. ऐसे में, इस सेक्शन में दी गई जानकारी अपडेट कर दी जाएगी.

वेब और ओएस, दोनों प्लैटफ़ॉर्म पर, रिपोर्ट को तीन बार भेजने की कोशिश की जाएगी. हालांकि, अगर तीसरी कोशिश के बाद भी रिपोर्ट नहीं भेजी जा सकी, तो उसे नहीं भेजा जाएगा. रिपोर्ट भेजे जाने के बावजूद, scheduled_report_time की मूल वैल्यू सेव रहती है. दोबारा कोशिश करने की टाइमलाइन, हर प्लैटफ़ॉर्म के हिसाब से अलग-अलग होती है:

• वेब ब्राउज़र ऑनलाइन होने पर रिपोर्ट भेजेगा. अगर रिपोर्ट नहीं भेज पाती है, तो दूसरी कोशिश के लिए पांच मिनट इंतज़ार करना होगा और फिर तीसरी कोशिश के लिए 15 मिनट इंतज़ार करना होगा. अगर ब्राउज़र ऑफ़लाइन हो जाता है, तो ऑनलाइन आने के एक मिनट बाद फिर से कोशिश की जाएगी. वेब पर रिपोर्ट भेजने में कोई तय समय नहीं होता. इसका मतलब है कि अगर ब्राउज़र ऑफ़लाइन हो जाता है, तो फिर से कोशिश करने की नीति के मुताबिक, ब्राउज़र के ऑनलाइन होने के बाद, वह रिपोर्ट भेजने की कोशिश करेगा. भले ही, रिपोर्ट कितने समय पहले जनरेट की गई हो.
• Android फ़ोन में लगातार नेटवर्क कनेक्शन हो. इसलिए, यह हर घंटे एक बार रिपोर्ट भेजने के लिए जॉब चलाएगा. इसका मतलब है कि अगर कोई रिपोर्ट नहीं भेजी जा सकी, तो अगले घंटे और उसके बाद अगले घंटे में फिर से कोशिश की जाएगी. अगर डिवाइस का कोई कनेक्शन नहीं है, तो डिवाइस, रिपोर्टिंग की अगली जॉब के साथ रिपोर्ट भेजने की कोशिश फिर से करेगा. यह जॉब, डिवाइस के फिर से नेटवर्क से कनेक्ट होने के बाद चलेगी. रिपोर्ट भेजने में ज़्यादा से ज़्यादा 28 दिन लग सकते हैं. इसका मतलब है कि डिवाइस, 28 दिन से पहले जनरेट की गई रिपोर्ट नहीं भेजेगा.

रिपोर्ट का इंतज़ार करना

हमारा सुझाव है कि बैच में रिपोर्ट इकट्ठा करते समय, देर से आने वाली रिपोर्ट का इंतज़ार करें. देर से मिलने वाली रिपोर्ट का पता लगाने के लिए, scheduled_report_time वैल्यू की तुलना रिपोर्ट मिलने की तारीख से करें. इन रिपोर्ट के बीच के समय के अंतर से यह तय करने में मदद मिलेगी कि आपको देर से आने वाली रिपोर्ट के लिए कितनी देर इंतज़ार करना है. उदाहरण के लिए, देर से मिलने वाली रिपोर्ट इकट्ठा होने पर, scheduled_report_time फ़ील्ड की जांच करें और देखें कि घंटों में देरी हुई है, क्योंकि 90%, 95%, और 99% रिपोर्ट मिली हैं. इस डेटा का इस्तेमाल यह तय करने के लिए किया जा सकता है कि देर से आने वाली रिपोर्ट के लिए कितना इंतज़ार करना है. इंस्टैंट एग्रीगेट रिपोर्ट का इस्तेमाल, रिपोर्ट में देरी की संभावना को कम करने के लिए किया जा सकता है.

नीचे दिए गए विज़ुअल में, शेड्यूल किए गए समय के हिसाब से, देर से आने वाली रिपोर्ट को सही बैच में सेव किया जा रहा है. बैच T, scheduled_report_time को दिखाता है और T+X, देर से मिलने वाली रिपोर्ट के लिए इंतज़ार किए गए समय को दिखाता है. इससे, खास जानकारी वाली एक रिपोर्ट बनती है. इसमें, बैच में शामिल ज़्यादातर रिपोर्ट शामिल होती हैं. ये रिपोर्ट, शेड्यूल किए गए रिपोर्ट के समय के हिसाब से होती हैं.

एग्रीगेट की जा सकने वाली रिपोर्ट का हिसाब

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

रिपोर्ट इकट्ठा होने के बाद, उन्हें इस तरह से बैच में भेजा जाना चाहिए कि एक ही शेयर किए गए आईडी वाली सभी रिपोर्ट एक बैच का हिस्सा बन जाएं.

अगर किसी रिपोर्ट को पहले ही किसी दूसरे बैच में प्रोसेस किया जा चुका है, तो प्रोसेस करने पर आपको निजता बजट खत्म होने की गड़बड़ी का मैसेज मिल सकता है. रिपोर्ट को सही तरीके से बैच बनाने से, "कोई डुप्लीकेट नहीं" नियम की वजह से बैच को अस्वीकार होने से रोकने में मदद मिलती है.

शेयर किया गया आईडी एक ऐसा पासकोड होता है जो हर रिपोर्ट के लिए जनरेट किया जाता है. इससे, एग्रीगेट की जा सकने वाली रिपोर्ट के खाते को ट्रैक किया जा सकता है. शेयर किए गए आईडी से यह पक्का होता है कि एक ही शेयर किए गए आईडी वाली रिपोर्ट को सिर्फ़ एक खास जानकारी वाली रिपोर्ट में जोड़ा जाएगा. इसका मतलब है कि एक शेयर किए गए आईडी से मैप की गई सभी रिपोर्ट को एक ही बैच में शामिल किया जाना चाहिए. उदाहरण के लिए, अगर रिपोर्ट 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 की अनुमति नहीं है और यह गड़बड़ी के साथ बंद हो जाती है.

एक साथ कई रिपोर्ट

डुप्लीकेट रिपोर्ट से बचने और एग्रीगेट रिपोर्ट के हिसाब-किताब को ऑप्टिमाइज़ करने के लिए, रिपोर्ट को एक साथ प्रोसेस करने के सुझाए गए तरीके यहां दिए गए हैं.

विज्ञापन देने वाले के हिसाब से बैच बनाना

ध्यान दें: इस रणनीति का सुझाव सिर्फ़ एट्रिब्यूशन रिपोर्टिंग एग्रीगेशन के लिए दिया जाता है.

निजी एग्रीगेशन में attribution_destination फ़ील्ड नहीं होता, जो विज्ञापन देने वाले का होता है. हमारा सुझाव है कि आप विज्ञापन देने वाले के हिसाब से बैच बनाएं. इसका मतलब है कि एक ही बैच में, विज्ञापन देने वाले के खाते से जुड़ी रिपोर्ट शामिल करें. इससे, हर बैच के लिए, एग्रीगेट की जा सकने वाली रिपोर्ट की खाता सीमा से बचने में मदद मिलेगी. विज्ञापन देने वाला व्यक्ति या कंपनी, शेयर किए गए आईडी जनरेशन में शामिल एक फ़ील्ड है. इसलिए, एक ही विज्ञापन देने वाले व्यक्ति या कंपनी की रिपोर्ट में भी एक ही शेयर किया गया आईडी हो सकता है. गड़बड़ियों से बचने के लिए, उन्हें एक ही बैच में होना चाहिए.

समय के हिसाब से बैच

हमारा सुझाव है कि बैच बनाते समय, रिपोर्ट के शेड्यूल किए गए समय (shared_info.scheduled_report_time) को ध्यान में रखें. शेयर किए गए आईडी जनरेट करने में, शेड्यूल की गई रिपोर्ट का समय घंटे के हिसाब से कम किया जाता है. इसलिए, कम से कम एक घंटे के अंतराल में रिपोर्ट बैच बनाई जानी चाहिए. इसका मतलब है कि एक ही घंटे में शेड्यूल की गई रिपोर्ट का समय एक ही बैच में होना चाहिए, ताकि कई बैच में एक ही शेयर आईडी वाली रिपोर्ट न दिखें. इससे जॉब में गड़बड़ियां हो सकती हैं.

बैच फ़्रीक्वेंसी और शोर

हमारा सुझाव है कि एग्रीगेट की जा सकने वाली रिपोर्ट को प्रोसेस करने की फ़्रीक्वेंसी पर, नॉइज़ के असर को ध्यान में रखें. अगर एग्रीगेट की जा सकने वाली रिपोर्ट को बार-बार एक साथ प्रोसेस किया जाता है, जैसे कि रिपोर्ट को हर घंटे एक बार प्रोसेस किया जाता है, तो कम कन्वर्ज़न इवेंट शामिल किए जाएंगे और ग़ैर-ज़रूरी डेटा का असर ज़्यादा होगा. अगर फ़्रीक्वेंसी कम की जाती है और रिपोर्ट को हफ़्ते में एक बार प्रोसेस किया जाता है, तो शोर का असर कम होगा. बैच पर ग़ैर-ज़रूरी डेटा के असर को बेहतर तरीके से समझने के लिए, Noise Lab का इस्तेमाल करें.