Business Analytics Quiz: Creating Derived Variables
10 questions · exam conditions
0:00
Creating Derived VariablesQuestion 1 of 10

A subscription company builds a model at each month-end snapshot to predict whether a customer will renew during the following 30 days. Every feature must be constructible using information available no later than the snapshot timestamp.

Which derived feature is valid for model training without introducing future-information leakage?

The count of invoices paid during the 3030 days following the snapshot
The days from the snapshot to the contract expiration date scheduled at the snapshot
The average number of sessions from the snapshot through the next 1414 days
An indicator for whether a cancellation request is recorded during the next 3030 days
← Back to quizzes

Business Analytics Quiz

Business Analytics Quiz: Creating Derived Variables

Practice Creating Derived Variables 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 Creating Derived Variables, 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 subscription company builds a model at each month-end snapshot to predict whether a customer will renew during the following 30 days. Every feature must be constructible using information available no later than the snapshot timestamp.

Which derived feature is valid for model training without introducing future-information leakage?

  1. The count of invoices paid during the 3030 days following the snapshot
  2. The days from the snapshot to the contract expiration date scheduled at the snapshot (correct answer)
  3. The average number of sessions from the snapshot through the next 1414 days
  4. An indicator for whether a cancellation request is recorded during the next 3030 days
Explanation: When building predictive models on time-stamped snapshots, the golden rule is that every feature must be knowable at the moment the snapshot is taken — never afterward. This is called avoiding data leakage, and violating it produces a model that appears to perform well in training but fails completely in production, where the future is genuinely unknown. Choice B is the valid feature. The contract expiration date is a field already recorded in the system at snapshot time — it was set when the contract was signed. The days until expiration is simply a calculation: expiration date−snapshot date\text{expiration date} - \text{snapshot date}. No future events are required. This makes it a clean, leakage-free feature that also carries real predictive power (customers close to expiration are more likely to face a renewal decision imminently). Choices A, C, and D all commit the same fundamental error: they require observing events that occur after the snapshot. Choice A counts invoices paid in the 30 days following the snapshot — that window hasn't happened yet. Choice C averages sessions from the snapshot through the next 14 days — again, future data. Choice D flags cancellation requests recorded in the next 30 days — this is especially dangerous because it's practically a direct proxy for the outcome you're trying to predict, making it an obvious but severe form of leakage. A reliable strategy: whenever you see a feature description, ask yourself "could a data engineer compute this value at 11:59 PM on snapshot day?" If the answer requires waiting even one minute into the future, the feature is invalid.

Question 2

A customer has two orders represented by three order-line records. The first order contains two units at 3030 each with a flat line discount of 1010, plus one unit at 5050 with no discount. The second order contains three units at 2020 each with a 10%10\% line discount. The company defines customer average order value as total net merchandise revenue divided by the number of distinct orders.

What value should be assigned to the customer's derived average_order_value feature?

  1. 77.0077.00, after calculating net revenue by order and averaging the two orders (correct answer)
  2. 85.0085.00, after calculating gross revenue by order but ignoring both discounts
  3. 51.3351.33, after averaging the net revenue of the three order-line records
  4. 154.00154.00, after summing net merchandise revenue without dividing by order count
Explanation: When building derived features in business analytics, the key is to follow the business definition precisely — here, average order value means total net revenue divided by distinct order count. Any deviation from that definition produces a meaningless or misleading metric. Start by computing net revenue per order line. Order 1 has two lines: two units at $30\$30 minus the $10\$10 flat discount gives $50\$50, and one unit at $50\$50 with no discount gives $50\$50. Order 1 net total: $100\$100. Order 2 has three units at $20\$20 with a 10%10\% line discount: 3×20×0.90=$543 \times 20 \times 0.90 = \$54. Total net revenue across both orders: $100+$54=$154\$100 + \$54 = \$154. Dividing by 2 distinct orders gives $77.00\$77.00, confirming A is correct. Choice B is wrong because it ignores both discounts entirely, inflating Order 1 to $110\$110 and Order 2 to $60\$60, yielding $85\$85 — gross revenue, not net. Choice C mistakes the unit of analysis: it averages across the three order-line records rather than the two orders, confusing granularity levels and producing $51.33\$51.33. Choice D correctly computes total net revenue ($154\$154) but forgets to divide by order count — it returns a total, not an average, violating the definition entirely. The study tip here: always anchor your calculation to the exact business definition of the metric. When you see "average X," identify both the numerator (what you sum) and the denominator (what you count), and verify each matches the stated definition before computing.

