Business Analytics Quiz: Data Cleaning And Preprocessing
10 questions · exam conditions
0:00
Data Cleaning And PreprocessingQuestion 1 of 10

A company is building a churn model from customer records. Annual income is missing for thirty percent of customers in one region and four percent elsewhere, and typical income differs substantially by region. The data has already been divided chronologically into training and validation sets.

Which method most appropriately preprocesses annual income while limiting bias and avoiding validation leakage?

Estimate regional medians from the training set, use a training-set fallback median, and apply them unchanged to validation.
Estimate regional medians from the combined training and validation sets, then apply them to both sets.
Delete every record with missing income from both sets so the model uses only observed values.
Estimate separate regional medians within each set, then impute training and validation independently.
← Back to quizzes

Business Analytics Quiz

Business Analytics Quiz: Data Cleaning And Preprocessing

Practice Data Cleaning And Preprocessing in Business Analytics with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Data Cleaning And Preprocessing, giving you a quick way to practice the rules, question types, and explanations that matter most for Business Analytics.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A company is building a churn model from customer records. Annual income is missing for thirty percent of customers in one region and four percent elsewhere, and typical income differs substantially by region. The data has already been divided chronologically into training and validation sets.

Which method most appropriately preprocesses annual income while limiting bias and avoiding validation leakage?

  1. Estimate regional medians from the training set, use a training-set fallback median, and apply them unchanged to validation. (correct answer)
  2. Estimate regional medians from the combined training and validation sets, then apply them to both sets.
  3. Delete every record with missing income from both sets so the model uses only observed values.
  4. Estimate separate regional medians within each set, then impute training and validation independently.
Explanation: When preprocessing data for a predictive model, your guiding principle should be: statistics used for imputation must come only from the training set, and they must be applied consistently to new data. This prevents "validation leakage," where information from the validation set illegally influences your preprocessing and inflates apparent model performance. Answer A is correct because it follows this principle precisely. You calculate regional medians using only training data, create a fallback median (also from training) for any region too sparse to estimate reliably, and then apply those fixed values to the validation set without recalculating anything. Since income varies substantially by region, regional medians are far more accurate imputations than a single global median — and because thirty percent of one region's data is missing, a fallback prevents errors when a region has no usable training records. Answer B introduces leakage by computing medians from the combined training and validation sets. The validation set's values are "peeking" into the imputation step, which artificially optimizes preprocessing for data the model is supposed to encounter cold. This produces overly optimistic evaluation metrics. Answer C is tempting because it avoids imputation entirely, but deleting thirty percent of records in one region creates severe selection bias — your model learns from a systematically unrepresentative sample of that region's customers, likely degrading churn predictions for exactly that population. Answer D seems symmetrical but is subtly wrong: imputing validation records using validation-set medians means your validation preprocessing differs from what would happen in production, making the evaluation unrealistic. Study tip: Any transformation — scaling, encoding, imputation — should be fit on training data only and applied to all other sets. Treat your validation set as if it arrived after deployment.

Question 2

An online retailer stores one row per order in an orders file and one or more rows per order in a shipments file. After an analyst joins the files, the row count increases from 10,00010{,}000 to 14,00014{,}000 and reported booked revenue increases by 2828 percent. Management needs order-level booked revenue and an indicator of whether each order was delivered on time.

Which preprocessing approach best supports both metrics without inflating revenue?

  1. Aggregate shipments to one order-level record, then left-join that result to the orders file. (correct answer)
  2. Join all shipment records to orders, then calculate revenue using the distinct revenue amounts.
  3. Keep the first joined shipment row for each order, then discard every remaining shipment row.
  4. Join all shipment records to orders, then divide each order's revenue by its shipment count.
