SQL इंटरव्यू: रोलिंग 7-डे एक्टिव यूज़र्स की गणना करें

प्रॉम्प्ट और लागू संदर्भ

एक एनालिटिक्स टेबल में events(event_id, user_id, event_at, event_name, is_internal_user) शामिल है। event_at एक PostgreSQL timestamptz है। कम से कम एक app_open, view_dashboard, या run_report इवेंट के बाद एक उपयोगकर्ता सक्रिय माना जाता है। आंतरिक (internal) उपयोगकर्ता गिने नहीं जाते हैं।

1 जून से 30 जून, 2026 तक प्रत्येक America/New_York कैलेंडर तिथि के लिए एक पंक्ति लौटाएं। प्रत्येक रिपोर्ट तिथि के लिए, rolling_7d_active_users उस तिथि या पिछली छह कैलेंडर तिथियों में से किसी पर भी सक्रिय पात्र डिस्टिंक्ट उपयोगकर्ताओं की संख्या है। इसलिए 1 जून के लिए 26 मई से 1 जून (दोनों शामिल) तक की गतिविधि की आवश्यकता होगी। यदि किसी उपयोगकर्ता के तीन तिथियों में बीस इवेंट हैं, तो भी उस विंडो में उसे केवल एक बार गिना जाएगा।

क्वेरी में शून्य उपयोगकर्ताओं वाली तिथियों को बनाए रखा जाना चाहिए, स्पष्ट समय सीमाओं का उपयोग किया जाना चाहिए, और यह बताया जाना चाहिए कि देर से आने वाले इवेंट्स पहले प्रकाशित परिणाम को कैसे प्रभावित करते हैं। मुख्य चुनौती एक रोलिंग डिस्टिंक्ट यूनियन (rolling distinct union) है। यह पहले से एग्रीगेट की गई दैनिक गणनाओं का रोलिंग योग (rolling sum) नहीं है।

इंटरव्यूअर क्या मूल्यांकन करता है

पहला संकेत सिंटैक्स से पहले मेट्रिक की परिभाषा है। एक मजबूत उम्मीदवार क्वालिफाइंग इवेंट्स, बाहर रखी गई आबादी, रिपोर्टिंग टाइमज़ोन, आउटपुट ग्रेन, समावेशी (inclusive) सात-दिनों की विंडो और डेटा पूर्णता सीमा (completeness boundary) को स्पष्ट करता है। इनके बिना, दो सिंटैक्टिक रूप से वैध क्वेरीज़ अलग-अलग प्रश्नों के उत्तर दे सकती हैं।

दूसरा संकेत ग्रेन कंट्रोल है। रॉ इवेंट्स को पहले अद्वितीय (user_id, activity_date) जोड़ों में बदला जाना चाहिए। यह एक ही दिन के डुप्लिकेट्स को हटाता है लेकिन जानबूझकर एक उपयोगकर्ता को कई तिथियों पर बनाए रखता है। अंतिम विंडो तब उन यूज़र सेट्स के डिस्टिंक्ट यूनियन की गणना करती है।

तीसरा संकेत लुभावने शॉर्टकट्स को अस्वीकार करना है। सात DAU मानों को जोड़ने पर एक उपयोगकर्ता प्रत्येक सक्रिय तिथि पर एक बार गिना जाता है। ROWS BETWEEN 6 PRECEDING AND CURRENT ROW सात पंक्तियों का वर्णन करता है, जरूरी नहीं कि सात कैलेंडर तिथियों का, और इसे दैनिक गणनाओं पर लागू करने से भी दिनों के बीच का डिस्टिंक्ट यूनियन फिर से नहीं बनाया जा सकता है।

अंतिम संकेत प्रोडक्शन निर्णय (production judgment) है: अनुरोधित सीमा से पहले छह-दिन के वॉर्म-अप को स्कैन करना, कैलेंडर स्पाइन के साथ खाली तिथियों को सुरक्षित रखना, घोषित टाइमज़ोन का उपयोग करके टाइमस्टैम्प को बदलना, लेट-इवेंट रिफ्रेश सेमेंटिक्स को परिभाषित करना, और जानबूझकर एक सटीक या अनुमानित स्केलिंग रणनीति चुनना।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

सक्रिय (active) के रूप में क्या योग्य है? केवल लॉगिन-आधारित परिभाषा सार्थक

