DoorDash Business Intelligence Analyst (Mid-Level) Interview Preparation Guide

Direct answer

A workable set of signals for whether stakeholders are genuinely aligned on a long-running initiative mixes a few things people actually DO (not just what they say) with a small number of honest, qualitative check-ins, and each signal needs a stated "worrying" threshold and a concrete next step, or the exercise becomes measurement for its own sake.

Structured elaboration

1. Behavioral signals over stated sentiment. Whether stakeholders show up prepared to meetings, act on agreed decisions without re-litigating them later, and proactively surface risks rather than waiting to be asked, are stronger signals than a survey score, because behavior is harder to fake than a rating.
2. A small number of qualitative check-ins. A short, direct question asked periodically ("is there anything about this initiative you're currently worried about that hasn't come up") surfaces concerns a satisfaction score would miss, especially from quieter stakeholders.
3. Decision follow-through rate. Tracking whether agreed decisions actually get implemented as agreed, versus quietly reversed or ignored, is a concrete, checkable proxy for real alignment versus polite agreement in the room.
4. A stated threshold and action for each signal. "If more than one of the last three decisions has been quietly reversed, that's worth a direct conversation" is actionable; a dashboard of numbers with no defined action if they look bad is not.

Worked example

For a multi-quarter initiative, tracking whether the last five cross-team decisions were implemented as agreed (a concrete, checkable number) alongside a brief, honest monthly check-in question to each key stakeholder produces a more reliable read than a generic satisfaction survey. If two of the last five decisions were quietly reworked without discussion, that's a specific, actionable signal of misalignment worth a direct conversation, rather than a vague sense that "something feels off."

Trade-offs and pitfalls

Over-instrumenting this with too many metrics creates its own overhead and can feel like surveillance rather than genuine check-in; keep the signal set small, and make sure the qualitative check-ins are genuinely safe for a stakeholder to answer honestly, or they'll just produce polite, uninformative responses.

Direct answer

Split users into "before" and "after" cohorts by whether their created_at falls before or after the rollout date, then compute both 30-day retention and 30-day LTV relative to EACH user's own signup date (not a fixed calendar date), treating users with zero purchases as genuine $0 contributors to LTV via a LEFT JOIN rather than excluding them, since silently dropping non-purchasers would understate the true per-user economics of both periods.

Structured elaboration

Cohort split. period = CASE WHEN created_at < rollout_date THEN 'before' ELSE 'after' END, a single flag derived once and reused for both the retention and LTV computations, so the two metrics are computed over exactly the same two populations.

30-day retention, per user's own signup date. A user counts as retained if they have a SESSION on exactly created_at + 30 days (or, depending on the exact definition wanted, ANY session within the 30-day window; the query below uses the stricter exact-day version, and either definition should be stated explicitly).

30-day LTV, per user's own signup date. Sum of purchases.amount where purchased_at <= created_at + 30 days, divided by cohort size (not by purchaser count), so a user who never buys anything correctly contributes $0 and pulls the average down, exactly as intended for a genuine per-user LTV figure rather than an average-order-value-among-buyers number.

Handling users with no purchases. A LEFT JOIN from the cohort to purchases (not an INNER JOIN) is what makes a non-purchasing user still appear in the aggregation with a $0 contribution rather than disappearing from the calculation entirely; COALESCE(SUM(amount), 0) guards against a NULL sum for a user with zero matching purchase rows.

Worked example

Schema exactly as given, rollout date 2026-01-15. Four "before" users and four "after" users, engineered to test the exact-day-30 retention boundary and the 30-day LTV window boundary in both directions:

CREATE TABLE users (user_id INTEGER, created_at TIMESTAMP);
CREATE TABLE sessions (session_id INTEGER, user_id INTEGER, started_at TIMESTAMP, duration_seconds INTEGER);
CREATE TABLE purchases (purchase_id INTEGER, user_id INTEGER, amount NUMERIC, purchased_at TIMESTAMP);

INSERT INTO users VALUES (1,'2026-01-01'),(2,'2026-01-01'),(3,'2026-01-05'),(4,'2026-01-10'),
                          (5,'2026-01-16'),(6,'2026-01-16'),(7,'2026-01-20'),(8,'2026-01-25');