Question 3

A retailer estimates a difference-in-differences model for weekly sales using a treated-store indicator, a post-campaign indicator, and a derived interaction feature equal to treated multiplied by post. The estimated treated coefficient is 55, the post coefficient is 88, and the interaction coefficient is −3-3.

Which derived feature and coefficient identify the campaign's incremental effect beyond the general post-period change?

  1. The treated-store indicator alone, giving an incremental effect of 55
  2. The treated-by-post interaction feature, giving an incremental effect of −3-3 (correct answer)
  3. The post-campaign indicator alone, giving an incremental effect of 88
  4. The sum of post and interaction terms, giving an incremental effect of 55
Explanation: Whenever you encounter a difference-in-differences (DiD) question, anchor yourself to its core purpose: isolating a causal treatment effect by controlling for both pre-existing group differences and time trends that affect everyone. In a DiD model, the three components play distinct roles. The treated coefficient captures the baseline difference between treated and control stores before any campaign — it tells you the treated group was already different, not that the campaign did anything. The post coefficient captures the time trend shared by all stores — sales that would have risen (or fallen) regardless of the campaign. The interaction term (treated × post) is the one that isolates what happened only to treated stores only after the campaign began. That's the definition of an incremental causal effect, and here it equals −3-3, meaning the campaign actually reduced sales relative to what the parallel-trends assumption would predict. That makes B the correct answer. A is wrong because the treated coefficient (55) simply reflects a pre-existing difference between store types — it exists even without any campaign and cannot represent an incremental effect. C is wrong because the post coefficient (88) reflects economy-wide or seasonal trends affecting all stores, not the campaign's unique contribution. D is wrong because summing post and interaction (8+(−3)=58 + (-3) = 5) has no standard DiD interpretation; you'd be blending the general time trend with the treatment effect, which defeats the entire purpose of separating them. Your study tip: in any DiD setup, the interaction term always owns the causal effect. If an answer points elsewhere, it's describing context, not causation.

Question 4

A demand model creates a three-calendar-day moving-average sales feature at the start of each day. The feature uses only the three completed calendar days immediately before the prediction date. A store recorded sales of 100100 on Monday, 120120 on Tuesday, 00 on Wednesday because it was open but had no sales, 9090 on Thursday, and 150150 on Friday.

What moving-average feature should be generated at the start of Saturday?

  1. 9292, averaging all five completed days from Monday through Friday
  2. 120120, averaging the three most recent days that had positive recorded sales
  3. 8080, averaging Wednesday, Thursday, and Friday while retaining the genuine zero-sales day (correct answer)
  4. 240240, summing Thursday and Friday because Wednesday contributes no sales
Explanation: When you see a feature engineering question involving a moving average, focus on two things: the exact window specification and data integrity. Here, the model uses the three completed calendar days immediately before the prediction date — no more, no less, and no filtering. For Saturday, those three days are Wednesday, Thursday, and Friday, with sales of 00, 9090, and 150150. The correct feature is simply 0+90+1503=2403=80\frac{0 + 90 + 150}{3} = \frac{240}{3} = 80, making C the correct answer. The zero on Wednesday is a genuine, informative observation — the store was open and sold nothing. Preserving it is essential; replacing or ignoring it would silently distort the model's understanding of real demand patterns. A is wrong because it averages all five days (Monday through Friday), which violates the three-day window. Expanding the window arbitrarily defeats the purpose of a defined rolling feature and would give 100+120+0+90+1505=92\frac{100+120+0+90+150}{5} = 92, a number the specification never calls for. B is wrong because it skips Wednesday's zero and looks back to Tuesday instead, as if only "positive sales days" count. This is a classic data-cleaning mistake — confusing a zero-sales day with missing data. A true missing value should be imputed; a recorded zero should be kept as-is. D is wrong because it sums rather than averages, and also drops Wednesday. A moving average is a mean, not a cumulative total. The study tip here: always distinguish between missing data and zero values. On feature engineering questions, zeros are valid signals — never silently discard them.

Question 5