उत्पाद इवेंट्स की तुलना में एक अलग सेट तैयार करती है। इवेंट के नाम और बॉट या आंतरिक बहिष्करण मेट्रिक अनुबंध का हिस्सा हैं।

कौन सा टाइमज़ोन एक दिन को परिभाषित करता है? यह उत्तर America/New_York का उपयोग करता है। UTC स्थानीय

मध्यरात्रि के करीब के इवेंट्स को एक अलग रिपोर्ट तिथि में स्थानांतरित कर देगा।

क्या विंडो सात कैलेंडर दिन है या 168 बीते हुए घंटे? प्रॉम्प्ट स्थानीय कैलेंडर तिथियों की मांग करता है।

डेलाइट-सेविंग ट्रांजिशन उन सात तिथियों में 167 या 169 बीते हुए घंटे बना सकता है।

क्या दोनों सीमाएं समावेशी (inclusive) हैं? उपयोगकर्ता सेट report_date - 6 से लेकर report_date तक को कवर करता है।

सोर्स टाइमस्टैम्प फ़िल्टर अगली मध्यरात्रि की दोहरी गणना से बचने के लिए हाफ-ओपन रेंज का उपयोग करते हैं।

क्या छूटी हुई तिथियां दिखनी चाहिए? हाँ। केवल मौजूदा इवेंट्स से तिथियां निकालने के बजाय

सभी तीस रिपोर्ट तिथियां जनरेट करें।

इवेंट टेबल कितनी पूर्ण है? यदि इवेंट तीन दिन देर से आ सकते हैं, तो हाल के परिणाम

अनंतिम (provisional) हैं या उन्हें एक निर्धारित वॉटरमार्क की आवश्यकता है। केवल SQL अधूरे इनपुट को अंतिम नहीं बना सकता।

क्या सटीक डिस्टिंक्ट (exact distinct) आवश्यक है? इंटरव्यू की क्वेरी सटीक है। बहुत बड़े पैमाने पर, एक अनुमानित

मर्जेबल-सेट रिप्रेजेंटेशन तभी स्वीकार्य हो सकता है जब उसके एरर अनुबंध को मंजूरी दी गई हो।

कौन सा डेटाबेस और स्केल लागू होता है? यह उत्तर PostgreSQL का उपयोग करता है। एक डेटा वेयरहाउस समान सेट सेमेंटिक्स

को बनाए रखते हुए दूसरे डेट-स्पाइन फ़ंक्शन या बिटमैप प्रिमिटिव का उपयोग कर सकता है।

30-सेकंड का उत्तर फ्रेमवर्क

“मैं पहले एक्टिव इवेंट्स, बहिष्करण, दिन की सीमा के रूप में America/New_York, और प्रति रिपोर्ट तिथि एक पंक्ति के आउटपुट ग्रेन को परिभाषित करूँगा। मैं 26 मई से स्कैन करूँगा क्योंकि 1 जून को छह पिछली तिथियों की आवश्यकता होती है, टाइमस्टैम्प को स्थानीय तिथियों में बदलूँगा, और प्रति उपयोगकर्ता प्रति तिथि एक पंक्ति में डिडुप्लिकेट करूँगा। फिर मैं generate_series के साथ 1 जून से 30 जून तक जनरेट करूँगा, प्रत्येक तिथि को date - 6 से उस तिथि तक की गतिविधि से लेफ्ट जॉइन करूँगा, और डिस्टिंक्ट उपयोगकर्ताओं की गणना करूँगा।

मैं दैनिक सक्रिय उपयोगकर्ताओं को नहीं जोड़ूँगा क्योंकि कई दिनों में सक्रिय उपयोगकर्ता को बार-बार गिना जाएगा। छह-पंक्ति वाली विंडो भी तिथियां गायब होने पर विफल हो जाती है और एक डिस्टिंक्ट यूनियन नहीं बनाती है। मैं मध्यरात्रि सीमाओं, डुप्लिकेट्स, खाली तिथियों और वॉर्म-अप गतिविधि का परीक्षण करूँगा, फिर एक as-of वॉटरमार्क प्रकाशित करूँगा या देर से आने वाले इवेंट्स आने पर हाल की तिथियों को रिफ्रेश करूँगा।”

चरण-दर-चरण विस्तृत विश्लेषण

चरण 1: मेट्रिक अनुबंध और इनपुट सीमा तय करें