INSERT INTO sessions VALUES
 (1,1,'2026-01-31',300),   -- u1: session exactly on day 30 -> retained
 (2,2,'2026-01-02',120),   -- u2: no session near day 30 -> not retained
 (3,3,'2026-01-31',200),   -- u3: session on day 26 (not day 30) -> not retained under the exact-day definition
 (5,5,'2026-02-15',400),   -- u5: session exactly on day 30 -> retained
 (6,6,'2026-01-17',90),    -- u6: no session near day 30 -> not retained
 (7,7,'2026-02-19',250);   -- u7: session exactly on day 30 -> retained
INSERT INTO purchases VALUES
 (1,1,50.0,'2026-01-10'),(2,1,30.0,'2026-01-29'),   -- u1: $80 within 30 days
 (3,3,20.0,'2026-01-20'),                            -- u3: $20 within 30 days
 (4,5,60.0,'2026-02-01'),                            -- u5: $60 within 30 days
 (5,7,45.0,'2026-02-10'),                            -- u7: $45 within 30 days
 (6,8,90.0,'2026-03-15');                            -- u8: purchase on day 49, OUTSIDE the 30-day window

WITH params AS (SELECT date('2026-01-15') AS rollout_date),
cohort AS (
    SELECT user_id, created_at,
        CASE WHEN date(created_at) < (SELECT rollout_date FROM params) THEN 'before' ELSE 'after' END AS period
    FROM users
),
retained AS (
    SELECT c.user_id FROM cohort c
    WHERE EXISTS (SELECT 1 FROM sessions s WHERE s.user_id=c.user_id AND date(s.started_at)=date(c.created_at,'+30 days'))
),
ltv_30d AS (
    SELECT c.user_id, COALESCE(SUM(p.amount), 0) AS revenue_30d
    FROM cohort c LEFT JOIN purchases p ON p.user_id=c.user_id AND date(p.purchased_at) <= date(c.created_at,'+30 days')
    GROUP BY c.user_id
)
SELECT c.period, COUNT(DISTINCT c.user_id) AS cohort_size,
    COUNT(DISTINCT r.user_id) AS retained_30d,
    ROUND(1.0*COUNT(DISTINCT r.user_id)/COUNT(DISTINCT c.user_id), 4) AS retention_rate_30d,
    ROUND(1.0*SUM(l.revenue_30d)/COUNT(DISTINCT c.user_id), 2) AS ltv_30d_per_user
FROM cohort c LEFT JOIN retained r ON r.user_id=c.user_id LEFT JOIN ltv_30d l ON l.user_id=c.user_id
GROUP BY c.period;

Executed against SQLite. Output:

period | cohort_size | retained_30d | retention_rate_30d | ltv_30d_per_user
after  | 4           | 2            | 0.5                 | 26.25
before | 4           | 1            | 0.25                | 25.0

Before: only u1 is retained (session exactly on day 30); u3's session lands on day 26, NOT day 30, correctly excluded under the strict exact-day definition, illustrating why the definition needs to be stated precisely, a "day 26" session reads as "the user came back" informally but does not satisfy "retained AT day 30" specifically. Retention: 1/4 = 0.25. LTV: u1 contributes $80 (both purchases fall within 30 days of Jan 1), u3 contributes $20, u2 and u4 contribute $0; total $100/4 = $25.00. After: u5 and u7 both retained (sessions exactly on their respective day 30), 2/4 = 0.5. LTV: u5 contributes $60, u7 contributes $45, u8's purchase on day 49 falls OUTSIDE the 30-day window and correctly contributes $0 despite being a real purchase, u6 contributes $0; total $105/4 = $26.25.

Trade-offs and pitfalls

