CBDA Interpret and Report Results: Domain 4, All Five Tasks

CBDA Interpret and Report Results is Domain 4 of the IIBA Certification in Business Data Analytics: 20% of 75 questions, so about 15 questions [1]. It covers five tasks in section 2.4 of the Guide to Business Data Analytics: validate your understanding of stakeholders, plan communication, determine communication needs, derive insights and communicate findings [2]. The key idea for the exam: a data pattern is not an insight until it means something for the business.

CBDA Interpret and Report Results at a glance

Interpret and Report Results is the domain where analysis turns into a message for a specific audience. The facts:

Last verified: November 2026 (exam facts, fees and competencies on iiba.org).

The competency list surprised me. In Analyze Data, all nine competencies are "General Awareness" [3]. In Domain 4, five of nine are practical: for example, "Follows Rules in developing visualizations to help with communications" and "Follows Rules in determining stakeholder communication needs" [3]. So the exam expects you to apply the reporting rules, not only to recognize them. I think this is the most useful fact for planning your study time on this domain.

One more detail: Domain 4 competencies include "putting forth recommendations from insights derived" and "refining problem/opportunity statements based on findings" [3]. Domain 5, Use Results to Influence Business Decision Making, is where those recommendations drive a decision. On the exam, I would read Domain 4 as the place where findings and recommendations get framed, and Domain 5 as the place where they are acted on.

The five tasks of Interpret and Report Results

The guide lists five working tasks, and the first three are about people, not data [2].

The "what comes out" column is my summary. The guide does not name formal outputs for these tasks the way BABOK does. The guide's own task list also names "Select Techniques for Interpret and Reporting Results" (2.4.6); it is a techniques table, so I cover it in the techniques section.

The domain overview sets three questions [2]. Planning: who needs the insights, what they think about the subject, how engaged and available they are, and how often to communicate. Interpreting: how patterns, trends and models become business insights in business language. Explaining: which insight, which method, which level of detail, and how to record results and feedback. The guide's summary line is that analysts "think like a designer".

2.4.1 Validate Understanding of Stakeholders

Stakeholders were analyzed early in the engagement, but business context, strategy and personnel change. So the guide calls stakeholder analysis "ongoing and continually updated" [2].

What the analytics team keeps checking:

• changing needs and objectives;
• the importance of the research questions;
• how quickly the analytics results are expected;
• skill-sets for interpreting those results;
• levels of education in and experience with analytics.

To validate, the team uses brainstorming, interviews, process modelling and other models such as organizational charts. It also reviews the models that linked enterprise strategic goals to organizational goals and to the impacted stakeholders [2].

Exam trap: an answer that reuses the stakeholder analysis from Domain 1 "as is". The guide expects you to re-validate it before you interpret and report.

2.4.2 Plan Stakeholder Communication

Planning means deciding what needs to be communicated, to whom, how and when. The guide says it "is like most other initiative-level communication planning" [2]. What makes analytics different is in the list of considerations:

• communications can involve an intermediate or a final result, because analytics initiatives are iterative;
• formality and level of detail vary between stakeholders;
• stakeholders need different levels of expertise to interpret results;
• privacy and confidentiality have to be maintained;
• stakeholders stay informed about progress and the approaches taken;
• the level of communication stays appropriate during the initiative;
• responses and feedback are recorded for action and follow-up.

Exam trap: "wait until the final model is ready, then present". The guide explicitly allows intermediate results and progress updates.

2.4.3 Determine Communication Needs of Stakeholders

This task customizes communication for individual stakeholders or groups "so the message is clearly understood" [2]. The input is stakeholder characteristics from stakeholder analysis. Communication requirements can include:

• what information is most relevant to them;
• how they wish to receive information, and how often;
• who the decision-makers in the group are;
• what biases they carry;
• what factors can weaken the analysis, such as contradictory results, the analytics approach, data anomalies, and stakeholders' impact and influence.

The guide also warns about friction. Descriptive and diagnostic results may expose gaps in a business process between stakeholders. Predictive and prescriptive results may suggest a completely new way of decision-making, so stakeholders may resist [2]. Some settings impose formats: drug discovery and medical studies have regulatory structures. Analysts use elicitation techniques here, and retrospectives or lessons learned show which communication methods worked.

Exam trap: an option that hides the weak points of the analysis from a skeptical stakeholder. The guide wants you to identify those factors, not to bury them.

2.4.4 Derive Insights from Data

The first inference happens in Analyze Data with statistics, technical visualizations and models. Whether those patterns have business relevance is decided here [2].