Explanation: When you join a one-to-many relationship — like orders to shipments — every extra shipment row duplicates the order's revenue, inflating totals. That's exactly what happened here: the row count jumped from 10,00010{,}000 to 14,00014{,}000, and revenue appeared to grow by 28%28\% even though no new sales occurred. Your goal is to preserve order-level granularity while still capturing shipment details like on-time delivery status. Option A is the correct approach because it solves the fan-out problem before the join ever happens. By aggregating the shipments file down to one row per order first — for example, taking the maximum or minimum ship date to determine on-time status — you then left-join that collapsed result to the orders file. The result is one row per order, revenue is counted exactly once, and the on-time indicator is cleanly derived. Both metrics are supported without distortion. Option B is tempting but flawed. Using "distinct revenue amounts" doesn't reliably de-duplicate revenue; if two shipments happen to share the same amount, the logic breaks, and the approach is structurally fragile rather than principled. Option C arbitrarily keeps only the first shipment row, which risks losing on-time delivery data from subsequent shipments — you can't determine true delivery status by ignoring part of the record. Option D divides revenue by shipment count, which is a mathematical patch rather than a structural fix. It produces fractional, nonsensical revenue per row and still leaves you with multiple rows per order. The study tip: whenever a join increases your row count unexpectedly, ask which side has multiple rows and aggregate that side before joining — don't try to correct inflation after the fact.

Question 3

A delivery dashboard contains 100100 orders. The recorded delivery-time values total 460460 days, but 88 records contain zero because those orders have not yet been delivered. The business definition of average delivery time includes only completed deliveries.

What cleaning action and revised descriptive metric are appropriate?

  1. Retain the zeros as valid durations and report an average of 4.64.6 days.
  2. Recode the zeros as missing and report an average of 5.05.0 days. (correct answer)
  3. Recode the zeros as missing and report an average of 4.64.6 days.
  4. Replace the zeros with the current average and report an average of 5.45.4 days.
Explanation: Whenever you encounter data-cleaning questions, ask two things: (1) Should these values be excluded or imputed? and (2) Does the recalculation reflect that change? Both steps must be correct together. Here, eight orders have a recorded delivery time of zero — not because they were delivered instantly, but because they haven't been delivered yet. The business definition explicitly limits the average to completed deliveries, so those zeros are not valid data points; they are placeholders for missing information. The right move is to recode them as missing and remove them from the calculation entirely. That leaves 100−8=92100 - 8 = 92 completed orders with a total of 460460 days, giving an average of 46092=5.0\frac{460}{92} = 5.0 days. That's exactly what answer B does — correct cleaning action, correct arithmetic. A is wrong on both counts: retaining the zeros treats "not yet delivered" as a real duration of zero days, which violates the business definition and artificially pulls the average down to 460100=4.6\frac{460}{100} = 4.6 days. C gets the cleaning step right (recode as missing) but uses the wrong denominator — dividing 460460 by 100100 instead of 9292, producing 4.64.6 days. This is a classic trap: students apply the correct filter conceptually but forget to adjust the count. D uses mean imputation, replacing zeros with the current average. That technique is sometimes used to preserve sample size, but it distorts the distribution and is inappropriate when the business rule says to exclude incomplete records outright. The key study tip: on data-cleaning questions, always verify both the method and the recalculated statistic — a correct concept paired with a wrong number is still a wrong answer.

Question 4

A predictive model uses a standardized monthly-spending variable. In the training set, the mean is 5050 and the standard deviation is 1010. A validation customer has monthly spending of 8080. The scaler will later be used for newly arriving customers.

Which preprocessing decision and transformed validation value are appropriate?

  1. Fit the scaler on training data only and transform the validation value to 33. (correct answer)
  2. Refit the scaler on validation data and transform the value using validation-period statistics.
  3. Fit the scaler on all available data and transform the value using combined-period statistics.
  4. Cap the value at two training deviations above the mean and transform it to 22.
Explanation: Whenever you see a question about preprocessing in predictive modeling, ask yourself: whose statistics should define the transformation, and why? The core principle is that a scaler must be fit on training data alone, then applied consistently to all other datasets — validation, test, and future production data. Here's why: standardization transforms a value using z=x−μσz = \frac{x - \mu}{\sigma}. For a validation customer spending 8080, you apply the training mean (5050) and standard deviation (1010): z=80−5010=3z = \frac{80 - 50}{10} = 3. This is exactly what A does — fit on training, transform consistently. It's the correct answer. B is wrong because refitting the scaler on validation data introduces data leakage in reverse — you'd be using future information (validation statistics) to define your transformation, making the pipeline inconsistent. When new customers arrive, you won't have their aggregate statistics to refit on. C is wrong for the same fundamental reason: fitting on combined training and validation data contaminates the scaler with validation information. This inflates your model's apparent generalizability and makes the pipeline unreproducible for new data. D is a plausible-sounding but incorrect distractor. Capping at two standard deviations (μ+2σ=70\mu + 2\sigma = 70) and transforming to 22 arbitrarily discards valid signal. Nothing in the problem justifies truncating the value, and this isn't a standard preprocessing rule. Study tip: Always think of your scaler as a "frozen recipe" learned from training data only — it must never be recooked using validation or test ingredients.