• The exact-day-30 retention definition used here is a real, consequential choice, not the only valid one; u3's day-26 session shows exactly how a "retained BY day 30" (any activity through day 30) definition would produce a different, HIGHER before-cohort retention rate (2/4 = 0.5 instead of 1/4 = 0.25) for the identical underlying data, so the chosen definition should always be stated alongside the resulting number.
• Comparing before/after cohorts around a single rollout date conflates the rollout's effect with ordinary calendar-time drift (seasonality, a concurrent marketing change, or simple cohort-to-cohort noise from small sample sizes); a rigorous read of "did the rollout work" needs either a genuine randomized holdout run alongside the rollout, or, at minimum, several cohorts on each side of the boundary rather than just one immediately-adjacent pair, to distinguish a real rollout effect from noise.
• An INNER JOIN to purchases instead of the LEFT JOIN shown would silently drop every non-purchasing user from the LTV calculation, inflating the reported LTV by computing it only over buyers; the deliberate LEFT JOIN plus COALESCE is what keeps the denominator honest at the full cohort size.

Situation: An upstream vendor announced deprecation of field X (used in KPI "Active Customers") in 3 months. We must migrate with minimal KPI disruption.

Plan (high level timeline — 12 weeks):

• Week 0–1: Impact analysis & stakeholder kickoff
• Week 2–4: Field mapping & validation
• Week 5–8: Parallel reporting + QA
• Week 9–10: Stakeholder signoff & switch
• Week 11–12: Monitor & rollback window

1. Impact analysis (who/what)

• Inventory all dashboards, ETL jobs, LookML/Power BI models, scheduled reports that reference field X.
• Use automated search (git, BI metadata, SQL query logs) + manual review.
• Deliverable: matrix listing dashboard name, owner, frequency, user groups, downstream consumers (data exports, ML models).

2. Mapping / fallbacks

• Work with vendor + internal data team to identify replacement Y or derived equivalence (e.g., Y + Z join).
• Define transformation logic with examples and unit tests (SQL snippets).
• If no perfect replacement, define fallback: approximate metric using existing fields (document bias/error).

3. Interim reporting strategy

• Implement dual-track reporting: continue calculating KPI with X where available, and compute alternative KPI' using Y in parallel.
• Surface both values in a “Data Migration” layer and dashboards (show KPI, KPI', delta, and confidence score).
• Add clear annotation/warning banners on executive dashboards.

4. Stakeholder notifications & timelines

• Week 1: Notify stakeholders (PMs, execs, data consumers) with impact matrix, planned timeline and risks.
• Biweekly updates and a pre-cutover reminder at Week 8 and 48-hour notice before switch.

5. Metrics to track during transition

• Coverage: % of records using original X vs replacement Y
• Drift: delta distribution between KPI and KPI' (mean, median, 95th percentile)
• Data quality: missingness, join failure rates, exception counts
• Business impact: top-line differences on downstream reports, alert on >2% deviation for KPIs

6. Rollback plan

• Maintain ability to switch visualizations back to X for 2 weeks after cutover (feature-flag or view-level switch).
• Keep historical snapshots and retain old ETL for up to 30 days.
• If replacement causes >5% business-impact deviations or data quality > threshold, revert to X and escalate to vendor for remediation. Run post-mortem and re-plan.

Responsibility matrix:

• BI Analyst (me): inventory, mapping SQL, dashboard updates, monitoring dashboards
• Data Engineering: ETL changes, feature-flag, DB views
• Product/Business Owners: signoff on KPI' acceptance
• Vendor liaison: confirm semantics and SLAs

Outcome: Minimize surprise by running parallel metrics, transparent communication, clear acceptance criteria, and a short rollback window to protect business decisions.

Requirements & constraints:

• Manage Power BI, Tableau, LookML artifacts across dev/test/prod.
• Version control, automated data & visualization tests, deploy & rollback, integrate with Git, secure secrets/service accounts, minimal disruption to business users.

High-level architecture:
Developer Git workflow (feature branches → PR → main) → CI server (GitHub Actions/GitLab CI/Bitbucket Pipelines) → automated tests → CD orchestrator (Argo CD/Octopus/ custom scripts) → environment-specific artifact stores (Power BI workspace, Tableau Server/Cloud projects, Looker projects) → monitoring & rollback.

Core components and responsibilities:

1. Git repo(s): store pbix/parameters, Tableau TWB/TDSX or workbook XML exports, LookML files. Use one mono-repo or per-tool repos with consistent branching policy and protected main branches.
2. CI (GitHub Actions): on PR run:
   • Lint LookML, validate Tableau XML schema, check pbix metadata.
   • Run unit/data tests: dbt tests or SQL-based row-counts, schema checks against dev database.
   • Visualization tests: use Snapshot testing (Selenium/Playwright + image diffs) or Assertive tests (check presence of fields, filters, no broken queries).
3. CD: on merge to main:
   • Deploy to dev workspace automatically; run integration tests against dev data.
   • Manual approval gates for test → prod (use pull-request or environment approvals in CD tool).
   • Deployment steps: push LookML via Looker API/git integration; publish Tableau workbook via Tabcmd/REST API to target project; publish Power BI via Power BI REST API/PowerShell (upload dataset, set parameters, refresh).
4. Rollback:
   • Maintain release tags and artifact snapshots in Git and artifact storage.
   • CD tool supports "promote previous tag" or re-deploy earlier commit; for Power BI/Tableau, use API to republish previous file and trigger refresh; for Looker, git revert & deploy.
5. Secrets & service accounts:
   • Use vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) integrated with CI/CD. CI uses short-lived tokens; never store creds in repo.
   • Create least-privilege service accounts for APIs with scoped permissions per environment. Rotate keys regularly and use OIDC where supported (GitHub Actions OIDC to Azure AD).