The guide's example: when Uber ride density in San Francisco was merged with the city's crime rate, the most rides started in high-crime neighbourhoods. A fascinating correlation, but demand prediction "should not be modelled on the crime rate without stronger evidence of a relationship" [2]. Analysts use "sound statistical judgment and explanatory analysis", especially when findings go against common business practice. If you want more on this trap, see correlation vs causation on the CBDA exam.

The second example is about audiences. An error residue graph shows prediction error falling as predictors are added to a revenue forecast. It helps the data scientist choose the number of variables, while a marketing stakeholder will likely want to see how ad spend relates to revenue [2]. That is the line between technical visualizations (3.18) and business visualizations (3.2).

The task closes with a Visualization Best Practices box [2]:

It also names six Gestalt principles: proximity, similarity, enclosure, closure, continuity and connection. The skills listed for this task are organizational skills, systems thinking, design thinking, creativity, attention to detail, stakeholder orientation and industry knowledge. My detailed take on chart choice is in the business visualizations technique guide.

Exam trap: a correlation presented as a cause, or a technical chart sent to a business audience.

2.4.5 Document and Communicate Findings from Completed Analysis

The rule of this task is short: "let the data speak for itself" [2]. Analysts decide how to package the results, how much to summarize and how to group information. Then they synthesize the main themes into a narrative, and may produce reports and dashboards.

Two things belong in the findings, and candidates often forget the second:

1. the results;
2. the methods used, the process followed, and "any limitations or weaknesses in the data or methods used" [2].

The narrative answers three questions: "Where are the data gaps?", "What does this mean for the business?" and "How can the business improve?". The guide adds four questions to consider when reporting results, from the most important aspects of the conclusions for each stakeholder to whether a video or dynamic visualization would be more engaging than a pure text report.

Then come data visualization and data storytelling. Stories create engagement "so that stakeholders feel invested in the insights" and give context for decision-making. Depending on the setting, analysts use storyboards, an elevator pitch, a 3-minute story, the big idea, data journeys and orchestration [2]. The guide calls this the place where "the fundamental value proposition" of analytics shows: decisions based on instinct are replaced by evidence-based decisions.

Exam trap: a findings package with results only. Methods and limitations are part of the findings.

Techniques used in Interpret and Report Results

The 2.4.6 table has 11 techniques: six with a BABOK reference and five specific to analytics [2].

The Big Idea row has the best example in the domain. A visual shows an S-curve between marketing expense and revenue for a customer cohort. The big idea answers "so what": beyond a certain dollar value, marketing expense "does not have any impact on revenue" [2].

In chapter 3, the core techniques for this domain are Business Visualizations (3.2), Data Storytelling (3.7), Stakeholder List, Map, or Personas (3.16), The Big Idea (3.19) and the 3-Minute Story (3.20). Technical Visualizations (3.18) stay with the data scientists, but they feed 2.4.4. Data Journeys, Storyboarding and UX Patterns appear in the table, but chapter 3 has no section for them.

Section 3.16 is worth a reread for this domain. Its Interpret and Report Results part says the key messages stay the same, while five factors change per audience: preferred type of communication (in-person or a dashboard online), information and level of detail, type of visualization, formality, and timing and frequency (Guide, 3.16). Several other techniques say they have no significant role in Domain 4 but can still help: concept models illustrate complex business vocabulary (3.3), new data elements defined from the results can be added to the data dictionary (3.4), data flow diagrams "can be used to support the narrative being constructed" (3.5), the reported results may change future decision models (3.8), and interface analysis leads to more accurate interpretation (3.13).

How it works in practice: the HiFive Ice Creams case

The guide's case study (2.4.7) is about one stakeholder who was not convinced, and an analyst who fixed the communication rather than the analysis [2].

HiFive Ice Creams, a premium retailer with dozens of parlours, wanted to measure the return on its social media marketing. A data team built an automated model with two metrics: influence (IE), the net influence of a user in a social network, and influence value (IV), word-of-mouth linked to actual sales. Nine months later, during an acquisition bid, Prisha Singhal, Director of Marketing at the acquiring company, asked why the team had chosen Facebook.

The team answered with a table of regional adoption: Facebook had 64,000 users and a 57% proportion of local connection; WordPress 37,590 and 13%; Foursquare 3,100 and 43%. Prisha was not convinced, because the table did not show how the data supported the strategic objective.

Here is how the analyst's steps map onto the five tasks:

