Tableau Data Analyst common mistakes
Tableau Data Analyst · Understand the traps and how to avoid them.
Connecting to a data source and leaving the join type as the default inner join without checking whether unmatched rows on either side should be preserved.
Candidates focus on getting the join keys to match and stop once rows appear; the default join type is rarely surfaced prominently, so the row-count change goes unnoticed.
What to do instead
After every join, compare row counts before and after and explicitly choose Inner, Left, Right, or Full Outer based on which unmatched records must survive; verify with a quick count of null keys on each side.
Treating a union as a join, stacking tables with different column meanings or orders and assuming Tableau aligns them by name.
Union appends by position/name automatically and the preview looks plausible, so mismatched semantics (e.g., 'Revenue' in one table and 'Cost' in another) silently merge into one column.
What to do instead
Before unioning, confirm columns are semantically identical; rename or restructure mismatched fields first, and inspect the union preview to confirm each source column lands in the intended field.
Assuming every field imported as a string or number is correctly typed, then building calculations on a field that is actually a string.
Data source defaults and Excel/CSV quirks leave numeric-looking fields as text; calculations then fail or aggregate incorrectly and the error is not obvious in the view.
What to do instead
Audit data types in the data pane immediately after connecting; convert with the correct type change or a CAST/INT function, and confirm by checking that aggregation and sorting behave numerically.
Building a chart with the wrong aggregation level (e.g., summing an already-summed field, or averaging an average) because the grain of the data was never established.
Candidates jump to the visualization without confirming what one row represents, so SUM vs AVG vs COUNTD is chosen by habit rather than by grain.
What to do instead
State the grain of the source (what one row means) before building; choose the aggregation that matches that grain, and use COUNTD or LOD expressions when a distinct count at a different level is required.
Leaving a measure on the Rows shelf as continuous when a discrete category was intended (or vice versa), producing a line where bars were expected or a broken axis.
Tableau auto-assigns discrete/continuous and the pill color is easy to overlook; the resulting chart can still render, so the mismatch is not flagged.
What to do instead
Check pill color (blue discrete vs green continuous) against the intended chart type before finalizing, and explicitly convert the field as needed to get the correct mark and axis behavior.
Using a filter that excludes records needed for a percent-of-total or benchmark calculation, then reporting a distorted share.
Filters are applied before the calculation in view, so a top-N or category filter changes the denominator and the percentages no longer sum to the intended whole.
What to do instead
Decide whether the calculation should respect the filter; use a context filter, a FIXED LOD, or a table calculation with the correct addressing to keep the intended denominator, and verify totals reconcile.
Placing many individual sheets on a dashboard without sizing or layout containers, so the dashboard breaks at different screen sizes.
Candidates assemble sheets by dragging onto a free-form canvas and judge only at their own resolution; containers and fixed sizing are skipped because the layout looks fine locally.
What to do instead
Build the dashboard inside layout containers with an explicit dashboard size (fixed or range) chosen for the target device, then test at the minimum and maximum expected resolutions before publishing.
Adding dashboard filter actions that filter every target sheet by default, unintentionally blanking unrelated views when a user clicks.
The action is created quickly and the target/clearing behavior defaults are not reviewed, so a click on one chart silently filters sheets it should not affect.
What to do instead
For each filter action, explicitly set the source and target sheets, choose the fields to pass, and define clearing behavior (show all values vs leave filtered); test by clicking each mark and confirming only intended sheets respond.
Publishing a workbook to a server/project with embedded credentials or with permissions inherited from a broad group, exposing data more widely than intended.
Publishing focuses on getting the content live; credential embedding and permission inheritance are configuration steps that are easy to accept as defaults.
What to do instead
Before publishing, choose the authentication method deliberately (prompt users vs embed), publish to the correct project, and set permissions explicitly for the intended audience; verify by checking effective access for a test user.
Extracting data without a refresh schedule and assuming the published view stays current.
An extract is created once and the workbook looks correct at publish time; the lack of a refresh schedule only surfaces later when stale numbers are reported.
What to do instead
When publishing an extract, configure a refresh schedule (or document a manual refresh owner), and confirm the extract refresh history and last-update timestamp after publishing.