6. Observability & testing feedback:
   • Log deployments, test results, dataset refresh history.
   • Alerts for failed refreshes, schema drift, visual regressions.
     Trade-offs:

• Image diff visual tests catch layout regressions but are brittle; combine with DOM/assertion tests.
• Full automation to prod increases speed but requires strong approval/gating for exec dashboards.

This pipeline balances reproducibility, test coverage, and safe deployments for BI artifacts.

1. Reflective/paraphrasing: after a stakeholder explains a need I restate it in my own words (e.g., “So you want a weekly executive view of LTV by cohort with ability to filter by region — is that right?”). This surfaces misunderstandings immediately and keeps the conversation aligned.

2. Task-based probing and scenarios: I ask them to walk me through how they’d use the report (decisions they’ll make, frequency, who will act). Example prompts: “Show me the exact steps you’d follow to investigate a drop in revenue,” or “What cutoff would trigger an escalation?” This reveals required dimensions, granularity, refresh cadence, and edge cases.

3. Visual prototypes and sample outputs: I sketch a mock dashboard or produce a quick wireframe/sample dataset in Power BI/Tableau so stakeholders see concrete outputs. Visuals force precise requirements (e.g., chart types, sorting, drilldowns).

Validation approach:

• Immediate read-back and capture: summarize acceptance criteria live and confirm (agree on KPIs, time windows, filters).
• Written requirements & examples: send a one-page spec with mock screenshots, field-level definitions, and sample SQL or data dictionary; ask for explicit sign-off.
• Rapid prototype + iteration: deliver an MVP dashboard using representative data, run a validation session where stakeholders execute real tasks, log issues, and iterate until acceptance.
• Traceability: map each requirement to dashboard elements and test cases so nothing is missed.

These techniques reduce ambiguity, catch hidden needs, and provide measurable validation before production.

Direct answer

The underlying finding stays identical, but you change altitude, vocabulary, and level of supporting detail. An executive gets the headline, the business impact, and the recommended decision in one or two lines up front. The implementation team gets the mechanism, the caveats, and enough of the underlying data to act on it correctly.

Structured elaboration

• Altitude: conclusion-first for the executive, versus enough method detail for the team to trust and reproduce the diagnosis.
• Vocabulary: business-impact language (revenue, risk, timeline) for the executive, technical specifics (segments, funnels, thresholds) for the team.
• Format: a one-slide or one-paragraph summary versus a working document with a data appendix.
• What must never change: the number itself and the direction of the conclusion, in both versions.

Worked example

