Senior Business Intelligence Analyst Interview Preparation Guide - Lyft

Approach: convert records into a pandas DataFrame, normalize dates, filter transactions for the target month, compute total revenue per active user in that month, and return the mean (ARPU). Active user = any user with at least one transaction in the month.

import pandas as pd
from typing import List, Tuple, Union

def compute_arpu(transactions: List[Tuple[Union[int,str], float, str]], month: str) -> float:
    """
    transactions: list of (user_id, amount, occurred_at) where occurred_at is ISO date/time string
    month: target month in "YYYY-MM" format
    Returns: ARPU (float). Returns 0.0 if no active users or no transactions in month.
    """
    if not transactions:
        return 0.0

    df = pd.DataFrame(transactions, columns=["user_id", "amount", "occurred_at"])
    # parse dates robustly
    df["occurred_at"] = pd.to_datetime(df["occurred_at"], errors="coerce")
    df = df.dropna(subset=["occurred_at", "amount", "user_id"])

    # filter by month string YYYY-MM
    try:
        year, mon = map(int, month.split("-"))
    except Exception:
        raise ValueError("month must be 'YYYY-MM'")

    mask = (df["occurred_at"].dt.year == year) & (df["occurred_at"].dt.month == mon)
    df_month = df.loc[mask]

    if df_month.empty:
        return 0.0

    # total revenue per active user in month
    revenue_per_user = df_month.groupby("user_id")["amount"].sum()
    arpu = revenue_per_user.mean()
    return float(arpu)

Key points:

• Time complexity: O(n) to parse/filter/group where n = number of records.
• Space: O(n) for DataFrame.
  Edge cases handled:
• Empty input or no transactions in month -> returns 0.0
• Malformed dates are coerced to NaT and dropped
• Multiple transactions per user aggregated
• Negative/refund amounts included in net ARPU
• Invalid month format raises ValueError

Possible extensions: support timezone-aware parsing, accept month as datetime, or return ARPU alongside active user count and total revenue for dashboards.

Direct answer

Classical A/B testing should be the default: a fixed traffic split, a pre-computed sample size, one analysis at the end, which gives a clean effect estimate with a known false-positive rate. A multi-armed bandit (MAB) earns its added complexity only when the in-test opportunity cost is genuinely high, many candidate flows, high traffic, real conversions lost every day a worse arm keeps getting equal traffic, because a bandit shifts traffic toward whatever currently looks best while the test is still running. That speed comes at the price of exactly the statistical guarantees a fixed A/B test provides, so a production bandit needs deliberate scaffolding, most importantly a held-out slice the adaptive logic never touches, to stay credible rather than just fast.

Structured elaboration

When MAB is appropriate. Many candidate arms, where a fixed even split wastes meaningful traffic on variants likely to be bad from the start; a genuinely high in-test opportunity cost, each conversion lost during testing has real value, as it does at a checkout or onboarding step, rather than a low-stakes cosmetic change; and a setting that is an ongoing production routing decision (which flow to show right now, continuously) rather than a one-time launch call that needs a classical p-value to defend to stakeholders.

Pitfalls, named as asked.

• Bias. A bandit reallocates traffic toward arms that look good early, so an arm that happened to start weak by pure chance gets starved of traffic before its true performance has a real chance to show. The final "winning" arm's reported conversion rate is upward-biased: you are effectively conditioning on having looked good at exactly the sample sizes where noise matters most, so naive post-hoc reporting of a bandit's winning arm overstates its true effect relative to what a properly randomized comparison would show.
• Reduced shipping of learning, underexploration of losing arms. As a bandit converges, it stops sending meaningful traffic to arms that currently look worse, which costs statistical power to actually confirm they are worse rather than just noisy early on, and removes the ability to notice later if a losing arm's true performance changes, since it is barely being observed anymore.
• Non-stationarity. A bandit implicitly assumes each arm's true conversion rate stays roughly constant through the test. If the environment shifts, a seasonal effect, a competitor's promotion, a change in who is arriving at the funnel, the bandit's accumulated confidence in the current best arm can lag badly behind reality, and it can take a long time for new evidence to overcome an already-strong prior, continuing to route most traffic to an arm that used to be best but no longer is.