Question 5

A grocery chain is preparing demand data for a prescriptive inventory model. On several days, recorded sales are zero and the inventory system shows that the item was out of stock for the entire day. The optimization model will use historical demand to set reorder quantities.

Which preprocessing treatment is most appropriate for those days?

  1. Treat zero sales as zero demand because only completed purchases should influence reorder quantities.
  2. Flag the observations as stockout-censored and estimate demand from comparable in-stock periods. (correct answer)
  3. Delete every zero-sales day, including days when inventory was available throughout the day.
  4. Replace each zero with the item's highest observed daily sales to avoid underordering inventory.
Explanation: Whenever you see a question involving historical demand data for an optimization model, ask yourself: does the recorded value actually reflect true demand, or was demand artificially constrained? This distinction is critical in prescriptive analytics. When a store runs out of stock, customers who would have purchased the item simply can't. The register records zero sales, but true demand was almost certainly greater than zero. This is called censored data — the observation doesn't reveal the full signal, only a lower bound. If you feed these zeros into a reorder model as if they represent true demand, the model systematically underestimates demand and will keep setting reorder quantities too low, perpetuating the stockout cycle. Answer B correctly identifies this problem: flag those days as stockout-censored and estimate latent demand using comparable in-stock periods (e.g., similar days of the week, seasonality, or neighboring stores). This preserves the integrity of the demand signal the model actually needs. Answer A is tempting but fundamentally wrong — it confuses sales with demand. Only completed transactions were recorded, not what customers wanted. Using sales as a proxy for demand is only valid when inventory was available. Answer C compounds the error by also deleting legitimate zero-demand days (perhaps the store was open but nobody wanted that item), which discards genuinely useful signal and introduces selection bias. Answer D overcorrects recklessly — substituting the historical maximum inflates demand estimates with no statistical justification, likely driving excess inventory and waste. Your takeaway: in any data-quality question involving operational constraints (stockouts, capacity limits, survey non-response), always ask whether the recorded value was prevented from reflecting true demand — that's the censoring red flag.

Question 6

A customer-acquisition model uses marketing channel as a categorical predictor. The training data contains Email, Search, and Social. Production data may contain new channels, and the deployed scoring process must always produce the same number of input columns.

Which preprocessing design best handles future unseen channel values?

  1. Replace every unseen value with the most frequent channel from the current production batch.
  2. Create a new indicator column whenever an unseen value appears during production scoring.
  3. Refit the categorical encoder on each production batch before generating model predictions.
  4. Fit a fixed training-based encoder with an Other category and map unseen values to that category. (correct answer)
Explanation: When you see a question about categorical encoding in a deployed ML pipeline, the core tension is between training-time consistency and production-time flexibility. The model was built expecting a fixed set of input columns — any preprocessing that changes that structure after deployment will break the pipeline or silently corrupt predictions. The right approach is D: fit your encoder once during training and include an explicit "Other" bucket to absorb any value that wasn't seen in training. This means unseen channels like "Podcast" or "TV" get mapped to the Other category, the column count stays identical to what the model was trained on, and predictions flow through without errors. The model may not perfectly represent these new channels, but it degrades gracefully rather than failing. A is flawed because replacing unseen values with the most frequent production channel is data leakage-adjacent thinking — it uses batch-level statistics that weren't available at training time and introduces inconsistency across batches. B is arguably the most dangerous trap: dynamically creating new columns at scoring time directly violates the fixed-schema requirement and would crash most deployed models, since the feature space no longer matches what the model expects. C sounds sophisticated but is actually a serious mistake — refitting the encoder on production data changes the encoding of existing categories (e.g., which integer Email maps to), which can silently corrupt all predictions, not just those for unseen values. As a study tip: in deployment questions, always ask yourself "does this change the schema or statistics the model was trained on?" If yes, it's almost certainly wrong.

