Creating Derived Variables - Business Analytics

1. Which derived feature is valid for model training without introducing future-information leakage?
   Answer: The days from the snapshot to the contract expiration date scheduled at the snapshot 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: $\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.
2. Which derived feature values should be assigned to an applicant whose original income is missing?
   Answer: log_income equals $\ln(60{,}000)$, and income_missing equals $1$ 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{,}000$. It then applies the natural log transformation to that filled value, yielding $\ln(60{,}000) \approx 11.00$. Separately, because the original value was missing, the indicator column income_missing is set to $1$. This is answer D — the only choice that correctly applies both steps. A is wrong because it uses $\ln(1) = 0$ as the imputed value, which is not the median. Nothing in the preprocessing rule substitutes $1$ for missing income. B correctly computes $\ln(60{,}000)$ but sets income_missing to $0$, which defeats the entire purpose of the indicator. If the flag were $0$, the model couldn't distinguish a true $\$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.
3. What value should be assigned to the customer's derived average_order_value feature?
   Answer: $77.00$, after calculating net revenue by order and averaging the two orders 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$ minus the $\$10$ flat discount gives $\$50$, and one unit at $\$50$ with no discount gives $\$50$. Order 1 net total: $\$100$. Order 2 has three units at $\$20$ with a $10\%$ line discount: $3 \times 20 \times 0.90 = \$54$. Total net revenue across both orders: $\$100 + \$54 = \$154$. Dividing by 2 distinct orders gives $\$77.00$, confirming A is correct. Choice B is wrong because it ignores both discounts entirely, inflating Order 1 to $\$110$ and Order 2 to $\$60$, yielding $\$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$. Choice D correctly computes total net revenue ($\$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.
4. Which pair of derived values should be assigned to this order?
   Answer: business_days_to_delivery equals $2$, and late_flag equals $1$ 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 $2$ business-day boundaries crossed. Since $2 > 1$, the late_flag equals $1$. This confirms answer A is correct: business_days_to_delivery $= 2$ and late_flag $= 1$. Answer B claims business_days_to_delivery $= 1$ and late_flag $= 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 $4$ 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 $3$ 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.
5. What derived KPI should the experiment report for the treatment?
   Answer: $20\%$ relative lift, based on customer conversion rates of $12\%$ and $10\%$ 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: $\frac{\text{Treatment Rate} - \text{Control Rate}}{\text{Control Rate}}$. For the treatment group: $\frac{96}{800} = 12\%$. For the control group: $\frac{75}{750} = 10\%$. The relative lift is $\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 $\frac{96}{1200} = 8\%$ versus control's $\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: $\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.
6. What value should the retailer assign to the order's derived net collected revenue variable?
   Answer: $166.00$, including shipping and subtracting refunded merchandise while excluding all sales tax 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$, reduced by a $15\%$ coupon: $240 \times 0.85 = \$204$. Add the $\$12$ shipping charge: $204 + 12 = \$216$. Then subtract the $\$50$ refunded merchandise (already stated as after-discount): $216 - 50 = \$166$. Sales tax is never included in this metric, so the $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$ shipping charge, which the definition explicitly includes. That single omission drops the result to $\$154$. C calculates cash actually retained in the bank — it adds tax collected ($204 \times 0.08 = \$16.32$) and subtracts tax refunded ($50 \times 0.08 = \$4$), arriving at $\$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$. 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.
7. What standardized feature value should be assigned to the new customer, rounded to three decimals?
   Answer: $2.605$, obtained by applying the offset log transformation before standardization 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) \approx 4.605$. Second, standardize using the training mean of $2$ and standard deviation of $1$: $z = \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) \approx 4.595$, then standardizes to get $\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$ 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: $\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.
8. Which feature construction correctly represents customer tier?
   Answer: Create Silver, Bronze, and Basic indicators; assign a Gold customer three zeros 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, 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 $k$ categories and an intercept, always create exactly $k - 1$ indicators. The omitted category becomes the reference, coded as all zeros.
9. What moving-average feature should be generated at the start of Saturday?
   Answer: $80$, averaging Wednesday, Thursday, and Friday while retaining the genuine zero-sales day 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 $0$, $90$, and $150$. The correct feature is simply $\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 $\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.
10. Which derived feature and coefficient identify the campaign's incremental effect beyond the general post-period change?
    Answer: The treated-by-post interaction feature, giving an incremental effect of $-3$ 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$, 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 ($5$) 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 ($8$) 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) = 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.

Start this quiz