Designing a safe MAB strategy. Use an adaptive policy, epsilon-greedy (with probability $\epsilon$ pick a uniformly random arm, otherwise the current best) or Thompson sampling (maintain a $\text{Beta}(\alpha_a, \beta_a)$ posterior per arm, draw a sample from each posterior, route to whichever sample is highest), for the majority of traffic, but hold out a small, fixed slice, for example 10 percent, that is randomized uniformly across arms for the entire test and never touched by the adaptive logic. That slice exists for one purpose only: unbiased evaluation, fully decoupled from the allocation decisions the bandit is making with the other 90 percent, which is exactly the traffic subject to the bias and underexploration problems above and therefore cannot itself be trusted for a clean final comparison or for catching a later shift in a losing arm's true rate.

A related, distinct experimentation-design concern: long-horizon holdout groups. Separate from the evaluation slice above, but the same underlying discipline applied at a longer time horizon, is a holdout group for measuring the lifetime effect of a campaign or an onboarding change: a fixed cohort deliberately excluded from every treatment variant, not just the eventual losing ones, for weeks or months, so their downstream behavior (long-term value, repeat engagement, referrals) establishes an uncontaminated baseline the treated population can still be compared against well after the initial launch decision was made. Three design considerations matter here specifically: sizing (large enough for a stable long-run baseline, small enough that excluding real users from what may turn out to be a genuinely better experience for months does not sacrifice too much value); spillover prevention (a holdout user must not be indirectly exposed through a treated friend, a referral, or a shared household, which contaminates the holdout the same way an under-isolated control region contaminates a difference-in-differences design); and rotation (periodically rotating which users sit in the holdout rather than freezing one cohort forever, both to spread the cost of exclusion across more users over time and to keep the holdout's composition from drifting away from the live population as the product itself evolves).

Worked example

Three onboarding flows, A, B, and C, each start with an uninformative $\text{Beta}(1,1)$ prior under Thompson sampling. After an early batch of traffic:

This is the standard closed-form conjugate update (posterior $\alpha$ = prior $\alpha$ plus observed successes, posterior $\beta$ = prior $\beta$ plus observed failures), verified directly: $1+8=9$, $1+4=5$, and likewise for B and C. For the next arriving user, Thompson sampling draws one random value from each of these three Beta distributions and routes to whichever draw is highest. Flow A, with the highest posterior mean and a moderately tight posterior after 12 trials, wins most such draws and gets most of the next batch of traffic, but not all of it: B and C's posteriors still have real spread this early, so they keep getting sampled and explored, more or less often depending on how much of their probability mass overlaps with A's. This is Thompson sampling's core property: exploration is not a separate fixed parameter like epsilon-greedy's $\epsilon$, it falls out naturally from posterior uncertainty and shrinks on its own as more data tightens each arm's distribution. Meanwhile, the 10 percent held-out slice keeps sending uniformly random traffic to A, B, and C throughout, so the final reported conversion rate for each flow, and any later check for whether B's true rate has changed, comes from that untouched slice rather than from the adaptive majority.

Trade-offs and pitfalls

• Common mistake: reading a bandit's converged allocation as statistical proof. "Flow A is getting 80 percent of traffic" is a policy decision made under uncertainty, not a hypothesis-test result; the held-out slice is what actually supplies a defensible final comparison.
• Common mistake: sizing the held-out slice too small to detect anything. It needs its own power calculation against the minimum effect size that actually matters, exactly like a standalone A/B test would, otherwise it exists in name only and never catches what it was built to catch.
• A stable-looking allocation is not evidence the environment is stationary. Only the held-out slice, or an explicit non-stationarity check such as decaying the weight of old observations in each posterior over time, can actually surface drift; the adaptive majority of traffic will happily keep routing to a stale winner.
• The speed advantage is real but is a deliberate trade-off, not a free upgrade. Shipping the better-looking flow to more users sooner has genuine value in a high-opportunity-cost setting, at the cost of weaker confirmatory evidence than a fixed A/B test would give; that trade-off should be made and stated on purpose, not defaulted into because a bandit sounds more sophisticated than a fixed split.

A warehouse-level result cache, BigQuery's automatic result cache is the canonical example, stores the exact output of a previously executed query, keyed by the query's text (and, in most implementations, the state of the underlying tables at execution time), and serves that stored result instead of re-running the query the next time an identical query is issued, as long as none of the tables it read have changed since the cached result was produced.

How it interacts with table updates

The cache is invalidated per-query the moment any table the original query touched changes, and it separately carries its own upper-bound time-to-live independent of table changes: BigQuery's automatic result cache, for example, holds a cached result for roughly 24 hours and also invalidates it immediately if any referenced table changes before that window closes, whichever happens first. A new insert, update, or delete to any dependency invalidates every cached result that depended on that table, even a result that was otherwise perfectly fine, and even a result over tables that never change still eventually falls out of cache once the TTL elapses. This means result-cache freshness is exact (you will never see a result that is definitely stale relative to the table's current state) but its hit rate on a table that updates frequently, even in ways unrelated to what a specific dashboard displays, can be much lower than expected.