Question 7

A transaction file includes quantity, unit price, discount, and net sales. The data dictionary states that net sales is derived as quantity multiplied by unit price and then reduced by the discount. One record has quantity 1010, unit price 125125, no discount, and net sales of 12,50012{,}500. The quantity and unit price match the source invoice.

How should the analyst handle this record before calculating profit-margin metrics?

  1. Winsorize net sales at a selected percentile because the recorded amount appears unusually large.
  2. Delete the entire transaction because any internally inconsistent record is unsuitable for analysis.
  3. Correct net sales to 1,2501{,}250 using the trusted fields and document the consistency rule. (correct answer)
  4. Retain net sales of 12,50012{,}500 because recorded totals should override component-level fields.
Explanation: When a transaction file contains a derived field — one calculated from other fields — your first job as an analyst is to verify internal consistency before trusting any aggregated metric. Here, the data dictionary defines net sales as quantity×unit price−discount\text{quantity} \times \text{unit price} - \text{discount}, so you can immediately audit the record: 10×125−0=1,25010 \times 125 - 0 = 1{,}250, not 12,50012{,}500. The recorded net sales is off by a factor of ten. Because the quantity and unit price are verified against the source invoice, those fields are your trusted anchor. The correct move — answer C — is to recalculate net sales as 1,2501{,}250, correct the erroneous derived value, and document the consistency rule you applied. Using corrupted data to calculate profit-margin metrics would silently inflate results. Answer A is wrong because Winsorizing addresses extreme-but-valid outliers in a distribution, not arithmetic errors. The issue here isn't that 12,50012{,}500 is statistically unusual — it's that it contradicts the formula. Applying Winsorization would leave the mistake intact. Answer B is wrong because deleting the record wastes perfectly good data. The source fields are verified and reliable; only the derived field needs correction. Wholesale deletion is a last resort when the record cannot be salvaged, not when a simple recalculation resolves the problem. Answer D is wrong because it inverts the trust hierarchy. Derived fields depend on component fields — if the components are verified, the derived total must be recalculated from them, not treated as authoritative. A useful rule of thumb: verified components outrank derived totals. When the calculation chain is broken, fix the output, not the inputs.

Question 8

A retailer stores transaction timestamps in Coordinated Universal Time but reports daily sales according to each store's local calendar date. Stores operate in several time zones, some of which observe daylight-saving changes.

Which sequence should be used to create the daily-sales date field?

  1. Extract the Coordinated Universal Time date first, then attach each store's time-zone label.
  2. Convert each timestamp with the store's time-zone rules, then extract the resulting local date. (correct answer)
  3. Subtract one fixed offset from every timestamp, then extract a common reporting date.
  4. Extract the server date and shift only transactions recorded near the end of each month.
Explanation: Whenever you see a question about time zones and date reporting, your guiding principle should be: always convert first, then extract. The local calendar date is a product of the local time, not the server time — so you must establish the local moment before you can label it with a date. Here's why B is correct: a UTC timestamp like 2024-03-10 02:30 UTC could represent March 9th in a U.S. store (behind UTC) or March 10th in a European store (ahead of UTC). You must apply each store's specific time-zone rules — including any daylight-saving offset in effect at that exact moment — to convert the timestamp into local time. Only after that conversion can you extract the correct local date. This sequence guarantees each transaction lands on the calendar day the customer actually experienced. A fails because extracting the UTC date first locks you into the wrong date before any conversion happens. Attaching a time-zone label afterward doesn't fix a date that was already extracted incorrectly. C is tempting but dangerous: a single fixed offset cannot represent multiple time zones, and it completely ignores daylight-saving transitions, which shift offsets seasonally. One constant subtracted from every timestamp will misclassify transactions near those transition boundaries. D is a patch, not a solution. Adjusting only end-of-month transactions is arbitrary and misses countless misclassifications that occur at the start and end of every single day across all time zones. Your study tip: on any time-zone question, ask yourself, "Have I established the local moment before I extracted anything?" If the answer is no, the logic is flawed.