An A/B test uses unique customers as the unit of assignment and defines conversion as the percentage of assigned customers who make at least one purchase. The treatment group generated 1,2001{,}200 page-view records from 800800 unique customers, of whom 9696 purchased. The control group generated 900900 page-view records from 750750 unique customers, of whom 7575 purchased. The requested KPI is relative conversion lift.

What derived KPI should the experiment report for the treatment?

  1. −4%-4\% relative lift, based on purchases divided by page-view record counts rather than unique customers
  2. 22 percentage points of absolute lift, incorrectly reported as relative lift from the two customer conversion rates
  3. 20%20\% relative lift, based on customer conversion rates of 12%12\% and 10%10\% (correct answer)
  4. 28%28\% relative lift, based only on comparing the two purchaser counts without adjusting for group sizes
Explanation: When an experiment reports a KPI, every number must be built from the correct unit of analysis using the correct metric definition. Here, the experiment assigns unique customers, so conversion must be computed as purchasers divided by unique customers — not page views. Relative lift then compares the two rates as a ratio: Treatment Rate−Control RateControl Rate\frac{\text{Treatment Rate} - \text{Control Rate}}{\text{Control Rate}}. For the treatment group: 96800=12%\frac{96}{800} = 12\%. For the control group: 75750=10%\frac{75}{750} = 10\%. The relative lift is 12%−10%10%=20%\frac{12\% - 10\%}{10\%} = 20\%, making C the correct answer. Each wrong choice embeds a specific, realistic mistake. A divides purchasers by page-view records instead of unique customers, giving treatment a rate of 961200=8%\frac{96}{1200} = 8\% versus control's 75900≈8.33%\frac{75}{900} \approx 8.33\%, which produces a negative lift — a classic unit-of-analysis error that penalizes the treatment for having more page views per customer. B correctly computes the two customer-based rates (12% and 10%) but reports the absolute difference (2 percentage points) while labeling it as relative lift — a framing error that confuses two distinct KPI definitions. D skips rate normalization entirely, comparing raw purchaser counts: 96−7575≈28%\frac{96 - 75}{75} \approx 28\% — this ignores the fact that the groups have different sizes, so the raw counts aren't comparable. As a study habit: always verify (1) the unit of assignment, (2) the denominator in the conversion rate, and (3) whether "lift" means absolute or relative before doing any arithmetic. These three checkpoints catch the majority of A/B test reporting errors on the exam.

Question 6

To reduce the skewness of annual customer spending while retaining customers with zero spending, an analyst creates x=ln⁡(1+spend)x=\ln(1+spend). The analyst then standardizes this feature using a training-set mean of 22 and standard deviation of 11. A new customer has annual spending of 9999.

What standardized feature value should be assigned to the new customer, rounded to three decimals?

  1. 2.6052.605, obtained by applying the offset log transformation before standardization (correct answer)
  2. 2.5952.595, obtained by logging spending without first adding the offset
  3. 4.6054.605, obtained by applying the offset log transformation without standardization
  4. 97.00097.000, obtained by standardizing the original spending value directly
Explanation: When a question involves feature engineering followed by standardization, always apply the transformations in the correct sequence: first transform the raw value, then standardize using the training-set parameters. Here, the pipeline has two steps. First, apply the offset log: x=ln⁡(1+99)=ln⁡(100)≈4.605x = \ln(1 + 99) = \ln(100) \approx 4.605. Second, standardize using the training mean of 22 and standard deviation of 11: z=4.605−21=2.605z = \frac{4.605 - 2}{1} = 2.605. Choice A is correct — it faithfully follows both steps in order. Each wrong answer skips or misapplies one of those steps. Choice B logs the spending without the offset, computing ln⁡(99)≈4.595\ln(99) \approx 4.595, then standardizes to get 4.595−21=2.595\frac{4.595 - 2}{1} = 2.595. This is close but wrong — the "+1" offset exists precisely to handle zero-spend customers, and omitting it breaks consistency with how the feature was defined during training. Choice C correctly computes ln⁡(1+99)=4.605\ln(1 + 99) = 4.605 but then forgets to standardize entirely, returning the raw transformed value instead of the scaled one. Choice D skips the log transformation altogether and standardizes the original spending: 99−21=97\frac{99 - 2}{1} = 97, which ignores the entire purpose of the log transformation and produces a wildly inflated value. A useful habit: treat preprocessing as a fixed pipeline. Whatever transformations were fitted on training data — log, scale, encode — must be applied in the same order to every new observation. Changing the sequence or skipping a step will corrupt your features and your model's predictions.

