DoorDash Senior Data Analyst Interview Preparation Guide

Clarifying questions

• Which specific "conversion" metric do you mean (purchase rate, sign-up, trial->paid, funnel step)?
• Which segment/s (all users, new vs returning, geo, channel, device, cohort)?
• Exact baseline: which week is "last week" and what comparison period do you want (previous week, same week last month, 4-week average, seasonal baseline)?
• Is this overall site/app or a particular flow/page/campaign?
• Any product changes, experiments, releases, or marketing campaigns deployed in that window?
• Are there known data quality issues, tracking changes, or outages?
• How fast do you need results and what format (slide deck, dashboard, SQL + notebook)?

Stakeholders to involve

• PM (requester) for business context and priority
• Product/Engineering for releases and telemetry changes
• Marketing for campaign timing and spend shifts
• Analytics/Tracking owner for event schema or instrumentation changes
• Customer support/ops for incident reports

Data sources

• Event/BE logs (clicks, conversions), data warehouse (user, orders tables)
• A/B test platform, release/deploy calendar, marketing analytics (ad platforms), CDN/infra monitoring, error logs, customer complaints

Metric definitions

• Precise numerator and denominator (e.g., conversions = purchases post-checkout; rate = purchases / sessions or unique users)
• Attribution rules (last-click? session-based?)
• Filtering rules (bots, internal traffic)

Time windows & granularity

• Primary window: last week (Mon–Sun) vs previous week and vs 4-week rolling mean
• Daily/hourly granularity for anomaly detection; cohort lookback for retention effects

Acceptable assumptions

• If instrumentation gaps exist, state assumptions (e.g., assume no major tracking loss if infra logs show uptime >99.9%)
• Use sessions as denominator if user IDs unknown, but note bias

What success looks like

• Clear, reproducible explanation for the drop: root cause identified (e.g., campaign paused, checkout error, tracking bug, traffic mix shift) with evidence and metrics
• Actionable recommendations and next steps (rollback, fix, deeper analysis)
• Deliverable: short executive summary + supporting dashboard/queries and reproducible notebook/SQL within agreed SLA.

Direct answer

Beyond CUPED (using a pre-experiment covariate to residualize the outcome), the two other standard variance-reduction levers are stratified (blocked) randomization, which forces balance on a known factor at assignment time instead of hoping random chance balances it, and covariate or regression adjustment, which is the general case of "adjust for a predictive covariate" that CUPED is one specific, pre-experiment-only instance of. Both work by removing a source of outcome variance that is not related to treatment, so the same true effect becomes easier to distinguish from noise; both reduce required sample size roughly in proportion to how much outcome variance the factor explains, and neither invents a new number, they trade a known, explainable source of variance for a smaller residual.

Structured elaboration

Stratified (blocked) randomization

Instead of randomizing the whole population as one pool, split the population into strata on a factor known before assignment (country, device type, new vs. returning user), then randomize independently within each stratum so each arm gets a matched share of every stratum. This removes between-stratum variance from the treatment-effect estimator's variance, because the strata are balanced by design rather than by luck: with plain randomization on a highly imbalanced population, an unlucky split (e.g., treatment skewing toward the low-baseline country) inflates the observed variance of the effect estimate even though the true effect is unaffected.

It is applicable whenever you have a discrete, pre-assignment factor that is known to correlate with the outcome and is stable at randomization time. It differs from covariate adjustment in when the correction happens: stratification acts at assignment time (balance is enforced), while regression adjustment acts at analysis time (balance is estimated and subtracted after the fact). The two are complementary, not substitutes: stratify at assignment for the factors you can, and adjust for continuous covariates at analysis.

Covariate / regression adjustment

This is the general technique of fitting a model for the outcome on one or more covariates (not restricted to pre-experiment-only, unlike CUPED) and using the model to remove predictable variance from the outcome before comparing arms, most simply via ANCOVA (analysis of covariance), a linear regression of $Y$ on the treatment indicator and covariates that removes the variance those covariates explain from the comparison, the same variance-reduction logic as CUPED and stratification, just carried out as a regression rather than a pre-experiment covariate or a balanced split. It is applicable whenever you have covariates, pre-experiment or otherwise as long as they cannot themselves have been affected by treatment, that are predictive of the outcome. CUPED is the special case where the covariate is restricted to a pre-experiment value of the outcome metric itself; regression adjustment generalizes this to any number of eligible covariates and lets you combine several weak predictors into one stronger adjustment.