अनुरोधित आउटपुट 1 जून से शुरू होता है, लेकिन सोर्स स्कैन 26 मई से शुरू होता है। केवल जून की पंक्तियों को पढ़ने से पहली छह रिपोर्ट तिथियों की कम गिनती होगी। ऊपरी सोर्स सीमा 1 जुलाई की स्थानीय मध्यरात्रि है; भविष्य की गतिविधि 30 जून को समाप्त होने वाली ट्रेलिंग विंडो के लिए अप्रासंगिक है।

फ़िल्टर में उन स्थानीय मध्यरात्रियों को timestamptz स्थिरांक में बदलें। यह इंडेक्स किए गए event_at कॉलम पर प्रेडिकेट को बनाए रखता है। WHERE क्लॉज के अंदर प्रत्येक सोर्स टाइमस्टैम्प को डेट में कास्ट करने से एक सामान्य रेंज इंडेक्स उपयोगी प्रूनिंग करने से रुक सकता है।

चरण 2: इवेंट्स को डिस्टिंक्ट यूज़र-डेज़ में सामान्यीकृत करें

बाउंडेड टाइमस्टैम्प फ़िल्टर लागू करने के बाद ही प्रत्येक क्वालिफाइंग इंस्टेंट को उसकी न्यूयॉर्क कैलेंडर तिथि में बदलें। फिर user_id और स्थानीय तिथि के अनुसार ग्रुप करें। एक अलग पंक्ति आईडी के साथ इवेंट का पुनः प्रयास और एक दिन में एक उपयोगकर्ता के बीस इवेंट, सभी एक यूज़र-डे बन जाते हैं।

यह डिडुप्लिकेशन अपने आप में अंतिम समस्या का समाधान नहीं करता है। यदि वही उपयोगकर्ता 1 जून और 2 जून को सक्रिय है, तो दोनों यूज़र-डे पंक्तियाँ उपलब्ध रहनी चाहिए ताकि किसी भी तिथि की ट्रेलिंग विंडो उस उपयोगकर्ता को शामिल कर सके।

चरण 3: एक पूर्ण डेट स्पाइन (Date Spine) तैयार करें

generate_series इवेंट की उपस्थिति की परवाह किए बिना प्रत्येक रिपोर्ट तिथि बनाता है। इवेंट टेबल से शुरू करने पर खाली तिथि छूट जाएगी, ROWS फ्रेम में पंक्तियों की संख्या बदल जाएगी, और डैशबोर्ड पर कोई शून्य-मूल्य वाला बिंदु नहीं रहेगा। स्पाइन आधिकारिक आउटपुट ग्रेन है।

चरण 4: प्रत्येक विंडो के लिए डिस्टिंक्ट यूनियन की गणना करें

सीधी सटीक क्वेरी है:

sql

WITH params AS (
  SELECT
    DATE '2026-06-01' AS report_start,
    DATE '2026-06-30' AS report_end
),
activity_days AS (
  SELECT
    e.user_id,
    (e.event_at AT TIME ZONE 'America/New_York')::date AS activity_date
  FROM events AS e
  WHERE e.event_at >= TIMESTAMPTZ '2026-05-26 00:00:00 America/New_York'
    AND e.event_at <  TIMESTAMPTZ '2026-07-01 00:00:00 America/New_York'
    AND e.event_name IN ('app_open', 'view_dashboard', 'run_report')
    AND e.is_internal_user = false
  GROUP BY
    e.user_id,
    (e.event_at AT TIME ZONE 'America/New_York')::date
),
report_dates AS (
  SELECT gs::date AS report_date
  FROM params AS p
  CROSS JOIN generate_series(
    p.report_start,
    p.report_end,
    INTERVAL '1 day'
  ) AS gs
)
SELECT
  d.report_date,
  COUNT(DISTINCT a.user_id) AS rolling_7d_active_users
FROM report_dates AS d
LEFT JOIN activity_days AS a
  ON a.activity_date BETWEEN d.report_date - 6 AND d.report_date
GROUP BY d.report_date
ORDER BY d.report_date;

लेफ्ट जॉइन खाली रिपोर्ट तिथियों को बनाए रखता है। COUNT(DISTINCT a.user_id) एक बेमेल लेफ्ट जॉइन द्वारा उत्पादित नल (null) को अनदेखा करता है। अंतराल में ठीक सात date मान शामिल हैं: वर्तमान तिथि और छह पिछली तिथियां।

