Google Data Analytics common mistakes
Google Data Analytics · Understand the traps and how to avoid them.
Confusing the six phases of the data analysis process (Ask, Prepare, Process, Analyze, Share, Act) - for example, labeling data cleaning as part of the Prepare phase or placing visualization in Analyze - and picking the wrong phase on scenario questions.
The phases overlap in practice, so candidates map their own workflow habits onto the exam's definitions instead of memorizing the course's boundaries for each phase.
What to do instead
Memorize a one-line deliverable for each phase (Ask = business question defined; Prepare = data collected and stored; Process = cleaned and validated; Analyze = patterns and calculations; Share = visuals and narrative with stakeholders; Act = decision or change). For every scenario, ask 'what is the analyst producing right now?' and match that output to the phase.
Treating 'data-driven decision making' as synonymous with 'use the data you have', and choosing an answer that skips clarifying the business question when a stakeholder request is vague.
Candidates want to demonstrate technical initiative, so they jump to data collection rather than recognizing that the first phase is defining the problem and the metrics.
What to do instead
Whenever a prompt describes an ambiguous stakeholder request, eliminate answers that begin with data pulling. The correct answer usually involves asking clarifying questions, identifying objectives, or defining success metrics (SMART-style) before any data work begins.
Mixing up the four question types - descriptive, diagnostic, predictive, prescriptive - for instance calling 'Why did sales drop in Q3?' descriptive because it uses past data.
Candidates classify by the tense of the data (past vs. future) rather than by the purpose of the question, and diagnostic questions often use historical data too.
What to do instead
Classify by intent: descriptive = what happened; diagnostic = why it happened; predictive = what is likely to happen; prescriptive = what should be done. Practice by writing one question of each type against the same dataset metric so the intent-based distinction becomes automatic.
Selecting an internal secondary data source when the prompt calls for primary data, or vice versa, and choosing 'the most convenient' source over the one that matches the stated need.
The terms sound interchangeable in casual use, and candidates focus on data quality rather than on who generated the data and for what purpose.
What to do instead
Anchor on origin: primary data is collected by the analyst/team for the current question (surveys, interviews, own tracking); secondary data was collected by someone else for another purpose (public datasets, vendor reports, internal sales records). Also memorize the ROCCC bias check (Reliable, Original, Comprehensive, Current, Cited) and apply it to eliminate weak-source options.
Answering database questions by treating SQL and spreadsheets as interchangeable - e.g., saying a spreadsheet is the right tool for querying millions of rows, or that SQL is used to build dashboards.
Course material presents tools side by side, and many learners only have hands-on experience with one of them, so they pick the familiar tool regardless of the scale or task described.
What to do instead
Build a tool-choice table keyed to the task: large volumes, joins across tables, repeatable queries → SQL/database; quick ad hoc exploration, small data, presentational tables → spreadsheet; statistical modeling and larger pipelines → Python/R; interactive reporting → visualization tool. Read the prompt for scale and repeatability keywords before answering.
Choosing 'delete the row' as the fix for every data-quality problem, including missing values that matter, duplicates that should be aggregated, or values that are merely in the wrong format.
Deleting is the easiest action to conceptualize, so candidates default to it without weighing sample-size loss or whether the null itself is informative.
What to do instead
Learn a decision rule: formatting inconsistencies → standardize; duplicates → dedupe or aggregate; missing values → investigate first, then impute, leave as null, or remove only if the volume is small and the missingness is random. On exam items, eliminate any option that discards data without first diagnosing why the value is missing.
Applying spreadsheet functions by rote without checking argument order or range anchoring - e.g., assuming VLOOKUP's third argument is the column letter, or writing SUMIF criteria without quotes - and then misreading the resulting output.
Candidates memorize function names during review but not signatures, and under time pressure they pattern-match on the function's name rather than its syntax.
What to do instead
Drill a short list of high-yield signatures with the argument order written out (VLOOKUP(search_value, range, column_index, [is_exact]); COUNTIF(range, criterion); SUMIF(range, criterion, [sum_range]); CONCATENATE/TEXTJOIN; LEFT/RIGHT/LEN/TRIM; SPLIT). Note that criteria strings with operators need quotes, and that a lookup column index counts from the start of the range, not the sheet.
Reading a summary statistic as a conclusion - declaring a relationship or a group difference from an average, correlation, or pivot-table total without checking distribution, sample size, or confounders.
The exam's analysis items often contain a plausible-sounding numeric conclusion, and candidates accept it because the arithmetic is correct, missing that the interpretation overreaches.
What to do instead
Before accepting any conclusion, run a mental checklist: What is n? Is the measure an average, median, or proportion? Could an outlier or a small subgroup be driving it? Does correlation get described as causation? Eliminate options that state a definitive causal or population-wide claim from a small or non-random sample.
Choosing a chart type by aesthetics rather than by data relationship - using a pie chart for many categories, a line chart for unordered categorical comparisons, or a 3D chart for a precise comparison - and misreading axis or scale questions.
Candidates review chart types as a vocabulary list rather than as mappings from data shape to visual encoding, so they select the most familiar chart.
What to do instead
Memorize the mapping: change over time → line; comparison across categories → bar; part-to-whole with few slices → pie or stacked bar; distribution → histogram or box plot; relationship between two numeric variables → scatter. Then eliminate options that add decorative 3D, truncated axes, or too many slices, since those distort perception.
Confusing Python syntax roles - mixing up list versus dictionary versus tuple, indexing from 1 instead of 0, or forgetting that pandas requires .loc/.iloc conventions and that Series operations align on index.
Learners coming from spreadsheets or R carry over 1-based indexing and expect column references to behave like cell references, and course review time is often spent reading rather than typing code.
What to do instead
Practice in a live notebook rather than reading: create a list, tuple, dictionary, and DataFrame; index each from 0; add a column with df['new'] = ...; filter with boolean masks; and use .iloc for position and .loc for label until the distinction is automatic. Write down the exact error message each mistake produces so you recognize the failure pattern in an exam scenario.
Treating the capstone as a coding exercise and skipping the framing: no clearly stated business question, no documented data limitations, and a final presentation of charts without recommendations tied back to the original ask.
Candidates optimize for producing analysis artifacts and assume the grader or reviewer will infer the purpose, when the case study is assessed on end-to-end process and communication.
What to do instead
Structure the deliverable as the six phases with an explicit artifact for each: a written problem statement and success metric; a data source list with ROCCC notes; a cleaning log of every change; the analysis with assumptions stated; visuals with a one-sentence takeaway each; and a closing slide of recommended actions and next steps. Test it by asking whether a reader who never saw your data could restate your question and your recommendation.