Effect on sample size and power

For both techniques, if the factor being controlled for explains a fraction $R^2$ of the outcome's variance, the variance of the treatment-effect estimator shrinks by roughly that same factor, and required sample size for a fixed target precision shrinks proportionally, since sample size for a fixed effect and power scales with the variance of the metric. A factor that explains little of the outcome variance buys little; a strong, well-chosen factor can meaningfully shorten the required test duration for the same statistical bar.

Worked example: stratifying a multi-country test

A test is planned across three countries with very different baseline conversion rates: Country A at 4%, Country B at 12%, Country C at 22%, in roughly equal traffic shares (each about one third of total users). Without stratification, plain randomization can by chance send more of one country's traffic to one arm, and even without that bad luck, the pooled outcome variance includes the between-country spread of baseline rates as extra noise the estimator has to average out.

Using the law of total variance, the overall variance of the outcome decomposes as:

$\operatorname{Var}(Y) = \underbrace{\mathbb{E}\big[\operatorname{Var}(Y \mid \text{country})\big]}_{\text{within-country variance}} + \underbrace{\operatorname{Var}\big(\mathbb{E}[Y \mid \text{country}]\big)}_{\text{between-country variance}}$

Stratifying by country and analyzing as a weighted average of within-country treatment effects removes the second (between-country) term from the treatment-effect estimator's variance, since each stratum is separately balanced and the between-stratum spread no longer contributes noise to the comparison. Concretely: with baseline rates of 4%, 12%, 22% and equal stratum weights, the between-country component of variance is

$\bar p = \frac{0.04+0.12+0.22}{3} = 0.1267$

$\operatorname{Var}(\bar p) = \frac{1}{3}\Big[(0.04-\bar p)^2 + (0.12-\bar p)^2 + (0.22-\bar p)^2\Big] = \frac{1}{3}(0.00751 + 0.0000445 + 0.00871) = 0.00542$

That 0.00542 is exactly the between-country variance component the stratified analysis removes from the pooled estimator's variance, computed directly from the three stated baseline rates, not asserted; how large a share of total variance that is depends additionally on the within-country binomial variance at each rate, which you would combine with this term using the same decomposition to get the full picture before quoting an overall percentage reduction.

Implementation for the multi-country case

• Assign the stratum at randomization time using the same deterministic hash-bucketing approach as the overall unit assignment, but nest it: hash within each country separately (or include country in the hash key) so each country independently hits its target split ratio.
• At analysis time, estimate the treatment effect within each country and combine as a weighted average (weighted by stratum size or by inverse variance), rather than pooling raw counts across countries, which is what actually realizes the variance reduction shown above.

Trade-offs and pitfalls

• Stratifying on too many dimensions at once shrinks individual strata until some contain too few units to balance meaningfully, and can create empty or near-empty cells, especially when crossing multiple categorical factors (country times device times cohort).
• A stratification factor chosen because it is convenient rather than because it is predictive buys little variance reduction while adding real implementation complexity; check the factor's explanatory power on historical data before committing the assignment pipeline to it.
• Regression adjustment on covariates measured close to, but not strictly after, the treatment start needs the same scrutiny as CUPED's pre-experiment-only requirement: any covariate that could plausibly be influenced by treatment invalidates the adjustment's unbiasedness, not just its efficiency.

Direct answer
The conversation matters less than the sequence: separate stabilizing the consequence from the coaching conversation, then run the retrospective as blameless (focused on the system and process, not the individual) so the mentee stays engaged rather than defensive, and turn what's learned into a durable safeguard, not just a one-time talk.

Sequence: stabilize, then convene

• First, contain the actual consequence, ideally with the mentee involved rather than sidelined; solving it together protects both the outcome and their sense of ownership.
• Only after that, run the retrospective. Doing it while still firefighting mixes urgency with reflection and makes the mentee defensive.