Designing to benefit from it

• Keep dashboard queries byte-for-byte identical across users and page loads where possible (same column order, same literal formatting, same filter representation), since most result-cache implementations key on the query text, not its semantic meaning, so two queries that return the same rows but are phrased differently will not share a cache entry.
• Separate frequently-updated tables from the tables a dashboard's expensive aggregation actually depends on, where the data model allows it, so that an unrelated update elsewhere in the warehouse does not needlessly invalidate a cached dashboard result.
• Combine with a materialized view or pre-aggregated table for the truly high-traffic dashboards, so the result cache is caching a cheap read of an already-small pre-aggregated table rather than a full scan-and-aggregate, which keeps even a cache miss relatively cheap.

Trade-offs and pitfalls

Relying on the result cache alone for freshness guarantees is fragile: it silently serves a fresh answer when nothing changed and silently falls back to a full, potentially expensive recomputation the instant anything changes, with no visible degradation warning to whoever is watching dashboard latency. Do not treat the cache hit rate as something you can directly control; design the query patterns and table update cadence around it instead, and treat it as a free accelerant on top of a materialized-view strategy, not a substitute for one.

1. Completed Trips (market activity - rider + driver)

• Improvement: up (more fulfilled demand)
• Guardrail: Cancellation Rate (rises may hide churn)
• Frequency: Weekly (with daily spike alerts)

2. Gross Bookings / Revenue per Week (monetary health)

• Improvement: up
• Guardrail: Average Trip Distance or Surge % (big revenue increase driven by longer trips or extreme surge may mask poor underlying demand)
• Frequency: Weekly (daily for anomalies)

3. Rider Conversion / Booking Rate (rider-side experience)

• Improvement: up (more riders who open app book a ride)
• Guardrail: App Crash Rate or Time-to-Match (UX issues can lower conversion)
• Frequency: Daily

4. Active Drivers / Driver Utilization (driver-side supply & engagement)

• Improvement: Active drivers stable/increasing and utilization (trips per active driver) healthy
• Guardrail: Driver Churn Rate or Acceptance Rate (low acceptance suggests dissatisfaction)
• Frequency: Daily

5. Marketplace Match Time / Time-to-Pickup (efficiency & experience)

• Improvement: down (shorter match-to-pickup time)
• Guardrail: Cancellation Rate by pickup window (faster matches but more cancellations may indicate bad matches)
• Frequency: Real-time/Hourly for ops, summarized weekly

6. Fill Rate / Unfulfilled Requests (%) (demand-supply balance)