Question 7

An online retailer defines net collected revenue as merchandise revenue after discounts, plus shipping charges, minus refunded merchandise revenue. Sales tax is excluded because it is remitted to the government. An order has a merchandise subtotal of 240240, a 15%15\% coupon, a 1212 shipping charge, and 8%8\% sales tax applied only to discounted merchandise. Later, merchandise worth 5050 after discount is refunded along with its associated tax.

What value should the retailer assign to the order's derived net collected revenue variable?

  1. 166.00166.00, including shipping and subtracting refunded merchandise while excluding all sales tax (correct answer)
  2. 154.00154.00, subtracting refunded merchandise while excluding both shipping and all sales tax
  3. 178.32178.32, measuring cash retained after refunding both the merchandise and its associated tax
  4. 182.32182.32, retaining collected sales tax but subtracting only the refunded merchandise amount
Explanation: Whenever you see a question about a derived business metric, your first move should be to decode the exact formula before touching any numbers. Here, net collected revenue = (merchandise revenue after discounts) + (shipping) − (refunded merchandise revenue), with sales tax explicitly excluded because it passes through to the government. Let's build the calculation step by step. The merchandise subtotal is $240\$240, reduced by a 15%15\% coupon: 240×0.85=$204240 \times 0.85 = \$204. Add the $12\$12 shipping charge: 204+12=$216204 + 12 = \$216. Then subtract the $50\$50 refunded merchandise (already stated as after-discount): 216−50=$166216 - 50 = \$166. Sales tax is never included in this metric, so the 8%8\% tax collected and the tax refunded are both irrelevant to the calculation. The correct answer is A. B is wrong because it omits the $12\$12 shipping charge, which the definition explicitly includes. That single omission drops the result to $154\$154. C calculates cash actually retained in the bank — it adds tax collected (204×0.08=$16.32204 \times 0.08 = \$16.32) and subtracts tax refunded (50×0.08=$450 \times 0.08 = \$4), arriving at $178.32\$178.32. This confuses cash flow with the defined metric, which excludes tax entirely. D keeps the tax collected but removes only the refunded merchandise, not the refunded tax, yielding $182.32\$182.32. This inconsistently applies tax treatment and again ignores the pass-through exclusion rule. The key study tip: when a metric has a precise definition, apply it mechanically. Don't substitute your intuition about what "makes sense" financially — the definition is the answer.

Question 8

A linear churn model includes an intercept and uses customer tier as a categorical predictor. The observed tiers are Gold, Silver, Bronze, and Basic. The analyst wants full-rank indicator features and chooses Gold as the reference category.

Which feature construction correctly represents customer tier?

  1. Create Silver, Bronze, and Basic indicators; assign a Gold customer three ones
  2. Create Gold, Silver, Bronze, and Basic indicators while retaining the model intercept
  3. Encode Gold through Basic as ordered integers from 00 through 33
  4. Create Silver, Bronze, and Basic indicators; assign a Gold customer three zeros (correct answer)
Explanation: When working with categorical predictors in regression, you need to watch for two classic pitfalls: the dummy variable trap and inappropriate encoding. The goal of dummy coding is to represent group membership without creating perfect multicollinearity or distorting the variable's nature. With four tiers and Gold as the reference category, the correct approach creates exactly three binary indicators — one each for Silver, Bronze, and Basic. A Gold customer receives a zero on all three indicators, which is how the model implicitly handles the reference group. The intercept then captures the baseline (Gold) outcome, and each indicator's coefficient measures the difference from Gold. This is precisely what D describes: three indicators, with Gold customers coded as all zeros. A is tempting but fatally wrong — assigning Gold customers three ones would incorrectly imply Gold belongs to Silver, Bronze, and Basic simultaneously. That makes no logical or mathematical sense and corrupts the encoding entirely. B falls into the dummy variable trap. Creating indicators for all four categories while keeping the intercept produces perfect multicollinearity (the four columns sum to a column of ones, identical to the intercept), making the model matrix rank-deficient and the coefficients unidentifiable. C treats tier as ordinal by assigning integers 0,1,2,30, 1, 2, 3. This imposes an assumption that the tiers are equally spaced in their effect on churn — a strong and likely unjustified constraint. Dummy coding makes no such assumption. Study tip: For any categorical variable with kk categories and an intercept, always create exactly k−1k - 1 indicators. The omitted category becomes the reference, coded as all zeros.

