ICDL Data Analytics (ICDL) common mistakes
ICDL Data Analytics · Understand the traps and how to avoid them.
Treating 'data analytics' as a single activity and picking 'descriptive analytics' as the answer for any question that mentions summarising past sales, rather than distinguishing descriptive, diagnostic, predictive, and prescriptive questions by what they ask you to do.
Candidates learn the four types as a list of words and memorise one example each, so when a scenario is worded differently (e.g. 'why did churn rise last quarter?') they default to the type they memorised first instead of matching the question's intent to the type.
What to do instead
For each scenario, ask 'what is the output?' - a summary of what happened (descriptive), a cause/relationship (diagnostic), a forecast of what will happen (predictive), or a recommended action (prescriptive) - and choose on that basis, not on keywords like 'sales' or 'report'.
Confusing data types when selecting an analysis method, e.g. computing a mean for a categorical field such as region or product category, or treating an ordinal rating as nominal.
Spreadsheet tools compute an average on any numeric-looking column without complaint, so candidates never get corrective feedback and carry the habit into scenario questions.
What to do instead
Before choosing a statistic, classify the field: nominal (labels, no order), ordinal (ordered labels), interval/ratio (true numeric). Use counts and modes for nominal, medians and modes for ordinal, and means/standard deviations only for interval/ratio data.
Choosing a pie chart for data with many categories or for showing change over time, and choosing a line chart for unordered categorical comparisons.
Pie charts are visually familiar and candidates equate 'showing proportions' with 'pie chart' without checking category count or whether the underlying question is trend versus composition.
What to do instead
Apply a chart-selection rule: line for trend over time, bar for comparing categories, pie only for a small number of parts of one whole (roughly five or fewer), scatter for relationship between two numeric variables. State the rule to yourself before answering.
Reading a chart's axis incorrectly - treating a truncated y-axis as showing a large change, or misreading a stacked bar as if segments were separate bars.
Candidates look at the shape of the chart rather than the scale and legend, and truncated axes are common in business dashboards designed to emphasise small differences.
What to do instead
Before interpreting any chart, read the axis labels, the starting value of each axis, the units, and the legend. If the y-axis does not start at zero on a bar chart, note that the visual difference overstates the real one.
Reporting a correlation in the data as proof of causation, e.g. concluding that a marketing channel caused higher sales because the two moved together.
The scenario is written to invite the intuitive causal reading, and candidates do not habitually ask whether a confounding variable or reverse causation could explain the pattern.
What to do instead
For any 'X is associated with Y' scenario, check for a plausible third variable, the direction of the relationship, and whether the data came from a controlled comparison. If not, phrase the conclusion as association only.
Leaving duplicate records, inconsistent category spellings (e.g. 'UK', 'U.K.', 'United Kingdom'), or mixed date formats in the dataset before analysis or before building a pivot table.
Cleaning is tedious and candidates want to move to the visible task; the errors are invisible in the raw sheet but silently split totals once aggregated.
What to do instead
Run a fixed pre-analysis checklist every time: remove duplicates, standardise category labels, convert dates to one format, check for blanks and outliers, and confirm each column's data type before aggregating.
Building a pivot table or summary that silently omits blank or unmatched rows, then reporting totals that do not reconcile with the source count.
Default aggregation ignores blanks and unmatched lookup keys, so the summary looks correct while quietly losing records; candidates rarely cross-check row counts.
What to do instead
Always compare the record count in the summary against the source row count, and explicitly decide how blanks and unmatched keys should be treated (excluded and disclosed, or filled) before reporting.
Presenting a dashboard or report packed with every available metric instead of the few that answer the stated business question.
Candidates equate thoroughness with including more data, and the exam scenario's actual decision question gets buried under unrelated figures.
What to do instead
Write the decision the audience needs to make in one sentence first, then include only the metrics that inform that decision, with the most important one placed most prominently.
Interpreting an average without checking the distribution, e.g. recommending action based on a mean that is distorted by a few extreme values or a bimodal split.
Summary statistics are the easiest output to produce and candidates stop at the first number the tool gives them rather than examining spread or shape.
What to do instead
For any mean-based conclusion, also check the median, the range or standard deviation, and a quick distribution view. If mean and median diverge sharply, investigate the outliers before recommending anything.
Recommending an action that the data does not support at the stated confidence - overstating a small or noisy sample as a firm conclusion, or ignoring the base rate when judging a segment's performance.
Scenarios often present a striking but small subgroup result, and candidates anchor on the striking number without asking about sample size, base rates, or margins of error.
What to do instead
Before recommending, ask three questions: how many records is this based on, what is the comparison baseline, and how large is the uncertainty. If the sample is small or the baseline is missing, recommend further data collection rather than an action.