Question 9

Customer-entered city values include New York, new york, New York followed by spaces, Newark, and New York City. The values will be used to summarize sales by city. An analyst wants to reduce artificial category fragmentation without combining genuinely different cities.

Which cleaning procedure is most defensible?

  1. Apply unrestricted fuzzy matching and merge every pair of city names above a broad similarity threshold.
  2. Convert all city names to uppercase and treat the resulting strings as fully standardized categories.
  3. Trim whitespace, normalize case, and apply an audited mapping of known equivalent city labels. (correct answer)
  4. Retain every original string and allow the reporting software to infer equivalent geographic categories.
Explanation: When cleaning categorical data for aggregation, your goal is to collapse artificial variation (typos, inconsistent formatting) while preserving meaningful distinctions between genuinely different values. That balance is the core tension this question tests. The most defensible approach is C: trim whitespace, normalize case, and apply an audited mapping of known equivalents. Trimming removes trailing spaces (catching "New York "), case normalization merges "New York" and "new york," and an explicit, human-reviewed mapping lets you deliberately decide that "New York" and "New York City" should—or should not—be combined. Every merge is transparent and reversible. This is why C is correct. A is the most dangerous distractor. Unrestricted fuzzy matching with a broad threshold will automatically merge strings based on character similarity, which means "Newark" and "New York" could be collapsed into the same category—silently destroying real geographic distinctions. Fuzzy matching is a useful tool, but only when constrained and audited. B sounds systematic, but uppercasing alone doesn't resolve the whitespace problem or distinguish "NEW YORK" from "NEWARK." It addresses only one dimension of variation and creates a false sense of standardization. D assumes the reporting tool has geographic intelligence it almost certainly lacks. Most BI tools treat strings as literals—"New York" and "new york" remain separate buckets. Deferring cleaning to downstream software is not a strategy; it's neglect. Your study tip: whenever a data-cleaning question mentions merging categories, ask whether the merge is controlled and auditable. Automated or passive methods that merge without human review are almost always wrong on these exams.

Question 10

In an A/B test, assignment occurs once per user. The event log contains multiple sessions per user, duplicate purchase events caused by payment retries, and no event rows for some assigned users. The primary metric is the percentage of assigned users who complete at least one valid purchase within fourteen days.

Which preprocessing workflow produces the intended conversion metric?

  1. Deduplicate purchase amounts, retain one row per amount, and divide by assigned treatment users.
  2. Count all purchase-event rows by treatment and divide each count by the treatment's session total.
  3. Remove users without event rows, deduplicate sessions, and calculate purchasers among remaining users.
  4. Deduplicate valid orders, create one purchase indicator per user, and left-join it to all assigned users. (correct answer)
Explanation: When designing conversion metrics in A/B testing, your first instinct should be to map the metric definition precisely to your data pipeline. Here, the metric is percentage of assigned users who complete at least one valid purchase — so your denominator must be all assigned users and your numerator must be distinct purchasers, nothing else. Option D achieves exactly this. By deduplicating valid orders (eliminating payment-retry duplicates) and collapsing each user to a single purchase indicator, you get a clean binary per user. Left-joining that indicator to the full assigned-user table ensures users with no event rows are preserved as non-converters rather than silently dropped. The result is: Conversion Rate=Users with ≥1 valid purchaseAll assigned users\text{Conversion Rate} = \frac{\text{Users with } \geq 1 \text{ valid purchase}}{\text{All assigned users}} Option A goes wrong by deduplicating on purchase amount rather than on order identity — two different orders of the same dollar value would be incorrectly collapsed into one, distorting the numerator. Option B divides by session totals instead of assigned users, which is the wrong denominator entirely. Session counts fluctuate independently of assignment, making this metric meaningless for measuring user-level conversion. Option C removes users without event rows before calculating conversion. This inflates your conversion rate by shrinking the denominator — it excludes exactly the non-converters you need to count, introducing selection bias into the metric. A reliable study tip: whenever a question involves user-level metrics, always ask yourself two things — who is in my denominator? and have I correctly deduplicated my numerator? These two checks will catch most preprocessing errors on exam questions like this.