Question 9

A distributor creates an SLA feature called business_days_to_delivery. The feature counts business-date boundaries crossed after the order date and through the delivery date; Saturdays and Sundays are excluded. An order placed on Friday, March 7, 2025, is delivered on Tuesday, March 11, 2025. A second feature, late_flag, equals 11 when business_days_to_delivery is greater than 11.

Which pair of derived values should be assigned to this order?

  1. business_days_to_delivery equals 22, and late_flag equals 11 (correct answer)
  2. business_days_to_delivery equals 11, and late_flag equals 00
  3. business_days_to_delivery equals 44, and late_flag equals 11
  4. business_days_to_delivery equals 33, and late_flag equals 11
Explanation: When a feature counts "business-date boundaries crossed," you need to carefully enumerate only the weekday transitions that occur after the order date and through the delivery date — not the total calendar days, and not counting the order date itself. For an order placed Friday, March 7, walk forward through the calendar: the next boundary is Monday, March 10 (skipping Saturday and Sunday entirely), then Tuesday, March 11. That gives exactly 22 business-day boundaries crossed. Since 2>12 > 1, the late_flag equals 11. This confirms answer A is correct: business_days_to_delivery =2= 2 and late_flag =1= 1. Answer B claims business_days_to_delivery =1= 1 and late_flag =0= 0. This would only be true if the order arrived on Monday, March 10 — one boundary crossed. Stopping the count one day early is the trap here. Answer C claims 44 business days, which would mean the order arrived on Friday, March 14. This error likely comes from counting all four calendar days between March 7 and March 11 without excluding the weekend, or miscounting boundaries entirely. Answer D claims 33 business days, suggesting delivery on Wednesday, March 12. This is off by one — possibly from incorrectly counting March 7 (the order date itself) as the first boundary, which the definition explicitly excludes. Study tip: On boundary-counting questions, always build a quick timeline and mark each crossing explicitly. The phrase "after the order date and through the delivery date" tells you the start is exclusive and the end is inclusive — that precision is what separates the right answer from the distractors.

Question 10

A lender uses a log-income feature and wants the model to retain information about whether income was originally missing. The preprocessing rule replaces missing income with the training-set median of 60,00060{,}000, computes the natural log of the completed income field, and creates income_missing equal to 11 only when the original value was missing.

Which derived feature values should be assigned to an applicant whose original income is missing?

  1. log_income equals ln⁡(1)\ln(1), and income_missing equals 11
  2. log_income equals ln⁡(60,000)\ln(60{,}000), and income_missing equals 00
  3. log_income remains missing, and income_missing equals 11
  4. log_income equals ln⁡(60,000)\ln(60{,}000), and income_missing equals 11 (correct answer)
Explanation: When a model uses imputation alongside a missing-value indicator, you're dealing with two separate but coordinated operations: filling the gap so the numeric feature is always usable, and flagging the gap so the model can learn from the fact that data was absent. Keep both goals in mind simultaneously. Here, the preprocessing pipeline does exactly that in sequence. The original income is missing, so the pipeline substitutes the training-set median of 60,00060{,}000. It then applies the natural log transformation to that filled value, yielding ln⁡(60,000)≈11.00\ln(60{,}000) \approx 11.00. Separately, because the original value was missing, the indicator column income_missing is set to 11. This is answer D — the only choice that correctly applies both steps. A is wrong because it uses ln⁡(1)=0\ln(1) = 0 as the imputed value, which is not the median. Nothing in the preprocessing rule substitutes 11 for missing income. B correctly computes ln⁡(60,000)\ln(60{,}000) but sets income_missing to 00, which defeats the entire purpose of the indicator. If the flag were 00, the model couldn't distinguish a true $60,000\$60{,}000 earner from someone whose income is unknown. C leaves log_income missing, violating the imputation step. A missing numeric feature would break most model training routines and renders the indicator strategy pointless. Study tip: On questions involving missing-value handling, always ask two questions: What fills the gap? and What records that the gap existed? These are independent operations — imputation handles the first, and the binary indicator handles the second. Confusing them or omitting one is the most common trap.