चरण 5: सिद्ध करें कि सामान्य विंडो शॉर्टकट क्यों विफल होता है

मान लीजिए यूज़र A सोमवार और मंगलवार को सक्रिय है, जबकि यूज़र B केवल मंगलवार को सक्रिय है। DAU क्रमशः 1 और 2 है, लेकिन दो-दिवसीय डिस्टिंक्ट यूनियन 2 है, 3 नहीं। एक बार जब दैनिक गणना उपयोगकर्ता की पहचान की जगह ले लेती है, तो SQL यह पता नहीं लगा सकता कि A दोनों दिनों में उपस्थित है।

पंक्ति फ्रेम (row frame) एक और त्रुटि लाता है। यदि बुधवार को कोई इवेंट नहीं है और वह इनपुट से गायब है, तो “छह पिछली पंक्तियाँ” कैलेंडर में आठ या उससे अधिक दिन पीछे जा सकती हैं। एक डेट स्पाइन कैलेंडर गैप्स को ठीक करता है, लेकिन DAU पर एक रोलिंग योग अभी भी पहचानों की दोहरी गणना करता है। सही प्रक्रिया है: पहले यूनियन, फिर कार्डिनैलिटी।

चरण 6: सेमेंटिक्स बदले बिना स्केल करें

मध्यम रेंज के लिए, रॉ डेटा को event_at द्वारा इंडेक्स करें और 7x अंतराल जॉइन से पहले इसे यूज़र-डेज़ में कम करें। (activity_date, user_id) द्वारा की (keyed) की गई एक मटीरियलाइज्ड दैनिक गतिविधि टेबल रॉ इवेंट्स को फिर से स्कैन करने से बचाती है। पार्टीशन प्रूनिंग में वॉर्म-अप तिथियां शामिल होनी चाहिए।

लंबी रिपोर्ट रेंज के लिए, प्रत्येक यूज़र-डे को अधिकतम सात पात्र रिपोर्ट तिथियों में विस्तारित करें, उन तिथियों को अनुरोधित सीमा तक सीमित करें, और फिर डिस्टिंक्ट यूज़र्स को समूहीकृत करें। यह जॉइन के आकार को बदलता है लेकिन सबसे खराब स्थिति वाले 7x विस्तार को नहीं। सटीक बिटमैप सेट वाले इंजन दैनिक उपयोगकर्ता बिटमैप को यूनियन कर सकते हैं; अनुमानित स्केच को सेट यूनियन का समर्थन करना चाहिए और मापी गई त्रुटि को प्रदर्शित करना चाहिए। दैनिक HyperLogLog अनुमानों को जोड़ना मान्य नहीं है क्योंकि यूनियन प्राप्त करने के लिए अनुमानित कार्डिनैलिटीज़ को जोड़ा नहीं जा सकता है।

चरण 7: लेट डेटा और वेरिफिकेशन को परिभाषित करें

परिणाम के साथ एक as_of वॉटरमार्क प्रकाशित करें। यदि पाइपलाइन तीन दिन तक की देरी से आने वाले इवेंट्स को स्वीकार करती है, तो कम से कम उन सभी रिपोर्ट तिथियों को रिफ्रेश करें जिनकी सात-दिवसीय इनपुट विंडो परिवर्तनशील (mutable) डेटा के साथ ओवरलैप करती है। एक स्थिर इवेंट आईडी इनजेशन डिडुप्लिकेशन में मदद करती है, जबकि यूज़र-डे ग्रुपिंग इस मेट्रिक को कई क्वालिफाइंग इवेंट्स से बचाती है; इनमें से कोई भी पूर्णता निगरानी (completeness monitoring) की जगह नहीं लेता है।

डुप्लिकेट इवेंट्स, कई तिथियों पर समान उपयोगकर्ता, एक आंतरिक उपयोगकर्ता, एक गैर-पात्र इवेंट, 26 मई और 31 मई के वॉर्म-अप इवेंट्स, एक खाली तिथि, दोनों तरफ स्थानीय-मध्यरात्रि इंस्टेंट्स, और एक डेलाइट-सेविंग सीमा के साथ एक हस्तनिर्मित टेस्ट ओरेकल का उपयोग करें। एक सरल एप्लिकेशन-स्तरीय सेट यूनियन के साथ प्रत्येक आउटपुट तिथि की तुलना करें। प्रोडक्शन जैसे वॉल्यूम पर EXPLAIN (ANALYZE, BUFFERS) चलाएं और सोर्स प्रूनिंग, यूज़र-डे कार्डिनैलिटी, जॉइन विस्तार, रनटाइम और स्पिल व्यवहार को सत्यापित करें।

