How to Write a Data Analysis Report That Gets Read

Most analysis reports are written in the order the work was done: background, data, method, results, and, finally, the conclusion. Most readers never reach it. They read the title, the first paragraph and perhaps a chart, then decide whether to continue. A report that gets read is written for that behaviour: the answer is where people look first, and everything else is there to support it.

Put the answer first

The inverted pyramid, long used in journalism and recommended for writing on the web, starts with the most important information, effectively the conclusion, so readers get the main point however much they read (Nielsen Norman Group: inverted pyramid). Academic papers often do the opposite, building up to the conclusion at the end. Business reports should follow the journalists.

The structure

1. A title that states the finding. "Autumn sales doubled on UK order volume; plan capacity accordingly" tells the reader something before they open the document. "Q4 sales analysis" does not.

2. A summary that stands alone. Three to five sentences: the answer, why it matters in money, customers or risk, and the recommendation or decision needed. If a senior reader reads only this, they should be able to act.

3. Key findings as evidence. Two to four short sections, each opening with one sentence stating a finding, followed by the chart or table that supports it and a line on what it means. Order them by importance, not by the order you discovered them.

4. Recommendation and next steps. What should happen, who should do it, and by when. If there are options, show them with their trade-offs and say which you recommend.

5. Data and method. Sources, period, definitions, exclusions and approach, written so a colleague could reproduce the work. This is where cleaning decisions and row counts belong.

6. Limitations. What the analysis cannot show, and how that might change the conclusion. Stated plainly, this builds trust rather than undermining it.

7. Appendix. Detailed tables, extra charts and query references for anyone who wants to check.

An example summary

For an analysis of an online gift retailer's autumn sales, a summary that stands alone might read: "Sales doubled between August and November 2011, to almost 1.5 million, because far more UK customers placed orders; the average order was slightly smaller. We recommend planning warehouse and customer service capacity for about twice the summer order volume from September, and testing bundles to lift order value. A decision on seasonal staffing is needed by the end of July."

Writing so it is easy to read

Guidance on plain writing starts from the audience (plainlanguage.gov: guidelines): write for the specific people who will read the report, not for other analysts. In practice:

• Short sentences and paragraphs. One idea per paragraph.
• Active voice. "Returns rose 3%" rather than "an increase in returns was observed".
• Everyday words instead of jargon: "fewer customers came back" rather than "retention decay".
• Define any necessary term once, the first time it appears.
• Headings that say something, so a reader skimming the headings gets the story.

Numbers and charts

• Round to the precision that matters. "About 1.5 million" in the text; exact figures in tables.
• Present numbers consistently: numerals, commas in thousands, the % sign, and the same number of decimal places in a list, as style guides such as GOV.UK's set out (GOV.UK: style guide).
• Always give a comparison: previous period, target or benchmark.
• One message per chart, stated in its title, with the relevant part highlighted.
• Label percentages clearly: percentage points for changes in rates, percent for relative changes.

A reusable template

• Title: the finding in one line.
• Summary: answer; why it matters; recommendation; decision needed and by when.
• Findings: finding 1 with evidence and implication; finding 2; finding 3.
• Recommendation and next steps: action, owner, date; options if relevant.
• Data and method: sources, period, definitions, exclusions with counts, approach.
• Limitations: what the analysis cannot show and how it might change the conclusion.
• Appendix: detailed tables and charts.

How long should it be?

As long as the decision needs and no longer. For many business questions, the summary and findings fit on one or two pages, with method and appendix after. If the report grows long, check whether it is answering one question or several; two separate short reports are often better than one long one.

A checklist before sending

1. Could someone act on the summary alone?
2. Does the title state the finding?
3. Does every chart support a finding stated in the text?
4. Are numbers consistent between the summary, text and charts?
5. Are definitions and exclusions stated?
6. Is the main limitation stated plainly?
7. Has someone outside the analysis read it and explained it back correctly?

The last check is the most revealing: if a colleague summarises your report differently from how you would, the structure or wording needs another pass.

Related skills

A report is a written story. How to tell a story with data covers building the narrative, and presenting data to non-technical stakeholders covers delivering it in a meeting. Data visualisation best practices covers making the charts honest.

Business reporting and data storytelling are part of the Data Analytics course.

Sources

• Inverted Pyramid: Writing for Comprehension (Nielsen Norman Group) — Nielsen Norman Group
• Federal plain language guidelines (plainlanguage.gov) — plainlanguage.gov
• A to Z style guide (GOV.UK) — GOV.UK