CDSP (DSP-110) common mistakes
CDSP (DSP-110) · Understand the traps and how to avoid them.
When a scenario describes a stakeholder asking for a churn dashboard, the candidate immediately starts choosing models and metrics instead of first restating the business decision the dashboard must support, the decision owner, and what action would follow from a high or low churn signal.
Technical training rewards jumping to tools, and the exam's scenario wording ('the team wants to predict churn') looks like a modeling prompt, so candidates pattern-match to model selection and skip the framing step that the question is actually testing.
What to do instead
Before evaluating any answer option, write one sentence naming the decision, the decision-maker, and the cost of a wrong call. Eliminate any option that starts with a technique, tool, or metric before the business objective and success criterion are pinned down; the correct option in framing questions almost always ties the analysis to a decision and a measurable outcome.
The candidate treats the stated business objective as the analytical objective, for example accepting 'increase revenue' as a target variable and proceeding to build a model of revenue, rather than translating it into a measurable, time-bounded, operationally defined outcome such as 90-day incremental conversion lift for a specific segment.
Objectives in real briefs are vague and aspirational, and candidates worry that adding specificity means inventing requirements, so they keep the vague phrasing and lose the ability to define success criteria or evaluate model fit.
What to do instead
Practice converting each vague objective into a testable form: outcome metric, population, time window, baseline, and minimum detectable effect. On the exam, prefer options that operationalize the objective and state a baseline or comparison; reject options that leave the target undefined or that measure a proxy with no stated link to the business outcome.
When presented with a dataset description, the candidate accepts the row count and column list at face value and moves straight to modeling, without checking grain (what one row represents), duplicate keys, date coverage, or whether the population in the data matches the population in the business question.
Exam vignettes are written compactly and the data section reads like background, so candidates treat it as context rather than as evidence to be audited; in practice, grain and coverage problems are the most common real-world cause of wrong conclusions.
What to do instead
For every data description, explicitly state the grain in one sentence ('one row per order line, not per order') and check whether counts, date ranges, and segment coverage are consistent with the business question. Options that silently change grain, join on non-unique keys, or extrapolate beyond the observed period are usually the distractors.
The candidate sees missing values and either drops every row with a null or imputes with the column mean by default, without asking why the values are missing or whether missingness itself carries information correlated with the outcome.
Introductory courses teach listwise deletion and mean imputation as the standard defaults, and the exam options that mention 'remove incomplete records' sound clean and defensible, so candidates pick them without considering bias or leakage.
What to do instead
Classify missingness first: is it structural (field not applicable), random, or related to the outcome? Then choose handling that preserves the signal, such as a missing-indicator plus a sensible imputation, and fit imputation parameters on training data only. Eliminate options that drop data wholesale or impute using statistics computed across the full dataset.
The candidate evaluates a classifier on a dataset with a 2% positive rate and reports accuracy of 97% as evidence the model works, or selects the model with the highest accuracy, without comparing against the base rate or examining precision, recall, or the cost of each error type.
Accuracy is the first metric taught and the easiest to compute, and the exam deliberately includes an accuracy figure that looks impressive; candidates who do not compute the no-skill baseline get pulled toward it.
What to do instead
Always compute the majority-class baseline before reading any accuracy number, then choose the metric from the business cost of false positives versus false negatives. On the exam, an option citing high accuracy on imbalanced data without a baseline or a cost discussion is almost always wrong; prefer options that name the base rate and justify the chosen metric.
The candidate judges a model by its in-sample fit or by a single random train/test split, and accepts the resulting performance as the model's expected performance, ignoring leakage from target-derived features, time ordering, or preprocessing fit before the split.
The vignette often reports a strong holdout score, and candidates do not check whether the split respected the data's structure (for example, future information in a time-series split) or whether features were engineered using the full dataset.
What to do instead
Check the split design against the data structure: time-ordered data needs a temporal split, grouped data needs group-aware splitting, and all preprocessing must be fit inside the training fold. On the exam, options that report a suspiciously high score, or that tune and evaluate on the same data, are the intended distractors; prefer cross-validation that mirrors deployment conditions.
The candidate reads a regression coefficient or feature-importance ranking as a causal effect, concluding that increasing the top feature will increase the outcome by the coefficient's amount, without considering confounding, selection, or whether the model was built for prediction rather than inference.
Coefficients and importance scores look like effect sizes, and exam options phrased as 'a one-unit increase in X raises Y by b' mirror the model output so closely that they feel like restatements of fact rather than causal claims.
What to do instead
Separate the question type before interpreting: prediction models support ranking and forecasting, not intervention claims. Reject options that convert an association into an intervention effect unless the scenario describes randomization, a natural experiment, or a defensible identification strategy; when the question is causal, look for the option that names the confounder or the design that controls it.
The candidate treats a statistically significant result with a tiny effect size, or a confidence interval that barely excludes zero, as decision-relevant, and recommends acting on it without asking whether the effect is large enough to matter operationally or whether the study had power to detect a meaningful difference.
Significance is taught as the threshold for a real finding, and exam options that cite a p-value below 0.05 sound authoritative; candidates conflate statistical and practical significance and skip the effect-size and power reasoning.
What to do instead
For every inferential result, state the effect size in business units, the interval around it, and the minimum effect that would justify action. Prefer options that discuss practical significance, interval width, and power; treat options that recommend a rollout solely because p < 0.05, or that interpret a wide interval as a precise estimate, as distractors.
When asked to present findings to executives, the candidate recommends walking through methodology, model choice, and validation metrics in detail, or conversely strips the recommendation of any uncertainty and presents a single number as certain.
Candidates default to demonstrating technical rigor because that is what they were trained to value, and they overcorrect toward simplicity when they sense the audience is non-technical, losing the caveats that make the recommendation trustworthy.
What to do instead
Structure the answer as decision, evidence, uncertainty, and next step, with technical detail moved to an appendix. On the exam, prefer options that lead with the recommendation and its business impact, state key assumptions and confidence honestly, and offer a concrete next action; reject options that lead with model internals or that present point estimates without caveats.
The candidate recommends deploying a model or shipping a dashboard without specifying how its performance will be monitored after launch, what drift or degradation would trigger a review, or who owns the retraining decision, and treats the analysis as finished once the model is built.
Exam questions often end at model selection, and candidates read the last step as 'pick the best model'; lifecycle and monitoring content is underweighted in study habits even though it is central to how analytics work is evaluated in organizations.
What to do instead
For any deployment scenario, attach a monitoring plan: the metric tracked in production, the threshold or drift signal that triggers action, the cadence of review, and the owner. Prefer options that include post-deployment monitoring and a feedback loop; treat options that end at 'deploy the model' or that assume performance observed offline will persist unchanged as incomplete.