मजबूत नमूना उत्तर

“मैं SQL लिखने से पहले सेट को परिभाषित करूँगा: एक पात्र उपयोगकर्ता के पास कम से कम एक स्वीकृत उत्पाद इवेंट होता है, आंतरिक उपयोगकर्ताओं को बाहर रखा जाता है, और एक दिन का अर्थ America/New_York है। रिपोर्ट तिथि D के लिए, सेट वह प्रत्येक पात्र उपयोगकर्ता है जिसकी स्थानीय गतिविधि तिथि D घटा छह और D के बीच (दोनों शामिल) है। आउटपुट में सभी तीस तिथियां होनी चाहिए।

मैं 26 मई की स्थानीय मध्यरात्रि से 1 जुलाई की स्थानीय मध्यरात्रि तक रॉ टाइमस्टैम्प को फ़िल्टर करूँगा, जिसमें ऊपरी सीमा को एक्सक्लूसिव रखूँगा। फ़िल्टर करने के बाद, मैं स्थानीय तिथियों में कनवर्ट करता हूँ और उपयोगकर्ता और तिथि के अनुसार ग्रुप करता हूँ। एक generate_series स्पाइन 1 जून से 30 जून की आपूर्ति करता है। प्रत्येक स्पाइन तिथि अपने ट्रेलिंग अंतराल में यूज़र-डेज़ को लेफ्ट जॉइन करती है, और COUNT(DISTINCT user_id) यूनियन कार्डिनैलिटी लौटाता है।

मैं SUM(DAU) को अस्वीकार करूँगा क्योंकि कई तिथियों पर सक्रिय पहचान दोहराई जाती हैं, और ROWS 6 PRECEDING को अस्वीकार करूँगा क्योंकि पंक्तियाँ कैलेंडर तिथियां नहीं हैं और दैनिक एकत्रीकरण ने पहचान को हटा दिया था। स्केल के लिए मैं (activity_date, user_id) को मटीरियलाइज़ करूँगा, वॉर्म-अप रेंज को प्रून करूँगा, और सटीक बिटमैप यूनियन या मापे गए अनुमानित सेट यूनियन पर तभी विचार करूँगा जब सटीक आउटपुट की आवश्यकता न हो। परिणाम में एक as_of वॉटरमार्क होता है, और लेट डेटा सीमित पुनर्गणना को ट्रिगर करता है।”

सामान्य गलतियाँ

सात DAU मानों को जोड़ना → दोहराए गए उपयोगकर्ताओं को प्रत्येक सक्रिय तिथि पर एक बार गिना जाता है → पूरी विंडो में उपयोगकर्ता पहचानों का यूनियन करें, फिर गिनें।
स्पार्स (sparse) तिथियों पर ROWS 6 PRECEDING का उपयोग करना → छह पंक्तियाँ छह से अधिक पिछली तिथियों में फैल सकती हैं → एक पूर्ण कैलेंडर स्पाइन जनरेट करें और कैलेंडर सीमाओं को व्यक्त करें।
केवल जून को स्कैन करना → शुरुआती जून की विंडो मई की गतिविधि को खो देती है → छह-दिन का वॉर्म-अप शामिल करें।
सोर्स फ़िल्टर में event_at कास्ट करना → एक साधारण टाइमस्टैम्प इंडेक्स कुशलतापूर्वक प्रून नहीं कर सकता है → स्थानीय तिथि प्राप्त करने से पहले हाफ-ओपन timestamptz सीमाओं के साथ फ़िल्टर करें।
रॉ इवेंट्स की गिनती करना → पुनः प्रयास और बार-बार उपयोग उपयोगकर्ताओं की संख्या बढ़ा देते हैं → यूज़र-डे में डिडुप्लिकेट करें और फिर भी अंतिम विंडो में डिस्टिंक्ट काउंट करें।
इवेंट्स से आउटपुट तिथियां निकालना → खाली तिथियां गायब हो जाती हैं → डेट स्पाइन को आउटपुट ग्रेन बनाएं।
हाल के आउटपुट को अंतिम कहना → देर से आने वाले इवेंट्स सेट को बदल सकते हैं → एक वॉटरमार्क प्रकाशित करें और प्रभावित विंडो को रिफ्रेश करें।
अनुमानित दैनिक कार्डिनैलिटीज़ को जोड़ना → कार्डिनैलिटी जोड़ ओवरलैप को नहीं हटा सकता है → यूनियन का अनुमान लगाने से पहले सेट-सक्षम स्केच या बिटमैप को मर्ज करें।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: यदि मेट्रिक का अर्थ पिछले 168 घंटे हो तो क्या बदलता है?

