एग्रीगेट की जा सकने वाली रिपोर्ट को एक साथ भेजने के लिए, एक साथ भेजने की रणनीतियों को ऑप्टिमाइज़ करना ज़रूरी है, ताकि निजता की सीमाओं को पार न किया जाए. एग्रीगेशन सेवा को रिपोर्ट के बैच भेजने के लिए, यहां कुछ सुझाई गई रणनीतियां दी गई हैं.
रिपोर्ट इकट्ठा करना
किसी बैच में शामिल करने के लिए रिपोर्ट इकट्ठा करते समय, इन बातों का ध्यान रखें:
रिपोर्ट अपलोड करने के लिए, फिर से कोशिश करने की संख्या
ध्यान दें: फिर से कोशिश करने की शर्तों में बदलाव हो सकता है. ऐसे में, इस सेक्शन में दी गई जानकारी अपडेट कर दी जाएगी.
वेब और ओएस, दोनों प्लैटफ़ॉर्म पर, रिपोर्ट को तीन बार भेजने की कोशिश की जाएगी. हालांकि, अगर तीसरी कोशिश के बाद भी रिपोर्ट नहीं भेजी जा सकी, तो उसे नहीं भेजा जाएगा. रिपोर्ट भेजे जाने के बावजूद, 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 की अनुमति नहीं है और यह गड़बड़ी के साथ बंद हो जाता है.
बैच रिपोर्ट
डुप्लीकेट रिपोर्ट से बचने और एग्रीगेट रिपोर्ट के हिसाब-किताब को ऑप्टिमाइज़ करने के लिए, रिपोर्ट को एक साथ प्रोसेस करने के सुझाए गए तरीके यहां दिए गए हैं.
विज्ञापन देने वाले के हिसाब से बैच बनाना
ध्यान दें: इस रणनीति का सुझाव सिर्फ़ एट्रिब्यूशन रिपोर्टिंग एग्रीगेशन के लिए दिया जाता है.
Private Aggregation में attribution_destination फ़ील्ड नहीं होता, जो विज्ञापन देने वाले का होता है. हमारा सुझाव है कि आप विज्ञापन देने वाले के हिसाब से बैच बनाएं. इसका मतलब है कि एक ही बैच में, विज्ञापन देने वाले के खाते से जुड़ी रिपोर्ट शामिल करें. इससे, हर बैच के लिए, एग्रीगेट की जा सकने वाली रिपोर्ट की खाता सीमा को पार करने से बचा जा सकता है. विज्ञापन देने वाला व्यक्ति या कंपनी, शेयर किए गए आईडी जनरेशन में शामिल एक फ़ील्ड है. इसलिए, एक ही विज्ञापन देने वाले व्यक्ति या कंपनी की रिपोर्ट में भी एक ही शेयर किया गया आईडी हो सकता है. गड़बड़ियों से बचने के लिए, उन्हें एक ही बैच में होना चाहिए.
समय के हिसाब से बैच बनाना
हमारा सुझाव है कि एक साथ कई रिपोर्ट जनरेट करते समय, रिपोर्ट के शेड्यूल किए गए समय (shared_info.scheduled_report_time) का ध्यान रखें. शेयर किए गए आईडी जनरेशन में, शेड्यूल की गई रिपोर्ट का समय घंटे तक का होता है. इसलिए, कम से कम रिपोर्ट को एक घंटे के अंतराल पर बैच में भेजा जाना चाहिए. इसका मतलब है कि एक ही घंटे में शेड्यूल की गई सभी रिपोर्ट को एक ही बैच में भेजा जाना चाहिए, ताकि एक से ज़्यादा बैच में एक ही शेयर किए गए आईडी वाली रिपोर्ट न हो. इससे जॉब में गड़बड़ियां हो सकती हैं.
बैच फ़्रीक्वेंसी और शोर
हमारा सुझाव है कि इकट्ठा की जा सकने वाली रिपोर्ट को प्रोसेस करने की फ़्रीक्वेंसी पर, ग़ैर-ज़रूरी डेटा के असर पर ध्यान दें. अगर एग्रीगेट की जा सकने वाली रिपोर्ट को बार-बार एक साथ प्रोसेस किया जाता है, जैसे कि रिपोर्ट को हर घंटे एक बार प्रोसेस किया जाता है, तो कम कन्वर्ज़न इवेंट शामिल किए जाएंगे और ग़ैर-ज़रूरी डेटा का असर ज़्यादा होगा. अगर फ़्रीक्वेंसी कम कर दी जाती है और रिपोर्ट को हफ़्ते में एक बार प्रोसेस किया जाता है, तो ग़ैर-ज़रूरी डेटा का असर कम होगा. बैच पर ग़ैर-ज़रूरी डेटा के असर को बेहतर तरीके से समझने के लिए, Noise Lab का इस्तेमाल करें.