The blameless postmortem as the concrete framework

• Ground rules stated up front: the goal is understanding the system and sequence of events, not assigning blame to the individual who happened to be the one who made the change.
• A neutral facilitator, or a rotating one across the team so it isn't always the same person in that role, helps keep the conversation from drifting toward blame, especially when the mentor is also the mentee's manager.
• Reconstruct a factual timeline first, before any discussion of what should have happened differently; jumping to "here's what you should have done" before the facts are laid out reads as judgment, not diagnosis.
• Sensitive details (who wrote the specific line, private context) get anonymized in the written artifact where possible, since the point is the process, not the person.
• The output is a written root-cause artifact with concrete action items, not just a conversation that ends when the meeting does.

Coaching the mentee specifically

• Ask them to walk through their own reasoning at each decision point, rather than you narrating what went wrong; this builds their own diagnostic skill for next time instead of just transmitting your conclusion.
• Separate the mistake from their competence explicitly, out loud; the message is "the system let this happen too easily," not "you're bad at this."

When the mistake isn't just one person's

• Sometimes the visible consequence comes from multiple people's individually reasonable changes interacting badly (a cross-team or cascading failure), not one person's error. The blameless frame matters even more here: the postmortem needs to surface the interaction, not scapegoat whichever team's change happened to be the trigger. The coaching conversation with your mentee shifts from "what would you do differently" to "how do you think about the blast radius of a change you don't fully control," since the lesson is about system boundaries, not individual judgment.

Worked example
A mentee I was supporting shipped a change that caused a visible, customer-facing issue. The first move was working alongside them to stabilize it, not taking over and pushing them out of the loop. Once it was stable, I ran a blameless postmortem with the mentee, a couple of the affected team members, and a neutral facilitator: we built a timeline from logs and commits before discussing anything about what should have happened, and the mentee walked through their own reasoning at each step rather than me presenting conclusions.

The root cause turned out to be a gap in the pre-merge checks, not a lapse in the mentee's judgment; the change was reasonable given what the tooling surfaced at the time. The written follow-up had concrete items (a new check added to the pipeline, an update to the review checklist) rather than just "be more careful." A few weeks later, in a separate incident, another engineer's change was caught by that new check before it shipped, which is the kind of signal that the fix generalized rather than just patching one person's blind spot.

Trade-offs and pitfalls

