Preparation, Cleaning, and Sampling

Preparation, Cleaning, and Sampling

Quick Answer: After sources are selected and quality is assessed, CBDA practitioners prepare and clean data so it matches the research question’s grain, population, and definitions—then support sound sampling when full-population analysis is unnecessary or impractical. Document every material transformation. Prefer representative samples, watch selection bias, and choose missing-value treatments that minimize distortion of business conclusions.

Sourcing raw data is only half of Domain 2 work. Preparation is the deliberate set of steps that convert multi-source, messy, multi-definition inputs into an analysis-ready dataset. On the CBDA exam, preparation items test business judgment: what to clean, what to leave transparent, how to sample without bias, and how to keep the chain of custody clear for reproducibility and stakeholder trust.

What “Analysis-Ready” Means in CBDA Terms

Analysis-ready does not mean “every column is perfect.” It means the dataset is fit for the planned analysis and decision:

• Population matches the research question (for example, active B2B accounts in North America in 2025, not every lead ever).
• Grain is explicit (customer-month vs order-line vs claim-event).
• Definitions for KPIs and labels are applied consistently (what counts as churn, conversion, defect, or “high risk”).
• Keys join reliably enough for the intended relationships.
• Known defects are either fixed, isolated, or documented as limitations.
• Transformations can be replayed by another analyst or auditor.

If preparation silently changes who is in the population or how the outcome is defined, later “insights” may be artifacts of cleaning rather than business reality.

Pre-Processing and Cleaning Activities

Typical preparation activities a CBDA practitioner plans, reviews, or performs with technical partners include:

1. Standardization — Dates, currencies, units, case, whitespace, code synonyms (US/USA/United States).
2. Parsing and structuring — Splitting free-text into usable fields, extracting product attributes, normalizing addresses.
3. Type and range correction — Converting strings that should be numbers/dates; handling sentinels like 9999 or N/A.
4. Deduplication at the correct grain — Removing true duplicates without collapsing legitimate multi-event histories.
5. Grain alignment — Aggregating or expanding rows so every analysis table answers questions at one intended level.
6. Enrichment joins — Attaching reference data (product hierarchy, region maps) with orphan handling rules.
7. Derived fields — Tenure, recency, margin, flags—created from documented business rules, not ad hoc spreadsheet formulas that only one person understands.
8. Sensitive data handling — Minimization, masking, and access controls consistent with policy (ties to ethics and governance domains).

Cleaning is iterative with profiling: clean → re-profile → confirm the scorecard moves in the expected direction → freeze a version for analysis.

Missing Values: Strategies That Survive Exam Scrutiny

Missing data is almost inevitable. The CBDA-relevant skill is choosing a strategy that matches why data is missing and how the analysis will be used.

Common strategies

Exam traps

• “Always delete incomplete rows.” If incomplete rows are systematically the highest-risk customers, deletion removes the population you care about most.
• “Always impute the mean.” Mean imputation shrinks variance and can distort segments; it is not a universal fix.
• “Missing data means the source is unusable.” Sometimes a well-documented subset still answers a narrowed research question.

Always ask: Is data missing completely at random, related to observables, or related to the missing value itself? Even a conceptual grasp of this distinction is enough for scenario judgment: non-random missingness requires caution, bias discussion, and often process remediation—not only a statistical patch.

Sampling Basics for Business Data Analytics

Full-population analysis is ideal when feasible, but organizations sample for cost, speed, privacy, or experimental design. CBDA practitioners help ensure sampling supports the business question, not only computational convenience.

Sample size (conceptual level)

You are not expected to derive complex power formulas from memory for every technique, but you should understand:

• Larger samples generally reduce sampling error for estimates of means, proportions, and many model metrics—up to the point where bias and measurement error dominate.
• Rare events (fraud, severe adverse outcomes) need larger samples or stratified designs to observe enough positive cases.
• Segment-level decisions require adequate size within each segment, not only overall.
• Tiny samples can produce unstable insights that look “precise” in a slide deck and fail in production.

When partnering with data scientists, the business analyst contributes effect sizes that would matter operationally, segment definitions, decision thresholds, and constraints (time, cost, ethics). Those inputs drive whether a sample is “big enough” in a business sense.

Representative samples

A representative sample mirrors the population of interest on characteristics that matter for the research question (and preferably on the outcome distribution). Representation is about the target population defined by the research question, not “the entire company database.”

