Analytics Categories and Technique Selection

Analytics Categories and Technique Selection

Quick Answer: Once research questions are clear, CBDA practitioners choose an analytics category—descriptive, diagnostic, predictive, or prescriptive—that matches the question and decision need, then pick tools and techniques inside that category. Technique-first thinking ("we should do machine learning") is a common exam trap when the question only needs a baseline or driver analysis.

Domain 1 does not end when questions are written. Competency areas around selecting analytics approaches and techniques (including 1.2.4-style expectations to pick tools and techniques based on analytics category) connect research design to the work that will follow in sourcing and analysis. Category fit is a professional judgment: the same business theme ("churn," "conversion," "cycle time") can require different categories depending on what is unknown and what decision is imminent.

The Four Analytics Categories

Memorize the question pattern each category answers. Exam stems often embed the pattern in stakeholder language; you map language → category → techniques.

These categories form a maturity ladder of insight, not a status symbol. Descriptive work is not "junior"; it is often the highest-value next step when definitions are contested or baselines are unknown. Prescriptive work is not automatically better; it fails without trusted descriptive metrics, causal or quasi-causal understanding, and operational ability to execute recommendations.

Descriptive analytics

Descriptive analytics profiles history and the present: totals, rates, medians, percentiles, trend lines, funnels, cohort tables, and simple segment breakouts. It answers research questions about magnitude, composition, and change over time.

Examples of descriptive techniques: aggregations and KPI scorecards, exploratory data analysis (EDA) summaries, time-series charts of actuals, funnel conversion tables, Pareto charts of loss concentration, and distribution analysis (histograms, box plots).

CBDA scenario flavor: Before anyone models readmission risk, quality leaders need the measured 30-day unplanned heart-failure readmission rate by facility and quarter with a single definition.

Diagnostic analytics

Diagnostic analytics investigates why descriptive patterns exist. It compares groups, tests associations, decomposes variance, and explores candidate drivers—while remaining careful about correlation vs causation (deepened in Domain 3).

Examples of diagnostic techniques: comparative cohort analysis, correlation analysis, contingency tables, drill-down by process stage, contribution/driver analysis, controlled comparisons where feasible, and structured root-cause methods paired with data evidence.

CBDA scenario flavor: Conversion fell 2.1 points on mobile—diagnostic work asks which stages, devices, and segments account for the drop and which factors move together with abandonment.

Predictive analytics

Predictive analytics estimates future or unknown outcomes using patterns in historical data: will this customer churn, what will demand be next week, how likely is a claim to exceed a threshold?

Examples of predictive techniques: regression models, logistic regression, classification trees and ensembles, time-series forecasting, survival/propensity models, and scored risk tiers. Technique choice depends on outcome type (continuous vs binary vs time-to-event), data volume, interpretability needs, and validation plan.

CBDA scenario flavor: Care management can contact only 15% of discharged patients—predictive scores help rank who is most likely to be readmitted if the score is validated and tied to an intervention pathway.

Prescriptive analytics

Prescriptive analytics recommends actions under objectives and constraints: which offer to send, how to allocate nurses, how to set inventory buffers, which claims to route to specialists first.

Examples of prescriptive techniques: optimization (linear/integer programming), simulation of policies, decision rules/threshold policies built on predictive scores, reinforcement learning in advanced settings, and constrained next-best-action frameworks. Many organizations start with simple rule-based prescriptions on top of solid descriptive/diagnostic insight before full optimization engines.

CBDA scenario flavor: Given predicted high-risk patients and finite nurse capacity, prescribe a weekly outreach list that maximizes expected prevented readmissions under staffing limits—not merely a ranked risk list with no action design.

Match Category to Research Question and Decision Need

Selection starts with the research question, not with the coolest method on a resume.

Decision need filters

Ask four filters before locking category:

1. Time orientation — Past performance, explanation, future estimate, or recommended action?
2. Action readiness — Can the organization act on a score or only on a diagnosis right now?
3. Evidence maturity — Do we trust definitions and baselines enough to model?
4. Risk of error — What is the cost of a wrong prediction vs a delayed baseline?

