ICDL Data Analytics (ICDL) common mistakes
ICDL Data Analytics · Understand the traps and how to avoid them.
Answering a scenario question with descriptive statistics when the question is asking about a wider population - e.g. reporting 'average delivery time is 3.2 days' from a 40-row sample file and treating it as the organisation-wide figure, with no mention of sample size or uncertainty.
Candidates read the number off the screen and stop there; the distinction between summarising the data in hand and generalising beyond it is not something they check for before answering.
What to do instead
Before answering, ask two questions in order: 'Am I describing these rows only, or a larger group?' If the wording mentions all customers, the population, or a forecast, state the sample size and that the figure is an estimate, and give a range rather than a single value.
Choosing the mean as the headline 'typical' value for a skewed column (income, order value, call duration) and reporting it alone, despite a handful of very large values.
The mean is the default function candidates reach for, and it is easy to compute without ever looking at the shape of the distribution.
What to do instead
Build a quick histogram or a min/median/max check first. If the distribution is skewed or has outliers, report the median and quartiles as the typical value and mention the mean separately as a total-based measure.
Deleting or filtering out every row with a blank or duplicate before deciding what the blank or duplicate means, so 'not recorded', 'zero' and 'not applicable' all disappear as if they were bad data.
Removing blanks makes the file look clean and makes counts line up, so it feels like progress; there is no step that forces a decision about each column.
What to do instead
Write a one-line rule per column before touching anything: keep / impute with a stated value / flag as unknown / delete. Only delete a row when the record is unusable for the analysis, record how many rows each rule removed, and report the excluded count with the results.
Opening a CSV or text file with default import settings so identifier codes lose leading zeros (00731 becomes 731), long numbers turn into scientific notation, and dates in dd/mm/yyyy are read as mm/dd/yyyy.
Spreadsheets and BI tools guess data types from the first rows; candidates assume the preview shown is what will be loaded and never inspect the imported columns.
What to do instead
Import identifier columns as text and set the locale/date format explicitly. After import, verify three things: the row count matches the source, the first and last identifier values are unchanged, and a known date appears with the correct day and month.
Cleaning and sorting the original source file in place - overwriting values, deleting columns, saving over the raw extract - with no copy kept and no record of what was changed.
It is the fastest path from download to answer, and candidates do not plan for having to justify or reverse a change.
What to do instead
Keep the original file read-only and work on a dated copy. Log each transformation (what changed, which rows, why) in a short change log so any figure in the final report can be traced back to the source.
Applying an AutoFilter and then totalling the column with SUM or AVERAGE, so the reported total includes the hidden rows and does not match the visible subset.
Filtered rows are hidden, not removed, and the whole-column function looks identical whether or not a filter is active; candidates trust the number because the screen only shows the filtered rows.
What to do instead
Use SUBTOTAL (function 9 for sum, 1 for average) or AGGREGATE so hidden rows are excluded, or build a pivot table. Sanity-check by comparing the filtered total to the grand total and confirming the difference equals the excluded rows.
Calculating from a pivot table or summary that was built before the source data was edited, and quoting the stale figures without refreshing; or dragging a formula down one row short so the last record is silently omitted.
Pivot output and copied formulas look finished on screen, and neither displays a warning that it is out of date or misaligned with the data range.
What to do instead
Refresh all pivots after any source change and reconcile one known cell by hand. For ranges, use a table or structured reference so the range grows automatically, and confirm the count of rows covered equals the expected record count.
Selecting a chart type by what looks attractive - a pie chart with fifteen slices, two pie charts to compare two periods, or a line chart joining unordered categories - instead of by the relationship being shown.
Candidates pick the chart they have practised with rather than starting from the question 'comparison, trend, part-to-whole, or distribution?'
What to do instead
State the relationship first, then pick: comparing categories → bar; change over time → line; part-of-a-whole with five or fewer slices → single stacked bar or bar; distribution → histogram. If a pie would need more than about five slices, switch to a sorted bar chart.
Leaving a bar or column chart's value axis starting above zero (or otherwise truncated) so a small difference between two categories looks like a large one.
Charting tools auto-scale to fill the plot area and the axis minimum is rarely adjusted; the resulting visual exaggeration is invisible to the person who built it.
What to do instead
Force the bar chart value axis to start at zero. If a non-zero baseline is genuinely needed for a line chart, break the axis visibly and label it; otherwise state in the title or caption that the axis is truncated.
Publishing a chart or dashboard with no axis titles or units, an unlabelled or unclear legend, and no source or as-at date, and encoding categories by colour alone.
The author already knows what the chart shows, so the missing context is invisible to them; colour is also the easiest series distinction to apply.
What to do instead
Run a fixed checklist before submitting: title saying what and when, axis titles with units, every series named directly or in a legend, data source and as-at date, and a second cue (direct labels, shape or pattern) so the chart still reads in greyscale or with colour-vision deficiency.