स्थानीय date मानों के बजाय इंस्टेंट्स की तुलना करें। प्रत्येक रिपोर्ट इंस्टेंट के लिए, (report_at - interval '168 hours', report_at] जैसी एक हाफ-ओपन टाइमस्टैम्प विंडो का उपयोग करें, जिसमें सटीक उत्पाद सीमा बताई गई हो। डेलाइट-सेविंग ट्रांजिशन के आसपास, यह सात न्यूयॉर्क कैलेंडर तिथियों से भिन्न होता है। एक परिभाषा को दूसरी का नाम न दें।

फॉलो-अप 2: क्या कोई विंडो फ़ंक्शन अपने आप सटीक रोलिंग डिस्टिंक्ट को हल कर सकता है?

एक विंडो एग्रीगेट तब उपयोगी होता है जब एग्रीगेट पंक्ति मानों से बना हो, जैसे कि रोलिंग योग। यहाँ, आवश्यक स्थिति विलोपन (deletion) वाला एक सेट है जब पुरानी तिथियां विंडो से बाहर निकलती हैं। प्रत्यक्ष PostgreSQL उत्तर पहचानों को बनाए रखता है और उन्हें रिपोर्ट तिथियों से जोड़ता है। एक विशेष इंजन सटीक बिटमैप-यूनियन विंडोइंग की सुविधा दे सकता है, लेकिन यह इंजन की एक विशेषता है, दैनिक गणनाओं को जोड़ने का कोई कारण नहीं।

फॉलो-अप 3: कोई इवेंट तीन दिन देर से आने के बाद आप कैसे रिफ्रेश करेंगे?

इवेंट की स्थानीय गतिविधि तिथि A ज्ञात करें। यह रिपोर्ट तिथियों A से लेकर A प्लस छह तक को प्रभावित कर सकता है, जो प्रकाशित रेंज के साथ ओवरलैप करती हैं। केवल उन पार्टीशन्स की पुनर्गणना करें या उन्हें बदलें, समाधान (reconciliation) के बाद वॉटरमार्क को आगे बढ़ाएं, और ऑपरेशन को आइडम्पोटेंट (idempotent) रखें। केवल तिथि A को रिफ्रेश करने से डाउनस्ट्रीम की छह विंडो छूट जाती हैं।

फॉलो-अप 4: आप देश के अनुसार सेगमेंट कैसे करेंगे?

पहले परिभाषित करें कि देश इवेंट से संबंधित है, उपयोगकर्ता की वर्तमान प्रोफ़ाइल से, या गतिविधि के समय की स्लोली चेंजिंग प्रोफ़ाइल (slowly changing profile) से। वह विकल्प ऐतिहासिक सत्य को बदल देता है। चुने गए देश को यूज़र-डे ग्रेन, डेट स्पाइन, ग्रुपिंग और वैलिडेशन ओरेकल में जोड़ें। जब कोई उपयोगकर्ता स्थान बदलता है तो वर्तमान-प्रोफ़ाइल जॉइन इतिहास को फिर से लिख सकता है।

फॉलो-अप 5: क्या होगा यदि सटीक डिस्टिंक्ट बहुत महंगा हो?

पहले सटीक क्वेरी को मापें। यदि स्वीकृत एरर बजट अनुमान की अनुमति देता है, तो प्रति गतिविधि तिथि और सेगमेंट में एक मर्जेबल सेट स्केच संग्रहीत करें, सात स्केच को यूनियन करें और एक बार अनुमान लगाएं। कम, सामान्य और उच्च-कार्डिनैलिटी वाले स्लाइस के लिए सटीक सेट के मुकाबले पूर्वाग्रह (bias) और सापेक्ष त्रुटि को मान्य करें। बिलिंग, पात्रता या अन्य निर्णयों के लिए सटीक प्रोसेसिंग रखें जो अनुमान त्रुटि को बर्दाश्त नहीं करते हैं।