The matrix had four criteria: more than 15,000 users in a locality, more than 25% of contacts within the locality, low effort to share the message, and simple connections to share it. The totals: Facebook 4, Twitter 3, SecondLife 3, Foursquare 2, and 1 each for WordPress, YouTube and Groupon [2]. Prisha left with "a very favourable assessment".

My take: the data did not change between the first and the second answer. The criteria did. The first table answered "which network is biggest", while Prisha's question was "why does this serve our objective". On the exam, if a stakeholder pushes back, look for the option that reframes the same evidence at the right level of detail before the option that runs more analysis.

What practitioners and data say about reporting work

Practitioners agree with the guide on one thing above all: a correct analysis can still fail at the reporting stage.

Most insights do not reach the decision. In a 2019 survey of 9,000 employees for a data literacy initiative, only 21% were confident in their data literacy skills, and 48% frequently deferred to "a 'gut feeling' rather than data-driven insights" [11]. A 2022 survey of 214 data and analytics leaders put the share of employees actively using BI tools at 25% on average [12]. A Gartner analyst predicted in 2019 that through 2022 "only 20 percent of analytic insights will deliver business outcomes" [13]. That last one is a forecast, not a measurement, so I treat it as a direction, not a fact.

The audience is the hard part. A data science consultant describes a paper she sent to a Board after about five years as an analytics manager: a CEO about a month into the job went through it "line by line" for 60 minutes. Her conclusion: "I hadn't paused for even a moment to think about the needs of the Board" [6]. This is 2.4.3 in one sentence.

Undisclosed limitations get attacked. A marketing data analyst spent months on a marketing mix model but neglected dataset accuracy; senior managers questioned it during the presentation, and months of effort were wasted [7]. He also notes the pressure: "Nobody wants to hear that the campaigns ran failed to meet the expectations." This is why 2.4.5 puts limitations into the findings.

Executives rarely open dashboards. A data science writer concludes from his conversations that "senior management doesn't like to look at dashboards" [8]. A staff data analyst at a software company describes the alternative her team used: each analyst aimed at one insight a week, posted in a team Slack channel with one to seven bullet takeaways and a chart, and "Explicitly inviting questions and responses is crucial" [9]. That is planned, recorded, two-way communication from 2.4.2.

Candidates find the questions tricky. A CBDA candidate with 10+ years in IT, including BI and analytics work, writes that many questions had "two confusing answers", and she had only 20 minutes left to review flagged items [4]. A product owner and BA with about 8 years of experience, who read the guide 5–6 times, says "the questions asked in the exam are scenario-based questions" [5]. Neither post discusses Domain 4 specifically. I could not find a first-hand write-up about Domain 4 questions online.

Experts disagree on how far the analyst should go

Everyone agrees insights must be communicated; they disagree on whether the analyst should recommend, and in which format.

1. Explain, don't hand over exploration. One storytelling practitioner separates the two clearly: "Exploratory analysis is what we do to find interesting things in our data", while the audience gets an explanatory visual with the takeaway highlighted [14]. This matches the guide's "explanatory analysis rather than exploratory analysis" [2].

2. Analysts inspire, decision-makers decide. Google's then chief decision scientist argues that analysts' "mandate is to summarize interesting facts and to use data for inspiration", while decision-makers choose [15].

3. Analysts must take a stance. An analyst turned executive argues the opposite: analysts too often "hide in our data" instead of taking a position, while the people deciding "need us to be courageous" [10].

4. Recommendations belong in the report itself. A web analytics author argues every dashboard should carry insights, actions and business impact, not only metrics [16]. A visualization consultant goes further: the work is "only done when the decision-maker is convinced" [17].

My take: for the exam, follow the guide and the competency list. Domain 4 frames findings and can put forth recommendations [3]; the decision itself belongs to stakeholders and to Domain 5. At work I lean towards positions 3 and 4. A findings deck without a "so what" usually comes back with one question: what should we do?

What the exam looks for in Domain 4

Scenario questions in this domain usually test one of these choices.

How to prepare for the Interpret and Report Results domain

Plan for practical application, because five of the nine competencies are at that level [3].

1. Read 2.4 in full, including the Visualization Best Practices box and the HiFive case.
2. Then read 3.2, 3.7, 3.16, 3.19 and 3.20; they are the core techniques of this domain.
3. Practise one translation a day: take a technical result and write the business insight in one sentence, as the Big Idea example does.
4. Learn the box rules as if-then pairs: one or two metrics → text; pie with angles → horizontal bar; secondary axis → avoid.
5. Drill scenario questions: start with the CBDA Interpret and Report Results quiz, then a timed mock on the CBDA exam simulator.