Finding: onboarding drop-off at step 3 is costing an estimated 6% of new signups per month.
Executive version: "we're losing about 6 of every 100 new signups at the step-3 confirmation screen, fixing it could recover meaningful revenue this quarter, recommend prioritizing it."
Team version: "62% of that drop-off happens on mobile between form submit and confirmation render, median time to abandon is 9 seconds, this looks like a loading-state issue on mobile specifically."
Both versions agree on the 6% headline number and the recommendation to prioritize the fix.

Trade-offs and pitfalls

The two versions can quietly drift into different conclusions if you're not careful, always trace both back to the same underlying analysis. Over-simplifying for the executive can also strip out the one caveat that would have changed their decision, so pick what to omit deliberately, not by default.

What the interviewer probes next

Expect a question about what happens when the executive summary gets forwarded on without you in the room, and how you prevent it from being read out of context.

Direct answer

Keep the blended north-star metric as the single headline number, since it still has real organizational value, but never publish it without a fixed, small decomposition by user tenure attached to the same dashboard on the same cadence. The reason a healthy-looking aggregate can hide two opposite trends is that it is a weighted average across the user base, and a shift in the mix of who makes up that average can offset a real change in each segment almost exactly, the same mechanism as Simpson's paradox playing out gradually rather than in one before/after snapshot.

Structured elaboration

Why this is structurally possible, not just a coincidence

The aggregate is a weighted average: $\text{blend} = p \cdot e_{\text{power}} + (1-p) \cdot e_{\text{new}}$, where $p$ is the share of power users and $e$ is each segment's average engagement. If $e_{\text{power}}$ rises while $e_{\text{new}}$ falls, the blend can stay fixed if the mix $p$ shifts by just the right amount, and mix shift is exactly the kind of change a single top-line number cannot reveal on its own.

Framework

• Track the north-star metric within a small, fixed set of segments (tenure buckets are a natural first cut: 0-30 days, 30-90 days, 90-plus days) on the same dashboard and cadence as the aggregate, not as a separate ad hoc report.
• Track the segment mix (share of total users in each bucket) alongside the segment-level metric, because a mix shift with stable segment-level numbers is a different problem (a growth or onboarding-funnel issue) than declining segment-level numbers with a stable mix.
• Set an explicit trigger: if any segment's trend diverges from the aggregate's trend by more than an agreed threshold for two consecutive reporting periods, that forces a mandatory segment review, independent of whether the aggregate itself moved at all.
• Cap the tracked dimensions at two or three (tenure, plan tier, acquisition channel) so the decomposition does not become its own form of metric overload.

Worked example

Month 1: power users are 20% of the base with average engagement 50 (arbitrary weekly engagement units), and new users are 80% of the base with average engagement 12.5:

Suppose over the following months power-user engagement genuinely rises to 70 while new-user engagement genuinely falls to 5, and the mix shifts to a power-user share $p_2$. Solve for the mix shift that would keep the blend exactly at 20:

So a mix shift from 20% power users to about 23.1% power users, combined with power-user engagement rising from 50 to 70 and new-user engagement falling from 12.5 to 5, reproduces the exact same blended value of 20 both times:

A relatively small, easy-to-miss mix shift is enough to fully cancel two large, opposite-direction segment trends in the headline number.

Trade-offs & pitfalls

Adding a mandatory segment decomposition to every report increases dashboard and analyst overhead, and tracking too many dimensions dilutes attention the same way too many top-level metrics would, so the dimension cap matters as much as the decomposition itself. A poorly chosen divergence threshold either triggers so often that the mandatory review becomes noise, or is set so loosely that a real multi-month divergence like this one still slips through before anyone is forced to look. The segment-level view should become the operative signal for decision-making once a real divergence is confirmed, but announcing that the north-star metric is "currently misleading" without also showing the decomposition that explains why can undermine trust in the metric more than the underlying problem warrants.

Direct answer. HAVING filters AFTER the GROUP BY has already computed every group's aggregate, so a condition that could have excluded rows BEFORE grouping, if it were expressed as a WHERE clause instead, forces the database to do the full grouping work for every group first and only discard the unwanted ones afterward; moving any predicate that doesn't actually depend on the aggregate itself into WHERE lets the engine filter rows out before the expensive grouping work happens at all.