If action readiness is low (no process to use scores), predictive work may create shelfware. If evidence maturity is low, descriptive and diagnostic work is the correct "advanced" choice.

Picking Tools and Techniques by Category (Competency 1.2.4)

Tools are platforms and products (BI tools, notebooks, warehouses, AutoML, optimization solvers). Techniques are analytical methods (funnel analysis, logistic regression, simulation). CBDA expects you to derive technique family from category, then choose tools that the organization can support—not the reverse.

Practical selection checklist

1. Restate the approved research question and mark its category cue words (what/why/will/should).
2. Confirm decision owner and action path for that category's output.
3. Assess data readiness for the technique family (labeled outcomes for supervised prediction; clean decision variables for optimization).
4. Choose the simplest technique that can answer the question at required confidence—not the most complex.
5. Plan validation and interpretation before build (especially for predictive/prescriptive).
6. Document assumptions (stability of process, missingness, population drift) that could invalidate the technique.

Example — sales conversion time:

• RQ: median and percentile cycle times by segment → descriptive (aggregations, distribution charts).
• RQ: which stage transitions drive elapsed time → diagnostic (stage contribution, cohort comparison).
• RQ: which open deals will exceed 90 days → predictive (classification or survival model with validation).
• RQ: how to assign specialists under capacity → prescriptive (assignment rules or optimization on predicted lift).

Jumping to a black-box predictor for the first RQ would be a category mismatch.

When to Escalate from Descriptive to Diagnostic or Predictive

Escalation is triggered by decision need and remaining uncertainty, not by project boredom.

Healthy escalation path (subscription churn)

1. Descriptive: Quantify voluntary churn rate, revenue lost, and concentration by tenure/plan.
2. Diagnostic: Identify engagement and support factors associated with cancelation in top loss cohorts.
3. Predictive: Score current customers for near-term cancel risk after definitions and associations are trusted.
4. Prescriptive: Assign limited retention offers to customers where expected incremental save exceeds cost, subject to inventory of offers and policy rules.

Each step should answer an approved research question. Skipping steps because a vendor demo showed "AI retention" is a classic Domain 1 failure mode.

Organizational readiness still applies

Earlier Domain 1 sections covered analytics culture and capability. Category choice must respect readiness: a team without reliable monthly closes should not promise real-time prescriptive pricing. On exam scenarios, the best answer often downshifts category to match data and process maturity while still advancing the decision.

Trap: Predictive Modeling Without a Descriptive Baseline

Trap: Stakeholders demand "predictive analytics" or "ML" before anyone can state the current metric definition, baseline rate, population, or decision threshold.

Why it fails:

• No success criterion — You cannot know if a model helps if "churn" is defined three ways.
• Silent population errors — Models train on the wrong grain (account vs user) and look accurate in sample.
• Unusable scores — Operations has no playbook for high-risk cases; scores create anxiety without action.
• False confidence — Fancy AUC charts hide that last quarter's actuals were never baselined for the decision population.

Counter-practice (exam and job):

1. Lock metric definitions and descriptive baselines for the decision population.
2. Confirm the decision and capacity to act on scores.
3. Complete enough diagnostic understanding that model features are business-meaningful.
4. Only then specify predictive techniques, validation design, and monitoring for drift.

Integrating Category Choice into the Domain 1 Package

A complete Domain 1 handoff into Domain 2 (source data) typically includes:

1. Framed business situation and business need.
2. Current/future state and success metrics.
3. Scope, assumptions, constraints, dependencies.
4. Approved research questions (prioritized).
5. Analytics category per question with rationale.
6. Candidate techniques (not final code) and known data needs.
7. Explicit note of what is out of category for this phase (e.g., "no prescriptive optimization until P1–P2 complete").

This package prevents the two failure modes CBDA tests relentlessly: solution-jumping and technique theater.

Category and technique selection is how research questions become an executable analytics approach. Match descriptive, diagnostic, predictive, and prescriptive work to the question pattern and decision need; choose techniques inside the category with organizational readiness in mind; escalate only when foundations exist; and never let predictive modeling substitute for a missing baseline.