The Data Science Workflow

The most common source. You write SQL against tables a data engineering team maintains — this is exactly why the SQL track pairs so well with this one.

Some data only exists behind a service endpoint, not yet in the warehouse. You fetch it programmatically and cache a snapshot for analysis.

Click and watch events often land first as raw JSON logs before any pipeline structures them — you may need to parse them yourself.

Less glamorous, extremely common. Always the least trustworthy source — verify column meanings before assuming anything.

One sentence and one number: "Premium cancellation is 18% higher than Basic, based on 25 subscribers — worth a deeper look before we conclude anything."

The chart, the caveat about sample size, and one concrete recommendation: run an A/B test before changing Premium pricing.

The full notebook, the exact filters applied, and the statistical test used to validate the finding.

A trained, serialized model plus the exact features and preprocessing steps, ready to wire into a production service.

Before writing any code, I would clarify the request into a precise, answerable question. "Engagement" is ambiguous — it could mean daily active users, session length, content completion rate, or repeat visits. I would ask what specific metric they care about, over what time window, and compared against what baseline (last month, a specific cohort, a competitor benchmark).

Once I have a precise version — for example, "did the percentage of Premium subscribers who watched at least one title in the last 7 days change after the pricing update?" — I know exactly which tables and columns I need, what the expected output looks like, and what would count as an interesting versus uninteresting result.

Skipping this step is the most common cause of wasted analysis work — building a thorough report that answers a question nobody actually asked, because the original request was never made precise.

Exploratory analysis is the discovery phase — looking at distributions, running groupbys, and generating hypotheses about patterns that might be present in the data. It is intentionally open-ended and is expected to surface both real signals and coincidental noise.

Validation is the confirmatory phase — taking a specific pattern found during exploration and testing, using statistics, whether it is likely to be real rather than due to chance or a small sample. This typically means checking sample sizes, running a hypothesis test, and considering whether the pattern would replicate on a held-out or future dataset.

The common mistake is treating an exploratory finding as validated fact without doing the second step — reporting the first interesting-looking groupby result as if it were a proven conclusion, when it has not yet been tested for statistical significance or checked against sample size.

Without a predefined success metric, it is easy to unconsciously search through many possible cuts of the data until one shows an interesting-looking pattern, then present that cut as the finding — a statistical error sometimes called p-hacking or data dredging. If you define the exact metric and comparison you are testing before looking at results, you avoid this bias.

It also makes the eventual result immediately actionable. If the agreed success metric for a feature launch was "7-day retention increases by at least 2 percentage points," the result is a clear yes or no. Without that predefined bar, any result can be spun as a success after the fact, which erodes trust in the analysis over time.

In practice, this means agreeing on the metric and the threshold for success with stakeholders during the framing stage — Stage 1 of the workflow — not after the results are already in hand.

A groupby and chart is the right tool when the question is descriptive — "what happened, broken down by category?" For example, "what is the average watch time per device type?" is fully answered by grouping watch_history by device and taking the mean. No model adds value here because nothing is being predicted about an individual, unseen case.

A model is the right tool when the question is genuinely predictive about individual future cases — "will this specific subscriber cancel next month?" cannot be answered by a groupby, because it requires estimating a probability for one new individual based on patterns learned across many past individuals. That requires a trained classification model, covered starting in Module 47.

A common junior mistake is reaching for a model when a groupby would answer the question just as well and be far easier to explain and maintain — model complexity should be justified by the question's actual need for individual-level prediction, not used as a default.

I lead with the finding in plain language, immediately followed by the confidence level in equally plain language — for example, "Premium subscribers are cancelling about 18% more than Basic subscribers this quarter. This is based on a reasonably large sample and is unlikely to be random noise, but it's correlational — we have not yet tested what happens if we change anything about Premium."

I avoid two failure modes. The first is hiding uncertainty entirely to sound more confident, which leads to decisions made on shakier ground than the stakeholder realizes. The second is burying the actual finding under so much statistical caveat that the stakeholder cannot extract an actionable takeaway at all.

The right balance is usually: the finding, one sentence of confidence context in plain terms (not p-values or confidence interval math), and — when relevant — a concrete next step like running a controlled experiment before committing a large decision to the finding.

Cause: You filtered a DataFrame into a new variable, then tried to modify a column on that filtered result. Pandas cannot always tell whether your filtered variable is an independent copy or a view into the original data, so it warns you that the modification may silently not do what you expect.

Fix: Add .copy() immediately after filtering, before modifying: premium = users[users['plan'] == 'Premium'].copy() — then premium['flag'] = True works safely and unambiguously. This is one of the most common warnings in real pandas work and is almost always fixed the same way.

Cause: The column you are merging on has a different data type in each DataFrame — for example, user_id is stored as text in one table and as a number in the other, often because one table was loaded from a CSV that quoted the IDs.

Fix: Check the dtype on both sides before merging: users['user_id'].dtype and subscriptions['user_id'].dtype. If they differ, cast one to match the other before merging: subscriptions['user_id'] = subscriptions['user_id'].astype(int) — do this once, right after loading the data, not repeatedly before every merge.

Cause: A merge or groupby was written with the column name spelled using a space instead of an underscore — 'user id' instead of 'user_id'. Pandas treats this as looking for a column that does not exist, rather than as a typo it can guess-correct.

Fix: Run df.columns.tolist() to see the exact column names, copy them exactly, and remember that StreamPulse (like almost all real data) uses snake_case with underscores, never spaces, for every column name.

Cause: You tried to convert a column to an integer type using .astype(int), but the column contains missing values (NaN). NaN is fundamentally a floating-point concept — there is no integer representation of 'missing' in NumPy's integer types, so the conversion fails outright.

Fix: Handle the missing values first — either fillna() with a sensible default or dropna() to remove those rows — before converting to int. Alternatively, use the nullable integer type: df['col'].astype('Int64') (capital I) which supports NaN values directly.

Cause: You tried to use a list as a groupby key or as a dictionary key, for example groupby(['plan', ['country']]) with an extra nested list, or accidentally passed a list where pandas expected a column name string or a flat list of column names.

Fix: Double-check the structure of what you are passing to groupby() — it should be a single column name as a string, e.g. groupby('plan'), or a flat list of column name strings for multiple keys, e.g. groupby(['plan', 'country']) — never a list containing another list.

Frame and answer this question end to end: 'Do subscribers who joined through Social Media referrals watch more content on average than subscribers who joined through Organic Search?' Merge users with watch_history, then compare average minutes_watched between the two referral_source groups.