Before Domain 4, it helps to know where the patterns come from; the CBDA Analyze Data domain guide covers that. And for why research questions decide what "relevant" means here, see CBDA Domain 1, Identify the Research Questions.

Check yourself: CBDA practice questions

Four short questions, checked against section 2.4 of the guide.

1. A CFO needs this quarter's ROI and profit margin for a board pack. What does the guide suggest?

A. A 3D column chart B. A dual-axis chart with ROI and margin C. Simple text with the two values D. A dashboard with drill-down

Answer: C. With a single or a couple of metrics, simple text may communicate better (2.4.4 box).

2. Merged data shows that most food deliveries start in neighbourhoods with many parks. Marketing wants to forecast demand from park density. What should the analyst do?

A. Build the forecast; the correlation is strong B. Treat it as a pattern that needs stronger evidence of a relationship before modelling C. Drop the data set D. Report it as the main insight

Answer: B. This is the guide's Uber example in another form (2.4.4).

3. Which belongs in documented findings from a completed analysis?

A. Only results that support the hypothesis B. Results, methods, process and limitations C. Raw data extracts D. The data scientist's code

Answer: B. The guide lists all four (2.4.5).

4. A new VP joins halfway through the initiative. What should the team do first in Domain 4 terms?

A. Keep the original communication plan B. Re-validate the stakeholder analysis C. Send the full technical report D. Wait for the final results

Answer: B. Stakeholder analysis is ongoing and continually updated (2.4.1).

Key takeaways

• Domain 4 is 20% of the CBDA exam, and its competencies are more practical than those of Analyze Data.
• Three of five tasks are about stakeholders; the data work starts in 2.4.4.
• A pattern becomes an insight only when it has business relevance and enough evidence.
• Findings include methods and limitations, not only results.
• The core techniques are business visualizations, data storytelling, stakeholder analysis, the big idea and the 3-minute story.

Related topics

• CBDA data visualization questions: chart-choice drills for 2.4.4.

FAQ

What is the Interpret and Report Results domain on the CBDA exam?

It is Domain 4 of the IIBA CBDA exam, worth 20% of 75 questions. It covers how analysts turn analysis results into business insights and communicate them to stakeholders at the right level of detail.

How many tasks are in CBDA Interpret and Report Results?

Five: Validate Understanding of Stakeholders, Plan Stakeholder Communication, Determine Communication Needs of Stakeholders, Derive Insights from Data, and Document and Communicate Findings from Completed Analysis. Section 2.4 also has a techniques table (2.4.6) and a case study (2.4.7).

What is the difference between a data pattern and a business insight?

Patterns describe trends, distributions and statistical parameters. Business insights infer business-relevant facts from them. The guide's Uber example shows a striking correlation that should not drive a model without stronger evidence.

Which techniques matter most in CBDA Domain 4?

Business visualizations, data storytelling, stakeholder list, map or personas, the big idea and the 3-minute story. The 2.4.6 table also lists interviews, prototyping, root cause analysis, workshops, storyboarding, data journeys and UX patterns.

Does Domain 4 include recommendations?

Partly. IIBA's Domain 4 competencies include putting forth recommendations from insights. Acting on those recommendations belongs to Domain 5, Use Results to Influence Business Decision Making.

Sources

1. IIBA: Certification in Business Data Analytics (CBDA)
2. IIBA: Guide to Business Data Analytics, 2.4 Interpret and Report Results
3. IIBA: CBDA competencies
4. Techcanvass: A CBDA candidate's exam journey (2024)
5. Techcanvass: CBDA certification journey of Aniket (2024)
6. Genevieve Hayes: The 60 minutes that transformed my data science career (2025)
7. Medium: Graduate from an amateur analyst, an insider's perspective
8. The Art of Data Science: The dumbest thing in data science (2024)
9. Locally Optimistic: Share your data insights to engage your colleagues (2021)
10. benn.substack: Does data make us cowards? (2021)
11. Qlik press release: Data skills gap is costing organizations billions in lost productivity (2020)
12. BARC: New study identifies drivers of BI and analytics adoption (2022)
13. Digital Insurance: Gartner's top data and analytics predictions for 2019
14. storytelling with data: Our tools don't know the story (2018)
15. AAPL: What great data analysts do, and why every organization needs them (HBR reprint, 2018)
16. Occam's Razor: The action dashboard, an alternative to crappy dashboards (2008)
17. Dark Horse Analytics: Own the adoption (2016)