data-analysis

data-analysis

An analysis is only as good as the question it answers and the caveats it discloses. A number without its uncertainty, sample size, or known bias is a number that will be misused. Anchor every step in the actual question being asked — don't just run statistics because the data supports them.

1. Start with the question, not the data

• Write down the specific question before opening the dataset: "did feature X change conversion?" is answerable; "tell me about this data" isn't — it invites cherry-picking whatever pattern looks interesting.
• Identify what decision this analysis feeds. That determines the bar for rigor — a rough sanity check for internal curiosity needs less than a number going into a public report.

2. Profile before you touch anything

Before cleaning or analyzing:

df.shape                       # rows, columns
df.dtypes                      # are numbers actually numeric, dates actually dates?
df.isnull().sum()              # nulls per column
df.duplicated().sum()          # exact duplicate rows
df.describe(include="all")     # ranges, distinct counts, obvious outliers
df.sample(10)                  # eyeball real rows, don't trust the schema blindly

Know the data's shape and quality before drawing any conclusion from it — most bad analyses trace back to an unnoticed null-heavy column or a units mismatch (cents vs dollars, UTC vs local) caught too late.

3. Clean deliberately, and log every change

• Document every row/column you drop or value you impute, and why — a colleague (or future you) needs to know the cleaned data isn't the raw data.
• Don't silently drop nulls/outliers without checking whether they're meaningful (a null "cancellation_reason" might mean "not cancelled", not "missing data").
• Prefer flagging over deleting when unsure (is_outlier column) — deletion is a one-way door that hides the decision from later review.

4. Sanity-check before concluding

• Check sample size — a "40% lift" on 12 users isn't a finding, it's noise. Report the N alongside every rate/percentage.
• Check for sampling bias — does the data represent who/what you're claiming to generalize to, or just who was easiest to measure (e.g. only logged-in users, only completed transactions)?
• Watch for Simpson's paradox — a trend that holds in aggregate can reverse within every subgroup. Slice by the obvious confounders (cohort, region, time period) before trusting an aggregate number.
• Correlation is not causation. If the question is causal ("did X cause Y"), say explicitly whether the analysis can actually support that claim (controlled experiment) or only an association (observational data) — don't let the phrasing imply more certainty than the method supports.