Techniques (conceptual awareness):

• Simple random sampling — each unit equal chance; clean baseline when a full frame exists.
• Stratified sampling — sample within key groups (region, product line, risk tier) to ensure coverage.
• Systematic sampling — every k-th record from an ordered list; watch hidden periodicity.
• Cluster sampling — sample groups (stores, clinics); efficient but design effects matter.
• Time-based samples — recent windows vs full history; seasonality can destroy representativeness.

Bias in sampling

Selection bias occurs when some members of the target population are systematically more likely to be included. Common business examples:

• Surveying only customers who open email campaigns (engaged subset).
• Training a model only on accounts that completed an application (ignores drop-offs).
• Using call-center tickets as “all quality issues” (silent failures never call).
• Convenience samples from one region rolled out as national truth.
• Survivorship bias: analyzing only active customers when the question is about attrition.

CBDA scenarios often ask what is wrong with a proposed sample or what the practitioner should do next. Strong answers: redefine the population frame, stratify, collect additional data for underrepresented groups, or explicitly limit claims to the sampled subpopulation.

Feature Awareness (Conceptual Encoding)

Even when a data scientist engineers features, the CBDA practitioner must stay accountable for business meaning:

• Feature — an input attribute used in analysis or modeling (raw or derived).
• Target / label — the outcome the business cares about; definition errors here dwarf most encoding choices.
• Encoding (conceptual) — converting categories or text into analysis-ready forms (binary flags, ordinal maps, one-hot style indicators). The exam cares that you know why encoding is needed and that arbitrary numeric codes can invent false order (for example, treating unordered region IDs as numeric magnitudes).
• Leakage awareness — features that accidentally include future information or direct restatements of the target invalidate results (for example, using “cancellation reason filled after churn” to “predict” churn).
• Scale and units — mixing dollars, percentages, and counts without care misleads distance-based methods and human readers alike.

Your job in scenarios is often to challenge a feature that is convenient but misaligned (“months since last login” for enterprise accounts that use SSO differently) or to insist on documenting how categorical fields were mapped.

Documenting Transformations for Reproducibility

Reproducibility is a professional and exam-relevant requirement. If another qualified person cannot recreate the analysis-ready table from raw extracts using your documentation, the work is not decision-grade.

Document at least:

1. Source systems, extract times, and filters applied at pull.
2. Join keys and join types (inner joins that drop orphans change populations).
3. Cleaning rules with examples (how duplicates were resolved; what happened to invalid codes).
4. Missing-value treatments and rationale.
5. Derived field formulas and business owners who approved definitions.
6. Sample design if not full population (frame, method, size, seed if random).
7. Excluded records counts and reasons.
8. Version identifiers for the dataset used in final results.

Lightweight forms work: a data preparation log, a notebook with narrative cells, a transformation catalog, or a pipeline config reviewed in a peer session. The medium matters less than completeness and clarity.

Supporting Data Scientists Without Abdicating Business Ownership

CBDA is not a pure data-science credential. In many organizations the practitioner:

• Translates the research question into population, grain, and label definitions.
• Negotiates sample frames and bias risks with stakeholders.
• Reviews preparation outputs against quality scorecards.
• Challenges leakage, proxy targets, and over-cleaning that erase real operational noise the business needs to see.
• Ensures preparation choices remain explainable when results influence decisions.

“The modeler will clean it” is not an acceptable exam posture when the stem shows preparation choices that change business meaning.

End-to-End Mini Scenario

A retailer wants to know whether a new loyalty tier increases repeat purchase rate within 90 days. Preparation work includes: defining eligible first-time buyers; excluding employees and wholesale accounts; standardizing channel codes; handling missing tier assignment dates (backfill from promotion system or exclude with bias note); sampling high-volume online orders while stratifying by region so small stores are not invisible; documenting that inner-joining to the email engagement table would drop non-email customers and bias digital-heavy segments. That documentation protects the interpretation phase when executives ask why results differ from a finance dashboard built on a different population.

Study Checklist for This Section

• List major cleaning/preparation activities and why grain alignment matters.
• Compare missing-value strategies and name at least two bias risks of dropping or imputing casually.
• Define representative sample and give three selection-bias examples from business settings.
• Explain the practitioner’s role in sampling and feature definition alongside data scientists.
• Specify eight elements of transformation documentation for reproducibility.