10 · Case study: Google Play Store cleaned EDA
With clean numeric data in hand, aggregate by category, compare free vs paid ratings with a t-test, and scatter installs against ratings to surface the dominant patterns.
Now that the data is clean, the real questions begin: which categories have the most apps, which earn most reviews, do paid apps rate higher than free?
Without this:
Without the EDA-on-clean-data stage, you'd jump straight to modeling and miss the dominant patterns sitting in plain sight.
Lesson 9 cleaned the Google Play Store data — converting string columns into numeric ones and dropping duplicates. This lesson picks up from that clean state and asks the analytical questions that cleaning unlocked.
The core EDA pattern on tabular data is:
"For each cohort X, summarise metric Y."
That single sentence covers most of what a data analyst does day-to-day:
- For each Category, what is the average Rating?
- For each Type (Free/Paid), what is the Rating distribution?
- For each install tier, does Rating increase?
This pattern maps directly to pandas groupby(X)[Y].agg() — which is also the structure of SQL's GROUP BY X. If you can write a groupby, you can answer 80% of product analytics questions.
We'll also bring in a Welch's t-test to answer whether the free vs paid rating difference is statistically real or just noise — linking this EDA to the hypothesis testing foundations from the Statistics track.
Python (in browser)
The cleaned DataFrame: all columns are numeric, dtypes are correct, and we intentionally left 5 missing ratings to practise `.dropna()` in the groupby analyses. This is the starting state for all EDA in this lesson.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Python (in browser)
`df['Category'].value_counts()` counts occurrences per category. The bar chart surfaces category dominance — a finding that directly shapes model strategy: more data in a category means the model will generalise better for that cohort.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Python (in browser)
`df.groupby('Category')['Rating'].mean().sort_values()` — the groupby pattern in one line. The dashed overall-mean line turns the bar chart into a 'above/below average' comparison, which is instantly readable.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Python (in browser)
`scipy.stats.ttest_ind(free, paid, equal_var=False)` runs Welch's t-test — the variant that does NOT assume equal variances, which is safer when group sizes differ. The p-value answers: 'is the mean difference larger than sampling noise?'
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Python (in browser)
Scatter of `log10(installs)` vs `Rating` coloured by `Type` — three dimensions in one chart. `np.log10()` compresses the install range from [10K, 1M] to [4, 6], making the scatter readable. The Pearson correlation quantifies the strength of the relationship.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
The EDA-to-modelling bridge: every surprising chart generates a hypothesis; every confirming chart generates a feature. The groupby patterns become interaction terms. The cleaned, engineered X is what model.fit() receives.
You see paid apps have mean rating 4.2 and free apps 4.0 (n=20 each, std≈0.5). Is that difference likely 'significant'?
- The universal EDA pattern is `df.groupby(X)[Y].agg()` — 'for each cohort X, summarise metric Y'. This single pattern covers 80% of product analytics questions and maps directly to SQL `GROUP BY`.
- Bringing in a statistical test (Welch's t-test, χ²) during EDA answers 'is this difference real or noise?' before you commit to modelling — saves weeks of building a model around a spurious signal.
- Every EDA chart generates either a hypothesis (something surprising to test) or a feature (something confirming to engineer). Write both lists before opening a modelling notebook.
- Statistical significance ≠ practical significance. A 0.2-star difference between Free and Paid apps may be real (p < 0.05) but irrelevant to a recommendation engine that only shows 4.5+ apps.
Every product analytics team runs this exact play: aggregate by cohort, plot, statistical test, hypothesis-generate. ML modeling sits ON TOP of this layer, not instead of it.
If you remove it: You'd ship a churn model that learns 'recent users churn less' — a tautology your EDA would have caught in 30 seconds.