CBDA Analyze Data is Domain 3 of the IIBA Certification in Business Data Analytics: 16% of 75 questions, so about 12 questions [1]. It covers five tasks in section 2.3 of the Guide to Business Data Analytics: plan the analysis, prepare the data, explore it, perform the analysis and assess the approach [2]. The key idea for the exam: the analyst mainly supports the data scientist with business context rather than running the models.
CBDA Analyze Data at a glance
Analyze Data is the domain where a business question turns into a model, and the analyst's job is to keep that model tied to the business. The facts:
| Item | Value |
|---|---|
| Domain | Analyze Data (Domain 3) |
| Weight | 16% of the exam [1] |
| Exam format | 75 multiple-choice, scenario-based questions in 2 hours, online remote proctored only [1] |
| Guide section | 2.3, tasks 2.3.1 to 2.3.5, plus techniques (2.3.6) and a case study (2.3.7) [2] |
| Analyst's role | "More likely to support the data scientist" than to run the models [2] |
| Expected depth | All nine IIBA competencies for this domain are labelled "General Awareness" [3] |
Last verified: November 2026 (exam facts and competencies on iiba.org).
The last row matters more than it looks. IIBA describes the domain's competencies with words like "Basic Knowledge of preparing data" and "Understands whether the analytics results are helping to answer the business question" [3]. So the exam wants you to know what a logistic regression or a random forest is for, not how to tune one. I think this is the most useful fact for planning your study time.
The five tasks of Analyze Data
The guide lists five tasks, and the last one loops back into the two before it [2].
| Task | Purpose | What comes out |
|---|---|---|
| 2.3.1 Develop Data Analysis Plan | Plan techniques, models, sources, joins and cleaning | A formal or informal data analysis plan |
| 2.3.2 Prepare Data | Link sources into one coherent dataset | A cleaned, joined, transformed dataset |
| 2.3.3 Explore Data | Check the data is what was expected | Assurance about the data and early insights that guide the approach |
| 2.3.4 Perform Data Analysis | Answer the research question with mathematics and models | Model results for the research question |
| 2.3.5 Assess the Analytics and System Approach Taken | Decide whether results answer the business question | A decision to continue or to change data, model or approach |
The "what comes out" column is my summary of the task text. The guide does not name formal outputs for these tasks the way BABOK does.
2.3.1 Develop Data Analysis Plan
The data analysis plan sets which mathematical or statistical techniques and which models will be used, which data sources will be linked or joined, and how data will be preprocessed and cleaned [2]. The plan may be formal or informal.
What the analyst does:
- provides insights into the plan, especially business domain information, or drafts the initial plan for the data scientist to review;
- understands the models well enough to explain to stakeholders why a model fits the research question;
- uses metrics and KPIs to help the data scientist judge whether the results address the business need.
The decision itself is not the analyst's. The guide is clear that the data scientist "possesses deep technical expertise to decide how the data analysis will be conducted" [2]. The task also has a box with nine models and their advantages and disadvantages: ordinary least squares regression, ARIMA, decision trees, random forest, logistic regression, KNN, Naive Bayes, SVM and the perceptron. For example, random forest "works in most cases with high accuracy" but is complex to explain, while decision trees are easy to understand and visualize.
Exam trap: an answer where the analyst picks the algorithm. The analyst informs and explains; the data scientist decides.
2.3.2 Prepare Data
Preparing data means getting access to the planned sources and building the links between them into one coherent dataset [2]. It includes:
- understanding relationships between tables (0 to 1, 1 to 1 or 1 to many);
- joins and linkages, normalizing to reduce redundancy, standardization, scaling and converting;
- data cleansing, which corrects or removes bad data;
- weighting to correct bias, such as sample weights and survey weights.
The analyst's part is business context. The guide gives two cases [2]. A data scientist may fill missing values with the mean or median to keep the distribution intact; this is sound statistically but may conflict with business rules, which the analyst can point out. And a data scientist may drop a portion of data with missing information as statistically insignificant, while from a business standpoint further investigation may be needed, through stakeholder collaboration and a look at the recording process.
Exam trap: "statistically sound" is not the same as "acceptable". When a scenario shows imputation or dropped rows, look for the answer where the analyst checks business rules or the recording process.
2.3.3 Explore Data
Exploring data is an initial exploratory analysis on a subset of the data to make sure it is what was expected from the sources [2]. It is a quality check before the detailed analysis. The guide's sidebar calls exploratory data analysis "a deeper validation of the quality of data".
The data scientist assesses quality with four checkpoints [2]:
| Checkpoint | The question | Guide's example |
|---|---|---|
| Data integrity | Can the data be trusted, is it structurally correct? | |
| Data validity | Does the data represent the underlying construct? | Is win ratio a good measure of monthly sales performance? |
| Data reliability | Will repeated collection give the same results? | Will a respondent answer differently on different weekdays? |
| Data bias | Does the data give an accurate picture? | Are survey participants a representative sample? |
The guide's example is the Boston housing dataset with 13 predictors [2]. Some house prices looked like outliers. The analyst checked the data collection method for missed business rules and found these values were artificially set to a high value of $50,000 to mark prices that could not be disclosed. So the outliers were excluded for a business reason, not only a statistical one.
The guide also says exploration is "more involved than data preparation" [2], and it names data mining and histograms as typical tools. Technique 3.11 Exploratory Data Analysis describes the approach in detail: investigate the data with visuals "before applying more formal approaches".
Exam trap: confusing validity and reliability. Validity is "does it measure the right thing", reliability is "will I get the same answer again".
2.3.4 Perform Data Analysis
Performing data analysis is the deep analysis done once exploration has resolved the data quality issues [2]. The research question in business language is "transformed into a mathematical question", which becomes a model.
Data scientists may use association rule learning, decision tree analysis or K-means clustering to find patterns, regression to predict and forecast, and simulation to play out actions [2]. The analyst's role is again context: parameters and measures of success need business domain knowledge. The guide's example is market segmentation, where marketing guidance decides whether segments follow demography, monetary value, product types or customer lifetime value. The analyst describes success criteria so the data scientist can turn them into mathematical parameters.
Exam trap: treating model accuracy as success by default. In the guide, success criteria come from business decisions.
2.3.5 Assess the Analytics and System Approach Taken
Assessing the approach means the analytics team checks whether the results of exploration or analysis are helping to answer the business question [2]. It is "performed iteratively with Explore Data and Analyze Data". If exploration shows wrong data or gaps, data collection changes. If analysis fails to answer the question, exploration and analysis repeat.
The guide's example is a 10% discount campaign [2]. The team had 50,000 CRM records, used 30,000 to train a logistic regression and the rest to test it. Training performance was high, testing performance low. The data scientist suspected that existing customers and leads behave differently, and that missing variables such as income or education were confounding variables. The guide gives three options:
- obtain more relevant data, with the cost of surveys;
- run randomized simulation or A/B testing, with the cost of a new experiment;
- change to models better suited to confounding, such as propensity score matching or random forest.
For all three, the analyst evaluates cost-benefit, feasibility and business impact, which needs stakeholder discussion and consensus. The guide also expects basic statistics skills, a basic understanding of data science tools, business acumen, adaptability as new data and insights emerge, and trustworthiness, since access to some data carries legal responsibility [2].
Exam trap: an answer that jumps to a new model at once. The guide's analyst first weighs the options with stakeholders.
Techniques used in Analyze Data
The techniques table in 2.3.6 has 14 techniques: eight from BABOK Guide v3 and six specific to analytics [2].
| Technique | Source | Use in Analyze Data |
|---|---|---|
| Business Case | BABOK 10.7 | Align the analytics effort with high-level needs |
| Decision Analysis | BABOK 10.16 | Validate the data scientist's decisions on sampling, transformation, model and evaluation criteria |
| Financial Analysis | BABOK 10.20 | Costs, benefits and business value |
| Key Performance Indicators | BABOK 10.28 | Translate KPIs into the model's objective or cost function |
| Observation | BABOK 10.31 | Uncover data activities that may affect success |
| Reviews | BABOK 10.37 | Review the whole analytics process, not only the outcome |
| Risk Analysis and Management | BABOK 10.38 | Record risks and assumptions of the approach |
| Scope Modelling | BABOK 10.41 | Re-scope when objectives, data, models or criteria change |
| Data Journalism and Storytelling | Guide (3.7 Data Storytelling) | Communicate actions and results |
| Descriptive and Inferential Statistics | Guide (3.9) | Describe data patterns; inferential statistics for predictive and prescriptive models |
| Technical Visualizations | Guide (3.18) | See patterns during EDA and modelling |
| Machine Learning / Deep Learning | Guide table | Analysts understand and communicate model characteristics |
| Optimization | Guide (3.14) | Best outcome under constraints |
| Simulation | Guide (3.1 Business Simulation) | Outcomes when observed data is lacking or uncertainty is high |
Chapter 3 numbers in the table are my cross-reference: the 2.3.6 table only marks these six as N/A for BABOK.
The table has one line I would memorize: technical visualizations are "used to analyze the data, while business visualizations are used to interpret and report results" [2].
Several chapter 3 techniques also describe their role in this domain. Data dictionaries help with joins together with entity relationship diagrams (3.4). Data flow diagrams help find the source of discrepancies, including incorrect data mapping (3.5). Concept models give the business view of the data (3.3). Decision Modelling and Analysis, by contrast, says it has no significant role in Analyze Data (3.8). I wrote about one of the six in more detail: business simulation, technique 3.1.
How it works in practice: the ABC Insurance case
The guide's case study (2.3.7) shows the analyst as a translator between data scientists and the business [2]. ABC Insurance Co. in Japan saw 35% of individuals end their online application early, according to its web analytics; entering the data took about 90 minutes. The team worked with about 80,000 applications and almost 130 predictor variables to classify applicants into risk classes automatically.
Data scientists asked questions such as "Is this a multinomial classification problem?" and which metric to use: accuracy, MCC or Cohen's Kappa. The underwriters did not understand them, and the data scientists did not understand the business. The senior business data analytics expert, Haru Kobayashi, used four steps:
- learn the terminology with the data scientists;
- understand why they ask their questions;
- translate this into terms meaningful to underwriters;
- communicate the business implications so the team shares one understanding of the model.
A small example from the case: he explained Cohen's Kappa as two underwriters classifying the same applications, where accuracy shows how often they agree and Kappa corrects for agreement by pure chance [2].
To see the five tasks in one flow, here is a made-up example from e-commerce, my own field. It is not from the guide.
| Task | What happens |
|---|---|
| 2.3.1 Plan | Research question: which customers are likely to stop buying within 90 days? The analyst drafts a plan: order history and CRM data joined by customer ID, a classification model, success measured by retained revenue rather than accuracy alone. The data scientist chooses the model. |
| 2.3.2 Prepare | One customer has many orders (1 to many). Missing "last delivery date" is filled with the median. The analyst flags that a missing date means "click and collect" by a business rule, so the median is wrong here. |
| 2.3.3 Explore | A histogram of order values shows a spike at 0.01. The analyst finds that the warehouse system writes 0.01 for free replacement orders, so these rows are excluded. |
| 2.3.4 Perform | The model scores customers. The analyst translates "precision" into "of 100 customers we call, how many would really leave". |
| 2.3.5 Assess | Results look fine on test data but marketing cannot act on the top segment. The team re-scopes with Scope Modelling and adds campaign cost to the success criteria. |
The pattern repeats in every row. The data scientist does the mathematics, and the analyst brings the rule that the data does not show.
What practitioners and data say about analysis work
Practitioners repeat the guide's point that business context, not only mathematics, decides whether a model is useful.
Data preparation takes the biggest share. A 2020 survey of nearly 2,400 people found data scientists spend about 45% of their time on data preparation [6]. The popular "80% cleaning" claim is weaker than it looks. In the 2016 report it is often attributed to, 60% and 19% are the shares of respondents who named cleaning or collecting as the task they spend the most time on [4]. One author showed you can make such numbers "add up to 80%" by choosing labels [5].
Models often do not reach use. In a 2023 survey of data scientists, only 32% said their models usually deploy, and the author blamed under-planning and stakeholders without visibility [7].
Business context beats metrics. A senior data scientist writes that "no one cares about the model's accuracy or F1 score" and maps metrics to business goals instead [8]. Another author advises framing model results "in the context of the business problem" and comparing them with the current process [11].
Exploration catches business rules. A data analyst with over 20 years of experience describes placeholder dates such as 9999-12-31 in a warehouse, with variants, because "not all processes get written using the correct exact value" [9]. It is the same lesson as the guide's $50,000 house prices.
Train and test are not production. A consultancy's case study describes an enrollment model that looked strong in testing but degraded in production because of data leakage. The fix was "ensuring all data would be available at the time of prediction" [10], which is a business question about when data appears.
Candidates who passed the CBDA say the same about depth. One passer writes that the exam "does not cover in-depth data science or mathematical models" [12]. A product owner with about eight years of experience, who passed on the first attempt, stresses that the questions are scenario-based [13].
Experts disagree on the analyst's place in analysis
Experts agree the analyst needs some statistics, but not on how much or where exploration ends.
1. EDA is a mindset, not a phase. Authors of a widely used data science book write that "EDA is not a formal process with a strict set of rules" [14]. The guide is closer to a sequence: explore, then analyze, then assess, with iteration.
2. Cleaning is analysis. One essay argues that cleaning "imposes values/judgments/interpretations upon data" [15]. This fits the guide's imputation example: the choice of mean or median is a business decision as much as a statistical one.
3. Exploration and testing are different jobs. A decision scientist argues that patterns found in exploration "should not be taken seriously until they are tested statistically on new data" [16]. This matches the guide's split between 2.3.3 and 2.3.4, and the training and testing sets in 2.3.5.
4. The analyst needs foundations, not models. A BA training provider writes that "BAs are not expected to build machine learning models" but lists statistics up to correlation and regression [17]. IIBA's "Basic Knowledge of interpreting regression output" competency sits on the same line [3].
My take: for the exam, position 4 is the safe default. At work, positions 1 and 2 explain why the analyst should stay in the room during preparation and exploration, not only at the planning stage.
What the exam looks for in Domain 3
The exam looks for one behaviour: the analyst adds business context at each step and leaves the technical decision to the data scientist. The task traps are above; these are patterns from the techniques side:
| Scenario | Best answer usually |
|---|---|
| A survey sample over-represents one customer group | Weighting to correct bias (2.3.2) |
| Stakeholders question the data scientist's sampling or model choice | Decision Analysis: validate those decisions against business and statistical parameters (2.3.6) |
| Numbers differ between two sources after a migration | Data flow diagrams to find where the discrepancy starts (3.5) |
| A KPI must become the model's objective function | Translate the KPI into the mathematical model correctly (2.3.6, KPIs) |
| Objectives or data change mid-way | Re-scope with Scope Modelling and adjust the plan (2.3.6) |
| Choosing a chart for the data scientist | Technical visualization, not a business visualization (2.3.6) |
For the confounding pattern, see correlation vs causation on the CBDA exam.
How to prepare for the Analyze Data domain
Preparation for this domain is mostly about roles and vocabulary, not mathematics.
- Read section 2.3 once fully, then the techniques 3.9, 3.11 and 3.18.
- Learn the nine models in the 2.3.1 box at the level of "what it is for, one strength, one weakness".
- Learn the four checkpoints of 2.3.3 with one example each.
- Retell the 2.3.5 campaign example and the three options from memory.
- Drill scenarios: the CBDA Analyze Data questions set, then a timed mock on the CBDA exam simulator.
Domain 3 builds on the dataset from the previous domain, so it helps to read the CBDA Source Data domain first.
Check yourself: CBDA practice questions
Four short questions, checked against section 2.3 of the guide.
1. During exploration, a data scientist finds a cluster of prices at exactly the maximum value and wants to drop them as outliers. What should the analyst do first?
A. Agree, since outliers distort models B. Check the data collection method for business rules C. Replace them with the median D. Ask for a different model
Answer: B. In the guide's housing example, the analyst found these values were set on purpose to mark undisclosed prices (2.3.3).
2. Who decides how the data analysis will be conducted?
A. The business analysis professional B. The sponsor C. The data scientist D. The data owner
Answer: C. The analyst may draft or inform the plan, but the data scientist has the technical expertise to decide (2.3.1).
3. A model performs well on training data but poorly on test data. Which is NOT one of the options the guide lists?
A. Collect more relevant data B. Run an A/B test C. Use a model suited to confounding variables D. Deploy the model and monitor results
Answer: D. The guide lists more data, randomized simulation or A/B testing, and models such as propensity score matching (2.3.5).
4. A survey respondent may answer differently on Monday and Friday. Which checkpoint is at risk?
A. Integrity B. Validity C. Reliability D. Bias
Answer: C. Reliability asks whether repeated collection gives the same result (2.3.3).
Key takeaways
- Analyze Data is 16% of the CBDA, about 12 of 75 questions.
- Five tasks: plan, prepare, explore, perform, assess; assessment loops back into exploration and analysis.
- The analyst is more likely to support the data scientist with business context than to run the models.
- Many exam traps are "statistically fine, wrong for the business" choices.
- Technical visualizations analyze; business visualizations report.
Related topics
- Identify the Research Questions, Domain 1: where the research question that Domain 3 turns into a model comes from.
- CBDA statistics questions: practice for the statistics behind 2.3.
FAQ
What is the Analyze Data domain on the CBDA exam?
It is Domain 3 of the IIBA CBDA exam, worth 16% of 75 questions, about 12 questions. It covers the work between a dataset and a model: section 2.3 of the Guide to Business Data Analytics.
How many tasks are in CBDA Analyze Data?
Five: Develop Data Analysis Plan, Prepare Data, Explore Data, Perform Data Analysis, and Assess the Analytics and System Approach Taken. Section 2.3 also has a techniques table (2.3.6) and a case study (2.3.7).
Do I need to build machine learning models for the CBDA?
No. The guide says the analyst is more likely to support the data scientist than to run the models. IIBA describes the domain's competencies as general awareness and basic knowledge, such as interpreting regression output.
What is the difference between Explore Data and Perform Data Analysis?
Explore Data is a quality check on a subset, with four checkpoints: integrity, validity, reliability and bias. Perform Data Analysis comes after the quality issues are resolved and applies statistics and models to the research question.
Which techniques matter most in CBDA Domain 3?
Descriptive and inferential statistics, technical visualizations and exploratory data analysis for the work itself, plus BABOK techniques such as KPIs, Decision Analysis and Scope Modelling for the analyst's role.
Sources
- IIBA: Certification in Business Data Analytics (CBDA)
- IIBA: Guide to Business Data Analytics, 2.3 Analyze Data
- IIBA: CBDA competencies
- CrowdFlower: 2016 Data Science Report (PDF)
- Leigh Dodds: Do data scientists spend 80% of their time cleaning data? Turns out, no? (2020)
- BigDATAwire: Data Prep Still Dominates Data Scientists' Time, Survey Finds (2020)
- KDnuggets: Survey: Machine Learning Projects Still Routinely Fail to Deploy (2024)
- Medium: Gaining insight from real-world data science, 5 lessons learned (2023)
- DEV Community: Using SQL to discover problem dates in your data (2024)
- SPR: Battling data leakage, lessons from an enrollment model (2023)
- Towards Data Science: Stop using measures like accuracy, precision or recall (2019)
- Medium: Business Data Analytics Certification, a CBDA passer's notes
- Techcanvass: CBDA certification journey of Aniket (2024)
- R for Data Science, 2nd edition: Exploratory data analysis
- Towards Data Science: Data cleaning is analysis, not grunt work (2021)
- KDnuggets: What's the difference between analytics and statistics? (2019)
- Techcanvass: Business analyst role in data science (2025)