Structured elaboration. WHERE filters individual rows before grouping; HAVING filters GROUPS after aggregation, and can only reference conditions involving the aggregate result itself (like a computed count or sum), since individual row values are no longer available at that stage. A predicate that's genuinely about the aggregate (HAVING COUNT(*) > 5, filtering on how many rows ended up in a group) has to stay in HAVING, there's no way to know a group's count before you've grouped it. But a predicate that's actually about individual ROWS, and happens to be written after GROUP BY out of habit or oversight, belongs in WHERE, moving it there lets the engine discard non-matching rows before doing any grouping work on them at all, rather than grouping everything first and throwing entire groups away afterward.

Worked example. I verified the semantics with 2,000 orders spread across 20 customers, filtered to status = 'completed' and grouped with HAVING COUNT(*) > 5:

-- correct as written: the row-level filter is already in WHERE
SELECT customer_id, COUNT(*) AS c
FROM orders
WHERE status = 'completed'
GROUP BY customer_id
HAVING COUNT(*) > 5;

This returned all 20 customers, each with roughly 33-34 completed orders (consistent with 2,000 orders split across 20 customers at a completion rate that clears the threshold of 5), confirming the pattern itself is correct here; the actual anti-pattern this survivor is testing shows up when a query moves a genuinely ROW-LEVEL condition, like the status = 'completed' filter itself, INTO the HAVING clause instead (for example HAVING status = 'completed' AND COUNT(*) > 5), which forces the engine to group ALL orders (completed and not) before discarding the non-completed ones, rather than filtering them out first.

Trade-offs and pitfalls. The fix is purely about WHERE the filtering happens, not about changing what the query logically returns; verify a rewrite moving a condition from HAVING to WHERE produces the identical result set before trusting it, since a condition that mixes row-level and aggregate-level logic in one HAVING clause needs to be split carefully, not just relocated wholesale.

Complexity

Filtering rows in WHERE before grouping reduces the INPUT to the grouping step; filtering in HAVING after grouping means the grouping step processed rows that were always going to be discarded, extra work with no benefit.

Edge cases

A condition that references BOTH a raw column and an aggregate in the same clause needs to be split: the raw-column part moves to WHERE, and only the aggregate-referencing part stays in HAVING.

Direct answer

Once you know a partner function is measured on something different from you (speed versus quality or risk, for example), you scope your asks to be small and cheap under their metric, and you change what "status" means when you talk to them: short, action-oriented signals instead of the detailed risk narrative you'd give your own stakeholders. You're not changing what you need, you're changing how you package it so it doesn't read as a tax on the thing they're rewarded for.

Structured elaboration

1. Diagnose the incentive, don't assume it. Confirm what the partner function is actually measured on (deploy velocity, ticket close time, uptime, cost) rather than inferring it from how they push back. Different sub-teams within the "same" function can be measured differently.
2. Scope the ask to the smallest unit that gets you what you need. If they're speed-measured, don't ask for a broad, standing review of everything; ask for a narrow, well-bounded check on the specific surface that carries the risk you actually care about, and let everything else pass without friction.
3. Translate the ask into their currency. Instead of framing a request around your risk language, frame it around what it costs (or saves) them in their terms: incident response hours avoided, rework avoided, a compliance gate they'd otherwise hit later and more expensively.
4. Change the shape of status, not just the ask. For a speed-measured partner, give a compact signal (blocked/not blocked, a count, a single risk flag) they can act on in seconds. Save the fuller narrative for your own stakeholders who need the detail. Sharing the same long-form update with both audiences under-serves the partner who needs to move fast.
5. Keep a floor. Adapting your ask to their incentive has a limit: there's a minimum you can't compromise below without failing your own mandate. Know that floor before the conversation so "scoping down" doesn't quietly become "giving up the requirement."
6. Revisit as trust builds. Early asks are necessarily narrow and low-trust. As the partner sees your asks are well-scoped and your status updates are reliable, you can often widen the ask (a slightly broader review surface, more lead time) because they've learned you're not going to slow them down for nothing.

Worked example