• The common junior mistake is either being too harsh in the moment (public correction, visible frustration), which teaches the mentee to hide mistakes next time, or being too soft and skipping the structured retrospective entirely, which loses the systemic fix.
• Blameless doesn't mean consequence-free; if the pattern repeats after a genuine fix and support, that's a different, harder conversation about capability or fit, not a postmortem.
• Anonymizing sensitive details in the artifact protects psychological safety (people's sense that they can admit a mistake without fear of punishment), but overdoing it (scrubbing so much nobody can learn the specific mechanism) makes the postmortem useless as a teaching tool. The balance is protecting the person while keeping the mechanism specific.

Approach: define primary success metrics (conversion, time-to-complete) and safety guardrails tied to fraud signals. Use historical baselines, statistical significance, and both absolute and relative thresholds; monitor with daily/weekly windows and automated alerts plus escalation playbook.

Guardrail metrics (with thresholds and rationale):

1. Chargeback rate (chargebacks / settled orders) — Alert if > 0.5% absolute OR +50% relative vs baseline week for 3 consecutive days.
   Rationale: chargebacks are high-cost, lagging fraud signal. Use both absolute and relative to catch spikes from low-baseline categories.

2. Fraud acceptance rate (confirmed frauds / approved orders) — Alert if > 0.2% absolute OR +3σ above 30-day rolling mean.
   Rationale: direct measure of fraudulent approvals; sigma-threshold reduces false alarms from noise.

3. New-account purchase conversion & fraud mix — Alert if new-account conversion increases >30% while new-account fraud share >25% of total fraud for 7 days.
   Rationale: simplified flow may be abused by fake accounts; combining conversion and fraud share avoids punishing healthy growth.

4. Velocity anomalies (payments per IP/device per hour) — Alert if count from a single IP/device > 10x historical 95th percentile or sudden increase in distinct cards per IP.
   Rationale: automated attacks show high velocity; percentile-based threshold adapts to normal variability.

Implementation notes: backtest thresholds over historical A/B-split data, apply segmentation (country, payment method), surface alerts in dashboards + Slack, and require immediate rollback criteria (e.g., chargeback or fraud acceptance breach sustained for 72 hours).

Direct answer

For an online marketplace, the platform's own revenue is gross merchandise value (GMV, the total value of transactions flowing through the platform) multiplied by the take rate the platform keeps as commission; GMV itself decomposes into how many customers are active, what share convert, how much they spend, and how often. Each term in that chain has its own measurement approach and its own way of quietly going wrong.

Structured elaboration

$\text{Platform Revenue} = GMV \times \text{Take Rate}$
$GMV = N_{active} \times CR \times AOV \times F$

where $N_{active}$ is active customers, $CR$ is conversion rate, $AOV$ is average order value, and $F$ is purchase frequency over the period. Separating platform revenue from GMV matters specifically for a marketplace: the buyer's total spend and the platform's actual take are different numbers, and conflating them overstates what the business itself earns.

Worked example

Suppose, for one period: 10,000 active customers, a 4% conversion rate, $60 average order value, and 1.5 orders per active customer.

$GMV = 10{,}000 \times 0.04 \times \$60 \times 1.5$

Working left to right: $10{,}000 \times 0.04 = 400$ converting customers; $400 \times $60 = $24{,}000$; $$24{,}000 \times 1.5 = $36{,}000$.

$GMV = \$36{,}000$

If the platform's blended take rate on this category is 15%:

$\text{Platform Revenue} = \$36{,}000 \times 0.15 = \$5{,}400$

The buyers collectively spent $36,000 through the marketplace, but the platform itself only earned $5,400 of that; a decomposition that stops at GMV and calls it "revenue" overstates the business's actual earnings by more than six times in this example.

Trade-offs & pitfalls

The multiplicative decomposition assumes the four GMV terms move independently, but they often do not: a promotion that raises conversion rate frequently lowers average order value at the same time (customers converting on smaller, promo-priced baskets), so a healthy-looking conversion number can mask a shrinking GMV if AOV is not checked in the same breath. Take rate is the term most often left out of a customer-facing decomposition entirely, which is the core risk for a marketplace specifically: reporting buyer GMV growth as if it were platform revenue growth misrepresents the business, especially when take rate itself is drifting down due to a mix shift toward lower-commission categories or negotiated seller discounts. Finally, purchase frequency and active-customer counts both depend on identity resolution; if that resolution logic changes (a new login system, say), every term in the decomposition can shift for reasons that have nothing to do with real buyer or seller behavior.

On the sample [50, 55, 60, 5000], neither the IQR rule (1.5 times IQR beyond Q1/Q3) nor a Z-score threshold of 3 actually flags 5000 as an outlier, which is a useful lesson on its own: both rules can miss an obvious outlier when the sample is this small, because a single extreme value distorts the very statistics (IQR, mean, standard deviation) used to detect it. The bigger practical point is that the mean (1291.25) is not a trustworthy summary of this data, while the median (57.5) is.

Structured elaboration

Method 1: IQR rule

Sort the data, split into halves, and take the median of each half as Q1 and Q3:

$IQR = Q_3 - Q_1$
$\text{outlier if } x < Q_1 - 1.5\,IQR \ \text{ or } \ x > Q_3 + 1.5\,IQR$

Method 2: Z-score

$z = \frac{x-\bar x}{s}$

flag any point with the absolute value of z at least 3 (using the sample or population standard deviation; both are shown below, and they agree on the conclusion here).

Worked example

Data sorted: [50, 55, 60, 5000].

IQR rule:

• Q1 = median(50, 55) = 52.5
• Q3 = median(60, 5000) = 2530
• IQR = 2530 - 52.5 = 2477.5
• Bounds: [52.5 - 1.5(2477.5), 2530 + 1.5(2477.5)] = [-3663.75, 6246.25]
• 5000 is inside [-3663.75, 6246.25], so the IQR rule does not flag it.

Z-score rule:

• Mean = (50+55+60+5000)/4 = 1291.25
• Population standard deviation is about 2141.25 (sample standard deviation is about 2472.50)
• z(5000) = (5000 - 1291.25) / 2141.25, which is about 1.73 with the population standard deviation, or about 1.50 with the sample standard deviation
• Neither exceeds the threshold of 3, so the Z-score rule with threshold 3 also does not flag it.

(all values verified with python3's statistics module: mean 1291.25, population standard deviation 2141.25, sample standard deviation 2472.50, z(5000) with population standard deviation is 1.732)

Both rules fail here because n = 4 is far too small for either method's underlying assumptions. Q3 itself is contaminated by the outlier since it is the median of {60, 5000}, and the mean and standard deviation are both dragged upward by the same point that inflates them, making the z-score understate its own extremity.

Impact on mean vs median, and remediation

• Mean (1291.25) is wildly unrepresentative: it is more than 20 times any of the other three values.
• Median (57.5) reflects the typical value well and is unaffected by 5000's magnitude, only its rank.
• Remediation: investigate 5000 first (a data entry error versus a genuinely high-value customer). If it is legitimate but unrepresentative for a "typical revenue per user" metric, report the median or a trimmed mean alongside the full mean, or winsorize (cap) extreme values above a chosen percentile, and call out large accounts separately rather than letting them silently dominate an average.

Trade-offs & pitfalls

• Both rules are much less reliable at small n; with only 4 points, one extreme value can shift Q3 or the standard deviation enough to mask itself. Neither rule "failing" here means the value is not actually anomalous. It means the tools were not built for n = 4.
• The IQR rule is robust to the outlier's magnitude (it depends on ranks) but not to a small sample where the quartiles themselves are computed from very few points.
• The Z-score rule is directly vulnerable to the outlier: the outlier itself inflates the standard deviation used to judge it, which can hide even large true outliers (masking).
• Silently dropping a flagged, or even an unflagged but suspicious, value without investigating whether it is a data error or a real, important case risks deleting real signal (a legitimate enterprise customer) rather than noise.

A JSON payload column being slow for ad-hoc queries usually means the engine has to parse and traverse the semi-structured value for every row on every query that reaches into it, work that a typed, columnar layout would have already done once at write time; the fix generally means moving that parsing cost from query time to write time, at whatever level of commitment the workload can tolerate.

Schema-on-read versus schema-on-write

Schema-on-read (the current state, presumably) keeps the flexibility to store any JSON shape without an upfront schema decision, at the cost of every query paying the JSON-parsing overhead fresh, and getting no benefit from columnar compression or predicate pushdown (the engine applying a WHERE filter down at the storage layer, skipping unneeded data before it is even read into memory, instead of reading everything into memory and filtering afterward) on the fields buried inside the payload, since the storage layer only sees one opaque blob column, not the individual fields within it. Schema-on-write commits to a known structure ahead of time, letting the engine store and compress each field independently and apply the same pushdown/pruning optimizations to them as any other column, at the cost of needing to know (and re-migrate, if it changes) the schema in advance.

Extracting frequently-used fields into derived columns

A middle ground: identify the specific JSON fields that ad-hoc queries actually filter or aggregate on most often (from query logs), and materialize just those as proper typed columns alongside the original JSON blob, computed once at write time (or as a scheduled backfill/incremental job). Queries touching only those hot fields get full columnar-storage benefits; queries needing a rarely-accessed field can still fall back to parsing the original JSON blob, so you are not forced to fully commit to a schema for fields nobody queries yet.

Converting to Parquet with explicit typed columns

For a payload whose shape has genuinely stabilized, converting it fully into explicit typed Parquet columns (via a nightly or streaming transformation job) gets the full benefit, columnar compression, predicate and projection pushdown, statistics-driven pruning, on every field, not just the hottest ones, at the cost of committing to that schema and needing a migration path whenever the JSON payload's shape legitimately evolves.

Trade-offs and pitfalls

The derived-columns approach is attractive because it is incremental and low-risk (nothing about the original JSON blob's flexibility is lost), but it can accumulate an ever-growing set of ad-hoc extracted columns if nobody periodically reviews which ones are still actually used, becoming its own maintenance burden. A full Parquet conversion is the most performant long-term answer but is the wrong first move for a payload whose shape is still actively evolving, since a schema migration on every shape change can become more disruptive than the JSON-parsing cost it was meant to eliminate; match the level of commitment to how stable the payload's shape actually is.

In the first week, I would focus on protecting the launch while testing whether the plan is still realistic.

Day 1 and 2: I would get the facts. What is late, what is truly on the critical path, and which milestones depend on the partner. I would also ask for a written status update so there is one shared view of the problem.

Day 3 and 4: I would reset alignment with the partner and internal leaders. I would make the risk visible, propose a recovery plan, and define what needs to happen by when. If needed, I would narrow scope, add internal backup work, or create a phased launch so the entire roadmap is not blocked by one dependency.

Day 5: I would decide whether the original date is still credible. If the partner has recovered, I keep the plan. If not, I recommend a revised timeline with clear trade-offs, rather than hoping the delay disappears.

The key is to avoid passive waiting. Even without direct authority, I can protect the launch by clarifying ownership, escalating early with options, and keeping leadership informed with facts instead of optimism.

For example, in a case like this, the launch depended on a third-party payments provider delivering a new API endpoint that a checkout redesign needed to go live. On Day 1, the written status update from the vendor's account manager revealed the endpoint was not late by a day or two, it was still in the vendor's own internal QA with no committed date, three weeks past their original commitment. By Day 3, resetting alignment meant a joint call with the vendor and internal engineering leadership where the risk was made explicit: without the endpoint, the full checkout redesign could not ship on the original date. The recovery plan split the work: internal engineering built a fallback that used the vendor's existing, older endpoint for most transaction volume, while the new endpoint's remaining edge cases, a smaller set of international payment methods, were scoped out of the initial launch and phased in once the vendor delivered. On Day 5, the vendor still had no firm delivery date for the new endpoint, so the recommendation was to launch on the original date with the phased fallback rather than slip the whole roadmap, with a follow-up launch for the remaining payment methods once the vendor's endpoint actually shipped.

Direct answer

In a regulated industry the story changes in three ways before you ever open a slide deck: what you're allowed to show gets filtered by regulation first, every number needs a documented trail back to its source, and the audience usually includes someone whose job is to say no. The craft is presenting a defensible, compliant insight that is still genuinely persuasive, not a watered-down one.

Structured elaboration

1. Filter the insight through the regulatory constraint before you design the story.
Start by asking what you are legally or contractually allowed to surface, not what would make the best slide. In healthcare this typically means de-identification requirements in the style of HIPAA (the Health Insurance Portability and Accountability Act, the US healthcare privacy law) (removing or generalizing direct identifiers, applying k-anonymity style aggregation so no small cell size can be re-identified); in finance it often means restrictions on disclosing individual customer positions, fair-lending constraints on which variables can drive a decision, and model-risk-management documentation requirements. The constraint is not a formatting afterthought, it determines which findings you can even lead with. A finding that is only compelling at the individual-customer level may need to be re-cut at a cohort or segment level to be shshowable at all.

2. Choose an anonymization or aggregation method proportionate to the risk, and say so explicitly.
Common options, roughly in order of how much detail they preserve: generalization/binning (age becomes a 10-year band), suppression of small cells (any group below a stated threshold, for example n<10, is not reported individually), k-anonymity (restructuring the data so every individual is indistinguishable from at least k-1 others) or differential privacy (adding carefully calibrated statistical noise so no single record can be reverse-engineered from the released numbers) for released datasets, and full aggregation to segment or cohort level for anything leaving the compliance boundary. State which one you used and why in the deck itself, not just in a footnote; a compliance-literate audience will ask, and pre-empting the question builds trust.

3. Build the documentation trail the regulator or auditor would expect.
At minimum: a data lineage note (where the data came from, what was excluded and why), the exact aggregation/anonymization method applied, the population definition, and any known limitations or exclusions. In a bank this is close to what model-risk-management documentation already requires; in healthcare it is close to what a compliance or privacy officer would ask for before approving external use of a dataset. Producing this alongside the insight, not after someone asks for it, is what separates a defensible story from an accidental disclosure.

4. Present the compliance-versus-insight trade-off to the executive directly, instead of hiding it.
An executive who wants the fuller, more granular picture needs to understand that the constraint is not analyst caution, it is a hard requirement with real penalties for the organization. Frame it as: here is the insight we can show at the compliant aggregation level, here is what more granular view would add, and here is why we cannot show that view without additional legal/privacy sign-off (and what that sign-off would require, e.g., a data use agreement, approval from an institutional review board (the ethics body that approves research involving people's data), legal review). This turns a limitation into a scoped, honest recommendation rather than a vague 'we can't share that.'

Worked example

A healthcare analytics team wants to show a hospital system that a proposed care-pathway change reduces 30-day readmissions. The raw finding is a 2.1 percentage point reduction (from a baseline of 15.0% to 12.9%) in a cohort of 640 patients. Because the cohort includes some very small subgroups (for example, a specific rare-diagnosis subgroup of 6 patients), the team cannot report readmission rates by that subgroup without violating a small-cell suppression rule (commonly a minimum reportable cell size, e.g. n>=11, used across many healthcare reporting standards). The story that ships: the top-line reduction at the full-cohort level (which is well above the suppression threshold and safe to report), a note that subgroup-level results are directionally consistent but suppressed below n=11 per data governance policy, and an explicit statement that a follow-up analysis with a larger sample is planned before subgroup-level claims can be made. The executive sees the real result, understands exactly why the subgroup cut is withheld, and knows what it would take to get it.

Trade-offs and pitfalls

• The biggest pitfall is aggregating so heavily to stay 'safe' that the insight becomes too vague to act on; the discipline is finding the least aggregated view that is still compliant, not the most conservative one available.
• A second common mistake is treating the regulatory constraint as something to mention once in an appendix; a compliance-savvy stakeholder will judge you on whether the constraint shaped the analysis from the start, not whether you disclosed it at the end.
• Do not let 'the regulation requires it' become an excuse for skipping normal storytelling discipline (headline, evidence, recommendation); the compliant version of the insight still needs to lead with the so-what, it just has a narrower evidentiary base.
• When in doubt about whether a cut of the data is disclosable, the right escalation path is your privacy/compliance/legal function, not an individual judgment call, and that escalation itself is worth naming as part of your process when a stakeholder pushes for more granularity.

An in-warehouse transformation tool like dbt gives you three things a scheduled cron script does not: version-controlled, testable SQL; a dependency graph the tool builds and executes for you; and documentation that stays attached to the code instead of living in a separate wiki.

Concretely, what you get

1. Modularity and dependency management. Each model is a .sql file that references other models with ref(). dbt parses those references into a DAG (directed acyclic graph) and runs models in the right order automatically, so you never hand-maintain "run script B after script A finished."
2. Testing as a first-class citizen. You declare assertions in YAML next to the model (uniqueness, not-null, accepted values, referential integrity to another model) and dbt runs them as part of the pipeline, not as an afterthought someone has to remember to write.
3. Documentation and lineage for free. dbt generates a browsable docs site from your model definitions and column descriptions, and a lineage graph showing exactly what feeds what. A cron-scheduled SQL script has none of this unless someone builds it by hand and keeps it in sync.
4. Git-native change management. Because everything is plain text SQL and YAML, you get code review, branching, and CI the same way you would for application code, which a stored procedure buried in a scheduler typically does not.

Where this actually helps day to day
A change to an upstream source column shows up as a broken test or a documented lineage edge before it silently corrupts three downstream marts. Onboarding a new analyst is "clone the repo and read the docs site" instead of "ask around for who owns which script." A bad model can be reverted with git revert instead of hand-reconstructing what the SQL used to say.

What it does not replace
dbt only transforms; it does not extract or load data (you still need a connector or CDC (Change Data Capture) tool to get data into the warehouse), and it does not orchestrate anything outside the warehouse (you still need something like Airflow to trigger dbt run on a schedule and coordinate it with non-dbt tasks).