• Improvement: down (fewer unfulfilled)
• Guardrail: Average Wait Time and Surge Frequency (low unfulfilled but very high surge could show tight supply)
• Frequency: Daily (real-time alerts when spike)

For leadership: deliver the six metrics on one page with trend sparklines, week-over-week % change, and one-sentence insight + recommended action.

Direct answer

Build a mapping and identity-resolution layer between the two companies' product and customer models, assign new conformed surrogate keys for the unified entities, keep each company's original dimension tables live and queryable during a transitional period (so pre-merger historical reports remain reproducible exactly as before), and cut fact tables over to the unified conformed dimensions once the mapping is validated.

Structured elaboration

• Mapping approach: similar to conforming a product dimension across multiple sources, build explicit mapping tables (companyA_customer_id -> conformed_customer_key, companyB_customer_id -> conformed_customer_key) using a combination of exact-match keys where available (shared tax ID, email) and fuzzy matching with human review for ambiguous cases.
• Surrogate key generation for the unified model: mint entirely new conformed surrogate keys (not reusing either company's original keys, which avoids collisions and signals clearly that this is the unified, post-merger identity space) for every matched or newly-recognized entity.
• Conformed attributes: define, for any attribute both companies tracked differently (customer segment definitions, product categorization), an explicit reconciliation rule or a documented mapping between the two taxonomies, rather than silently picking one company's definition.
• Transitional layer, running both models in parallel: keep each company's original schema and historical fact tables intact and queryable (so a pre-merger report, re-run during the transition, still reproduces its original numbers exactly), while NEW fact data (post-merger) loads against the unified conformed dimensions; a transitional reporting layer can present a blended view by translating old-company-specific keys through the mapping tables when needed.

Worked example

Company A's customer CA-500 and Company B's customer CB-900 are identified as the same real-world entity (matched via a shared corporate tax ID) and both map to a new conformed customer_key = 100001. Pre-merger sales history from both companies remains queryable against their ORIGINAL dimension tables for historical continuity; post-merger sales load against the new conformed customer_dim, and a cross-period trend report joins pre-merger history through the mapping table to the conformed key to show this customer's full relationship across the merger boundary.

Trade-offs and pitfalls

Rushing to force ALL historical data into the unified model immediately (rather than running the transitional dual-model period) risks corrupting the historical record if the identity-resolution mapping has errors discovered later; keeping the original per-company schemas alive and immutable during transition gives a safety net to fall back on, at the cost of running two schemas in parallel for a period, which is real but bounded operational overhead worth paying for a migration of this risk level.

Direct answer

Write-audit-publish means landing new data in a staging location consumers can't see yet, running data-quality checks (the audit) against it while it is still invisible, and only then making it visible with a single atomic operation (a partition swap or a pointer flip), rather than publishing first and validating afterward. The audit step exists to solve the problem of consumers reading bad or partial data during a load: without it, "load then check" means anyone querying during or right after a bad load already saw the wrong numbers before any check had a chance to catch it.

Structured elaboration

The problem this solves. A pipeline that writes directly into the table or partition consumers actually query, then validates afterward if at all, leaves a window between when writes start and when a check would have failed, during which consumers can read incomplete or wrong data with no visible signal anything is wrong.

The three stages:

1. Write. Land the new batch in an isolated location, a staging table, a new partition or version, a new file set, that existing queries against the published location cannot see at all.
2. Audit. Run validation against that staged data while it remains invisible to consumers: row counts against expectation, null rates, schema conformance, referential checks, business-rule checks.
3. Publish. Only if the audit passes, flip visibility with a single atomic operation, an atomic partition swap, a metadata pointer update, or a table rename, so consumers see either the previous, already-audited state or the new, now-audited state, never a partial mix of the two.

Why the publish step has to be atomic. If publishing itself were multiple steps (remove old rows, then insert new ones), a reader querying in the middle could see an inconsistent partial state even after the audit already passed. The pattern only fully solves the visibility problem if the very last step is a single, indivisible flip.

What happens when the audit fails. The staged batch is simply never published. Production keeps serving the last good, already-audited state, and the failed batch goes to remediation instead of ever becoming visible to anyone.

Where it fits and where it doesn't. This suits batch or micro-batch loads into a location with many downstream readers who can't each validate before consuming, like a shared warehouse table. Strict low-latency streaming, where staging and swapping an entire batch isn't practical, achieves the same underlying goal (don't let one bad unit block or corrupt everyone) through per-record dead-letter handling instead.