A platform team is measured on release velocity; a security-minded partner function is measured on defect and incident rates. Rather than asking the platform team to route every change through manual security review (a direct tax on their velocity metric), the ask is scoped to only changes that touch a named risk surface, such as authentication or payment code. Everything else ships without added friction. Status to the platform team is a single weekly line: "2 changes in the review queue, 0 blocking, both cleared by Thursday." The fuller write-up, with rationale and residual risk, goes to the security function's own leadership, not to the platform team, because that's not the audience that needs it to act.

Trade-offs & pitfalls

• Pitfall: scoping the ask down so far it stops actually managing the risk it exists to manage. Know your floor before you negotiate.
• Pitfall: assuming the incentive instead of confirming it. Guessing wrong (e.g., treating a team as purely speed-driven when they're also on the hook for a compliance metric) leads to asks that miss what would actually land.
• Pitfall: sending the same status update to every audience. It either over-informs the speed-measured partner (who tunes it out) or under-informs your own stakeholders (who need the detail to make decisions).
• Senior differentiator: treating the ask size and the status format as things you design deliberately around the incentive gap, and revisiting that design as trust changes, rather than a fixed communication style you use with everyone.

Direct answer
A marketing-budget-allocation executive dashboard needs a small set of trusted, reconciled per-channel and per-region numbers (LTV/CAC point estimates with uncertainty ranges), a clear data-lineage story tying those model outputs back to the raw spend/conversion feeds, and visuals (marginal-ROAS curves, scenario simulation) chosen to make the reallocation trade-off actionable rather than merely descriptive.

Structured elaboration

1. Required data sources: the per-channel and per-region ad-spend and conversion feeds from each ad platform, the LTV/CAC model's own output table (point estimate plus uncertainty interval per channel and region), a historical spend-versus-response dataset used to estimate diminishing returns, and the finance-approved total budget-constraint record.
2. Source validation and reconciliation: validate that the per-channel spend figures tie back to each ad platform's own reported spend within an acceptable tolerance, and that the model output table's total predicted spend matches the actual budget-constraint record, so a channel's uncertainty range is never computed against stale or unreconciled spend data.
3. Model outputs to surface: always show the point estimate AND the uncertainty range for LTV/CAC per channel/region, never a bare point estimate, since an allocation decision made on a point estimate alone hides how confident the model actually is.
4. Decision rule for reallocating budget: reallocate from a channel/region only when its marginal ROAS (the model's forecasted return on the NEXT incremental dollar, not its average historical ROAS) falls below the portfolio's target hurdle rate, and only into a channel/region whose marginal ROAS is comfortably above that hurdle after accounting for the uncertainty range, not just the point estimate; where two candidates' uncertainty ranges overlap substantially, treat the reallocation as a hypothesis to test at smaller scale first, not a full-budget move.
5. Visualization choices: marginal-ROAS curves per channel/region (showing how ROAS declines with each additional dollar, the direct evidence for diminishing returns) plotted with a shaded uncertainty band around each curve, and a scenario-simulation view letting the executive test a candidate reallocation amount between two channels/regions and see the projected blended LTV/CAC outcome and its range before committing.
6. Decision framing: every visual should make the trade-off explicit (e.g. "reallocating $200K from Channel A to Channel B is projected to increase blended LTV/CAC by X, within a stated uncertainty range") rather than just displaying historical figures.

Worked example
Region C's Paid Social channel shows a marginal ROAS of 1.1x (90% CI: 0.8x-1.4x) against a portfolio hurdle rate of 1.5x, flagging it as a reallocation-from candidate; Region A's Search channel shows a marginal ROAS of 2.3x (90% CI: 1.9x-2.7x), comfortably above hurdle. The scenario-simulation view lets the executive test moving $200K from Region C/Paid Social to Region A/Search and see the projected blended LTV/CAC and its uncertainty range before approving the actual budget change.

Trade-offs and pitfalls
Skipping the spend-reconciliation step is the most common and most damaging shortcut on a budget-allocation dashboard: a model output that looks right but doesn't tie back to actual ad-platform spend or the finance-approved budget constraint can quietly justify a reallocation that finance later rejects, undermining trust in the model the first time the discrepancy surfaces.