Worked example

A daily table normally holds 2,000,000 rows. A join bug in that day's load causes fanout, and the staged batch lands with 2,600,000 rows:

If the audit's row-count check allows a tolerance band of plus-or-minus 5 percent around the historical baseline, a 30 percent deviation fails it clearly, so the atomic swap never happens. Consumers keep reading yesterday's correct 2,000,000-row table while the bad batch sits quarantined and the join bug gets fixed, instead of every downstream report briefly, or permanently until someone happens to notice, reflecting a 30 percent inflated count.

flowchart LR
    A[New batch written to staging] --> B[Audit checks run on staged data]
    B -->|pass| C[Atomic publish: swap or pointer flip]
    B -->|fail| D[Staged data quarantined]
    C --> E[Consumers read new data]
    D --> F[Remediation and retry]
    F --> A

Trade-offs & pitfalls

• Auditing the already-published table instead of the staged one only catches the problem after consumers may already have read bad data; the ordering, audit before publish rather than after, is the entire point of the pattern.
• Making publish itself a multi-statement operation reintroduces the exact partial-visibility problem the pattern exists to prevent.
• The pattern trades some latency (data isn't visible until the audit finishes) and some storage (staged and published copies briefly coexist) for that safety; that's a clear win for a widely-consumed shared table, and a less obvious win for a low-stakes, single-consumer dataset where the extra latency may not be worth it.
• A common wrong turn is treating "we run some validation somewhere in the pipeline" as equivalent to write-audit-publish; the pattern specifically depends on the audited data being invisible to consumers until it passes, not just checked at some point along the way.

I would start by diagnosing the problem before trying to fix it. I would interview both teams, review the timeline, and map every requirement change, handoff, and missed dependency. I would look for evidence of changing scope, unclear ownership, or missing acceptance criteria rather than assuming the issue is attitude.

Then I would reset the operating model. First, create a single source of truth for requirements and decisions. Second, define ownership for each deliverable and each handoff. Third, add a lightweight change-control step so new requirements are reviewed, sized, and approved before they disrupt the plan. I would also establish a regular checkpoint where both teams see the same risks and blockers.

If I found that the real problem was unclear handoffs, I would introduce a standard handoff template with the deliverable, due date, acceptance criteria, and owner. For example, if design changes a flow, engineering should see exactly what changed and what stayed stable. That shifts the teams from blame to shared execution and usually stabilizes delivery quickly.

For example, say the two teams are the Checkout team and the Fulfillment team, and the requirement that kept shifting was how a partial refund should be represented in the order-status payload. A filled-in handoff entry might read: deliverable: order-status payload v2 for partial refunds; due date: the 14th; acceptance criteria: refund_amount and refund_reason fields present and validated against three sample orders; owner: the Checkout API lead. With that entry in place, Fulfillment could build against a fixed contract instead of a moving target, and in the next release cycle the number of last-minute payload changes dropped to zero, because any change now had to go through the same template before it reached Fulfillment.

Start by clarifying goals: support business outcomes (speed to insight), data governance, cross-functional neutrality, domain expertise, and career development for BI staff. Evaluate using these criteria:

• Strategic alignment: which org needs BI close to its roadmap?
• Breadth vs depth: company-wide standardization vs domain-specific depth.
• Stakeholder demand patterns: many ad-hoc cross-team requests vs heavy finance/metric needs.
• Objectivity & governance: need for independent validation and data consistency.
• Speed & prioritization: trade-offs between centralized backlog and local SLAs.
• Talent growth & skill specialization: coaching, career ladders, tooling investment.
• Cost & tooling ownership: who funds platforms, licenses, and infra?

Reporting options, risks, and daily impact:

1. Reporting into Product

• Risks: product priorities may bias metrics toward product KPIs; cross-org needs deprioritized.
• Daily change: BI works closely with PMs, embedding in product sprints, faster feature telemetry dashboards, more A/B focus. Decision-making becomes product-driven; roadmap aligned to feature releases.

2. Reporting into Finance

• Risks: finance focus on historical accuracy and compliance may slow exploratory analytics and innovation.
• Daily change: emphasis on financial modeling, month-end reporting, strict governance. BI decisions prioritize auditability, reconciliations, and financial KPIs over product experiments.

3. Central Analytics / COE

• Risks: potential bottleneck, slower delivery for urgent domain needs; needs strong prioritization governance to avoid stakeholder frustration.
• Daily change: BI enforces standards, builds reusable metrics layer, handles cross-functional projects, provides consultation. Decision-making shifts to a governed backlog with SLAs and platform roadmap ownership.

Recommendation pattern:

• If organization needs consistency, regulatory rigor, and shared metrics, central analytics is preferred.
• If BI’s primary consumers are product teams needing rapid iteration and experimental analytics, product reporting works with embedded liaisons to maintain standards.
• For startups where finance drives survival metrics (cash, burn), finance reporting can make sense short-term but plan transition to central model as scale increases.

Mitigations: establish metric catalog/semantic layer, SLAs, dual-reporting dotted lines, and rotation programs so BI stays domain-savvy but governed.

Direct answer

Do not rebuild the existing department's star schema from scratch: keep it running, and introduce a compatibility view layer between its existing dimensions and a newly-built conformed version, so its current reports keep working unmodified while every new mart is built against the conformed dimensions from day one. Sequence the three new departments' marts in whichever order matches the bus matrix's widest-touching dimensions first, exactly as you would for a greenfield build, since from their point of view they are joining an enterprise warehouse that already has its shared dimensions defined.

Structured elaboration

What to do with the existing star schema. The existing department's fact table and dimensions almost certainly still work correctly for that department's own reports; the problem is only that its dimensions were never designed to be reused by anyone else. Do not touch the fact table. Build new, properly conformed versions of whichever dimensions the other departments will also need (typically customer and date), migrate the existing department's fact table to reference the new conformed dimension's keys, and leave everything else about that department's schema alone.

Introducing conformed dimensions without breaking existing reports. The mechanism that makes this safe is a compatibility view: create a view with the OLD dimension's name and column names, backed by the NEW conformed dimension underneath, so any report or dashboard query that has not been touched keeps running against the old names while the underlying table is now the shared one. Reports get migrated to query the conformed dimension directly (picking up any new attributes it offers) on the team's own schedule, not as a synchronized cutover, and the compatibility view is retired only once nothing depends on it anymore.

Sequencing the migration. For the three new departments, treat this the same way you would size a bus matrix for a greenfield enterprise build (see the sales-orders-first reasoning used when a company plans from scratch): whichever new department's mart shares the most dimensions with the others should be built first against the now-conformed dimensions, so its build validates that the conformed dimensions actually generalize before a second and third department also depend on them.

Worked example

A minimal, runnable illustration of the compatibility-view mechanism:

CREATE TABLE dim_customer_conformed (
    customer_sk   BIGINT PRIMARY KEY,
    customer_id   VARCHAR,
    customer_name VARCHAR,
    region_code   VARCHAR      -- new attribute the conformed dimension adds
);
INSERT INTO dim_customer_conformed VALUES
  (1, 'CUST-100', 'Ada Lovelace', 'EMEA'),
  (2, 'CUST-200', 'Grace Hopper', 'AMER');

-- The original department's dimension name and column names, preserved as a view
-- backed by the new conformed table underneath:
CREATE VIEW dim_customer_v1 AS
SELECT customer_sk, customer_id AS cust_id, customer_name AS cust_nm
FROM dim_customer_conformed;

-- The department's existing report, unmodified, still returns correct results:
SELECT cust_id, cust_nm FROM dim_customer_v1 ORDER BY cust_id;

Executed, the unmodified report query returns [('CUST-100', 'Ada Lovelace'), ('CUST-200', 'Grace Hopper')], exactly what it returned before the migration, while a new report written directly against dim_customer_conformed can immediately use the new region_code attribute the old schema never had.

Trade-offs and pitfalls

The most damaging mistake is treating this as a single cutover weekend: forcing every existing report to move to the new conformed dimension at once maximizes the chance something breaks in production with no fallback. The compatibility view exists precisely so migration can happen gradually, dashboard by dashboard, with the old and new dimensions correct and consistent with each other for as long as both are in use. The second common mistake is skipping the conformance work for a "small" attribute mismatch (say, the old dimension calls it cust_nm and everyone assumes it obviously maps to customer_name), which is exactly the kind of undocumented assumption that produces the four-different-customer-dimensions problem a badly-managed enterprise rollout tends to create.

Direct answer

SLI, SLO, and SLA are three layers of the same idea, stated with increasing weight. An SLI (service level indicator) is what you actually measure. An SLO (service level objective) is the internal target you set for that measurement. An SLA (service level agreement) is the external promise, usually contractual, built on top of that target, with consequences if you miss it. In plain terms: the SLI is the speedometer, the SLO is the speed limit you've set for yourself, and the SLA is the speed limit you've promised a customer you won't exceed, with a penalty if you do.

Picking the example and the threshold

• Choose one measurable thing the executive already cares about, not an internal engineering metric they have no context for. "Percent of requests that succeed" beats a raw latency percentile for this audience, because success or failure needs no further explanation.
• State the SLO as a number deliberately below what looks achievable. This is the part executives most often misread: an SLO of 99.9% isn't "we're at 100% and slipping a little," it's a chosen buffer that leaves room to ship changes and absorb normal failures without over-investing in reliability nobody needs.
• The SLA number sits below the SLO, with a consequence attached, and that gap is itself worth explaining: it exists so that missing the internal target doesn't automatically mean breaking a customer promise.
• The same three-layer structure holds outside web services too, whether you're onboarding a new product manager on a team's SLOs for the first time or defining an SLI/SLO for a streaming data pipeline (there the SLI might be how stale the data is, instead of whether a request succeeded), the relationship between the three layers doesn't change, only what's being measured does.

Worked example

Say the team sets it up this way for a checkout API. SLI: percent of checkout requests that return successfully within two seconds. SLO: 99.9% of checkout requests meet that bar, measured over a rolling 30 days, the number engineering is held to internally. SLA: 99.5% of checkout requests meet that bar, measured monthly, written into the enterprise customer contract; falling below it triggers a service credit specified in the contract.

Business consequence of missing the SLA (say the month comes in at 99.3%): this is a contractual breach. The customer is owed the agreed credit, and depending on the contract, may have grounds to escalate or walk away. It's a direct, quantifiable cost and a trust hit that shows up outside engineering entirely.

Business consequence of exceeding the SLO (say the month comes in at 99.97% against a 99.9% target): this isn't a "consequence" in the SLA sense, it's a signal. Consistently beating the SLO by a wide margin means either the target is stale and could absorb more risk (ship faster, take on more ambitious changes), or the team is over-investing effort in reliability the product doesn't need. Either way it's a prompt to revisit the number, not something to report as a win on its own.

Trade-offs and pitfalls

The most common executive misunderstanding is treating the SLO as the promise, when the SLA is the promise and the SLO is the internal cushion above it. Say that gap out loud every time, or the SLO number will get quoted externally by mistake. The second pitfall is picking a metric that's technically correct but means nothing to the audience, an uptime percentage without saying what "down" costs the business, always translate the metric into what the customer actually experiences before attaching a number to it.