Business Intelligence Analyst Interview Preparation Guide - Junior Level (FAANG Standards)

Direct answer

I spend the stakeholder's (the person with a stake in the outcome whose input I depend on) scarce time only on questions that are expensive to get wrong, make them easy to answer, and keep working on everything else using written assumptions. Then I tell them plainly what I am assuming, what it costs if I am wrong, and by when I need a yes or no. Progress and risk are both visible, so I do not stall and I do not guess silently.

How I balance asking with moving forward

1. Sort my questions by cost of being wrong. If a wrong guess can be undone in an afternoon, I decide and note it. If it would force weeks of rework or produces a wrong number in front of leadership, it goes on the list for the stakeholder.
2. Batch and shrink the ask. One message with at most five questions in priority order, each phrased so the reply can be one word, and each with my proposed default: "I plan to include refunds in revenue (net). Reply 'ok' or tell me what you prefer."
3. Look for a proxy. A deputy, a long-serving analyst or a prior document can answer many questions. Ask the stakeholder to name that person once, instead of asking them every time.
4. Ask for a standing slot. A 15-minute weekly checkpoint beats ad hoc interruptions.

What I write down: an assumptions log

I also record the date each question was asked and any reply, so the trail shows I tried.

How I communicate the risk

One short message to the stakeholder and, if the decision matters, their sponsor: "I am proceeding on these three assumptions (listed). If A is wrong, the cost is roughly two days. If B is wrong, we would have to rebuild the data model, so I need your answer on B by Wednesday. If I hear nothing, I will carry on with the stated default and flag it clearly in the draft." Then I mark the assumption visibly in the deliverable, so nobody mistakes a guess for a confirmed fact.

Worked example

A business-intelligence analyst is building a weekly sales dashboard and the finance lead answers messages once every few days. Of eight open questions, six are reversible formatting and labelling choices, so the analyst decides and logs them. The two that matter (refund treatment and fiscal calendar) go in one message with defaults. The finance lead replies "ok" to one and corrects the other in a two-minute reply. Nothing waited for a meeting.

Trade-offs and pitfalls

• Asking nothing is as risky as asking everything: it leaves hidden bets in the work.
• A stakeholder's silence is not approval. State the default and the date, and escalate when the downside is large.
• Do not hide the risk in a long status report; put it in the first sentence of the message.
• If a wrong assumption would cause real harm (money, compliance, customer-facing numbers) escalate to the sponsor rather than proceed on a guess.

Requirements:

• Sales reps see only rows for their assigned territory.
• Managers see aggregated performance for all territories they manage (no individual-level PII).
• Easy admin maintenance and auditable mapping.

Design overview:

1. Security mapping table (in the data model)

• Table: UserTerritoryMap(UserPrincipalName, TerritoryID, Role) where Role ∈ {Rep, Manager}.
• Keep as imported table refreshed from HR/CRM or Azure AD group sync.

2. RLS implementation (model-level)

• Create two roles in Power BI: RepRole and ManagerRole.
• RepRole DAX filter on Sales table (or Territory table):

// RepRole: filter territories to those mapped to the current user
[TerritoryID] IN
    SELECTCOLUMNS(
        FILTER(UserTerritoryMap, UserTerritoryMap[UserPrincipalName] = USERPRINCIPALNAME() && UserTerritoryMap[Role] = "Rep"),
        "T", UserTerritoryMap[TerritoryID]
    )

• ManagerRole: allow territories they manage but mask row-level details; recommend creating a manager view table that aggregates (TerritoryID, TotalSales, NumOrders, AvgMargin) and applying:

// ManagerRole applied to ManagerView (if using table-level roles)
TRUE()

Then build report visuals pulling from ManagerView to prevent drilling into raw rows.

3. Workspace/group-based limits

• Restrict report Author/Member permissions in workspace; only admins can edit RLS roles. Use app publishing to distribute; do not give build permissions to broad groups.

Testing & validation:

• Use Power BI Desktop “View As” to test RepRole and ManagerRole with several USERPRINCIPALNAME() values; validate filters and aggregated measures.
• Test with sample users: rep with multiple territories, manager of multiple reps, user without mapping (should see no data).
• End-to-end: publish to a test workspace and use “Test as role” in Service; verify no export of underlying data (disable export if needed).
• Audit: enable dataset usage and RLS change tracking; log mapping table updates and periodic reconciliation against HR source.

Best practices:

• Keep mapping table authoritative and automate refresh.
• Prefer aggregated tables for managers to prevent accidental row exposure.
• Document roles, owners, and run quarterly audits.

Direct answer
Design a visualization and alerting system for data-integrity issues (sudden drops, duplicates, or spikes in ingestion metrics) around a small set of well-chosen visual encodings (a trend line with a shaded expected-range band, and duplicate/volume counters), alert thresholds tuned against the metric's normal variation, and a direct path from an alert into the underlying data so an analyst can investigate the root cause without leaving the dashboard.

Structured elaboration

1. Visual encoding: a trend line for the ingestion volume (or key metric) overlaid with a shaded band representing the expected range (e.g. a rolling mean plus/minus a few standard deviations), so a sudden drop or spike visually breaches the band rather than requiring the viewer to mentally compute what's "normal."
2. Duplicate detection: a simple counter or ratio (e.g. distinct-record-count vs. total-record-count) trended over time catches a sudden duplication issue as a visible divergence between the two lines.
3. Alert thresholds: base thresholds on the metric's own historical variation (e.g. a z-score or rolling-percentile approach) rather than a fixed number, since ingestion volume often has its own natural daily/weekly pattern.
4. Root-cause investigation from the dashboard: an alert or a breached-band point should link directly to a filtered view of the underlying records for that time window, so an analyst can see what changed (a source system outage, a schema change, a duplicate-producing retry bug) without re-querying from scratch.

Worked example
Daily ingestion volume trended with a shaded band from a 30-day rolling mean plus/minus two standard deviations; a day where volume drops 60% below the band triggers an alert, and clicking that point opens a filtered log view showing zero records received from one specific upstream source, immediately narrowing the root-cause search.

Trade-offs and pitfalls
A fixed-threshold alert (e.g. "alert if volume drops below X") breaks the first time the business's normal volume legitimately shifts (growth, a new market, a seasonal low); a rolling-baseline approach adapts automatically but takes more design and validation effort up front.

Randomized experiments (A/B tests) give the strongest causal evidence because randomization balances observed and unobserved confounders; observational metrics are faster/cheaper but risk confounding and selection bias. For a BI analyst, choosing between them depends on the decision’s stakes, feasibility, and timeline.

When to rely on experiments:

• High-impact product changes (pricing, major UX flows) where causal certainty matters.
• When you can randomize exposure without ethical or technical constraints.
• When you can instrument metrics and run for sufficient sample size to detect meaningful effects.
  Example: rolling out a new checkout flow to 50% of users to measure conversion lift with pre-specified metrics and stopping rules.

When to rely on observational analysis:

• Exploratory insights, hypothesis generation, or monitoring where randomization is infeasible (e.g., policy changes, 3rd-party events).
• Fast, low-cost signals for prioritization or iterative improvements.
• Use causal inference methods (difference-in-differences, regression discontinuity, propensity scores) to strengthen claims but acknowledge limitations.
  Example: measuring the impact of a city-level marketing campaign where randomization wasn’t possible.

Trade-offs (summary):

• Causality vs speed: experiments >> causal; observation >> fast and cheap.
• Cost: experiments incur engineering, rollout, and opportunity costs; observational uses existing data but may require advanced modeling.
• Time: experiments need sample accumulation and analysis windows; observational can be immediate but less definitive.

How BI combines both:

• Use observational analysis to identify candidate ideas and segmentation to prioritize experiments.
• Instrument dashboards to monitor experiment metrics in real time and catch guardrail issues.
• After experiments, use observational data to validate external validity (do effects persist across cohorts, geographies, time?) and to analyze long-term outcomes that exceed experimental windows.
• Implement an experiment catalog and standardized metric definitions in BI to ensure consistency and prevent p-hacking.

Limitations and best practices:

• Power and sample-size planning, pre-registration of primary metrics, and guardrail metrics for experiments.
• For observational work, transparently report assumptions, sensitivity analyses, and potential confounders.
• Combine methods: run experiments when feasible; where not, use robust quasi-experimental designs and triangulate findings across data sources.

Recommendation: treat experiments as the gold standard for causal claims, observational analysis as complementary for speed and scope, and BI as the integrator that surfaces hypotheses, operationalizes metrics, and tracks both experiment and real-world performance.

Requirements & constraints:

• Deploy SQL models, LookML, Power BI datasets safely with traceability, automated tests, approvals, quick rollback, and monitoring.
• Use git, CI server (GitHub Actions/GitLab CI), dbt for SQL models, Looker CI/CD (LookML via git), Power BI REST/ALM APIs or Power BI deployment pipelines.

Branching strategy:

• Trunk-based with short-lived feature branches:
  • main (protected) — always releasable
  • feature/* — dev work, PRs to main
  • release/* (optional) — created for scheduled releases or hotfixes
• Enforce PRs, code owners for LookML/Power BI, required CI passing.

Automated CI pipeline (on PR):

1. Lint & static checks
   • SQL/LookML linters, Power BI file validations (pbix schema checks).
2. Unit & data contract tests
   • dbt tests: schema, uniqueness, not_null, relationships.
   • LookML validation (lookml-validator).
   • Power BI: check dataset schema vs expected metadata (column names/types).
3. Sample-run integration
   • Run dbt models on a lightweight test DB or ephemeral schema; run key LookML explores and sample queries; validate model outputs exist.
4. Regression data tests
   • Compare key aggregate metrics against baseline snapshot using safe thresholds (e.g., total_users delta <= 5%).
   • SQL-based regression queries in CI: run previous production query and compare against feature branch output for sample window.
5. Data quality anomaly detectors
   • Run row-count, null-rate, freshness checks; fail if outside bounds.

Approval gates & release:

• PR review by BI peers + stakeholder sign-off for business-critical dashboards.
• Auto-merge only when CI passes and approvals obtained.
• Deploy to staging workspace first:
  • Run full integration tests against staging data.
  • Run automated smoke tests: top N dashboards render, key visual counts match.
  • Optional UAT sign-off from product owner.
• Schedule production deployment windows; use deployment automation:
  • dbt: run models in production with tags to limit impact.
  • Looker: use git push + Looker deploy (or SDK) to production.
  • Power BI: use REST API/Deployment Pipeline to promote datasets + reports.

Rollback strategies:

• Atomic deploys and versioning:
  • All artifacts tagged in git with release tag.
  • dbt: keep historical models; use job to revert to previous DAG by re-running previous tagged models.
  • LookML: revert to previous git tag and redeploy.
  • Power BI: maintain versioned workspaces/backups (export pbix), ability to re-import previous pbix via API.
• Feature flags & soft launch:
  • For major metric changes, gate dashboards via parameterized dataset filters or workspace forks for limited users.
• Quick DB-level fallback:
  • If a SQL model causes incorrect aggregates, run emergency job to switch BI views to a stable materialized table snapshot.
• Document runbook for rollback steps and automate with scripts in CI.

Post-deploy monitoring & alerting:

• Automated post-deploy test job (immediate):
  • Run key query diffs vs production baseline; check SLA metrics (row counts, totals, top-k lists).
  • Snapshot screenshots of critical dashboards (visual regression) and compare hashes.
• Ongoing monitoring:
  • Data freshness (latency) metrics per dataset.
  • Business metric monitors (percent change alerts, anomaly detection using simple statistical thresholds or ML).
  • Observability: logs for failed refreshes, API errors, job durations; push to PagerDuty/Slack.
• Dashboards and SLOs:
  • BI Observability dashboard: last refresh, failures in last 24h, key metric deltas.
  • Define SLOs (e.g., <1% deviation in daily revenue; <30m refresh lag).
• Post-deploy review:
  • Automated report emailed to stakeholders summarizing tests, metric deltas, and anomalies during first 24h.

Example tests (concrete):

• SQL regression: SELECT COUNT(*) FROM model WHERE event_date BETWEEN X AND Y; assert delta <= 2%.
• Business sanity: SELECT SUM(revenue) FROM sales WHERE date = yesterday; assert value within historical mean ±3σ.
• LookML explore smoke: run a saved query and assert non-empty results.
• Power BI dataset schema test: ensure columns expected_by_report ⊆ actual_columns.

Trade-offs & notes:

• Full production run in CI is expensive — use staged or sampled data for PR; run full tests in staging pre-prod.
• Balance speed vs safety with release cadence; automate as much as possible to reduce human error.
• Maintain clear ownership and runbooks so on-call knows rollback & mitigation steps.

This workflow provides end-to-end safety: automated validation, stakeholder approvals, controlled promotion, quick rollback, and strong post-deploy observability tailored to BI artifacts.

The core move is decoupling what stakeholders need right now from what the fully correct pipeline will eventually produce, and treating those as two parallel, explicitly labeled tracks rather than one thing you're rushing. The interim number isn't a rough draft of the real number, it's a different artifact with its own documented accuracy bounds, and stakeholders need to know which one they're looking at every time they see it.

Step 1: scope the interim approximation to something buildable in days, not weeks, using data or logic already available even if it isn't the eventual source of truth. If the request is a new customer lifetime value by segment metric that needs a proper backend pipeline joining five systems, an estimated 5 weeks of engineering, the interim version might be a manual pull from the two systems that already have clean, joinable data, covering maybe 70% of customers, computed with a simpler formula (average order value times observed purchase frequency, rather than the full cohort-survival model the real pipeline will use). That's buildable in 2 to 3 days by one analyst.

Step 2: validate and document the interim approach's accuracy honestly, on a stated basis, before handing it to stakeholders. Pull a sample where both the quick method and something closer to ground truth are computable by hand, say 40 customers whose full value you can manually trace, and report the interim method's error against that sample as a labeled range, for instance "the interim estimate ran 8 to 15 percent below the manually verified figure across the sample, likely because it excludes returning customers acquired through the two systems not yet joined." Stating both the direction and the likely cause of the gap is what makes the number usable instead of just a hedge.

Step 3: document the risk of relying on the interim number in writing, not just verbally, and route it through whoever needs to sign off before it reaches decision-makers. If the metric touches anything regulated, pricing, eligibility, anything readable as compliance-relevant even in interim form, run it past legal or compliance in parallel with building the real pipeline, not after: a plausible failure mode is compliance flagging the interim number's use three weeks in, after it's already been relied on, which costs more time than a same-week review would have. The written risk note goes specifically to the business teams who will act on the number, not just to the requester, stating clearly what the number is, what it excludes, its estimated error range, and that it will be replaced.

Step 4: set and hold a specific cutover date, stated when you deliver the interim number, not decided later. Tie it to the real pipeline's actual build estimate (5 weeks here) plus a short validation buffer (3 to 5 days comparing the two methods on live data before fully switching), and put both the interim number's expiration and the real pipeline's target date in the same document the business teams received in step 3, so nobody is surprised when the number changes, and so it doesn't quietly become permanent because nobody set a forcing date.

Applied to a scenario. A growth team asks for time-to-value by acquisition channel, needed for a board deck in one week, but the definitive version requires a new event-tracking pipeline estimated at 5 weeks. The analyst delivers a manual, spreadsheet-based estimate from existing CRM (customer relationship management) exports within 3 days, validates it against a 40-account hand check (error band: 8 to 15 percent low, likely undercounting a channel where activation happens outside the tracked funnel), routes a one-paragraph risk note through the data governance lead in parallel, approved in 2 days with no blocking issue found, and documents a cutover date of week 6, with both numbers appearing side by side in that week's report so stakeholders see the interim estimate get replaced rather than silently disappear.

The same shape holds outside data work: a solutions architect quoting a client an interim SLA (service level agreement) estimate from a partial benchmark, while the full load-tested benchmark is still weeks out, needs the identical discipline, a labeled error range, a written risk note to whoever's relying on the number, and a stated date the real benchmark replaces it.

The common mediocre answer delivers the quick number without stating its error bounds or basis, which reads as confident precision it doesn't have, and skips the parallel compliance check because "it's just an interim number," exactly the reasoning that turns a 3-day estimate into a 3-week fire drill when someone downstream treats it as final and compliance finds out after the fact.

Direct answer

ON DELETE/ON UPDATE actions decide what happens to a dependent row when the row it references is deleted or its key changes: CASCADE propagates the change, SET NULL clears the reference, and RESTRICT/NO ACTION block the change entirely while any dependent rows exist; the right choice depends on whether the dependent row's existence is meaningful without its parent.

Structured elaboration

• CASCADE: deleting a users row also deletes all of that user's orders. Appropriate when the dependent row has no independent meaning without its parent (a user's shopping-cart items, say), but dangerous when the dependent rows themselves have standalone business value (deleting a user should probably not silently delete their entire order history).
• SET NULL: deleting a users row sets orders.referred_by_user_id to NULL instead of deleting the order. Appropriate when the reference is informational, not load-bearing (knowing who referred a customer is nice to have, but an order remains a valid, meaningful record even if the referrer's account is later deleted).
• RESTRICT/NO ACTION: block the delete entirely while any referencing row exists, forcing an explicit decision (reassign or manually remove the dependents first). Appropriate as the default for anything financially or legally significant, where a cascading or silently-nulled deletion could quietly destroy or corrupt a record that must be preserved.

Worked example

For users and orders: orders.user_id should almost certainly be RESTRICT or NO ACTION, not CASCADE, because deleting a user account should never silently delete their entire purchase and payment history; the correct operational flow is to first decide what happens to their orders (anonymize, reassign to a "deleted user" placeholder, or archive them) as an explicit step, not as an automatic side effect of the account deletion. By contrast, cart_items.cart_id referencing a carts row is a reasonable CASCADE: an abandoned cart's line items have no independent meaning once the cart itself is gone.

Trade-offs and pitfalls

• The main operational risk of CASCADE is exactly the "accidental mass-delete" scenario: deleting one row at the top of a deep reference chain can silently delete thousands of rows across many tables with no confirmation step, which is especially dangerous when the cascade chain is several levels deep and not all of it is obvious to whoever issued the original delete.
• Preventing accidental mass-deletes: default to RESTRICT for anything where deletion should require an explicit, reviewed decision, reserve CASCADE for genuinely dependent, no-independent-value child rows, and consider soft-deletes (an is_active/deleted_at flag, with no ON DELETE action ever firing because rows are never physically deleted) for anything where the safest default is "never let this disappear automatically at all."
• SET NULL requires the foreign-key column to be nullable, which is easy to overlook when initially defining the column as NOT NULL for data-quality reasons; if SET NULL is the intended behavior, the column's nullability constraint has to be designed for it from the start, not bolted on later.

Direct answer

A silent numeric error discovered weeks or months after the fact requires an incident-response structure with five distinct phases, run roughly in this order but with real overlap: scope the blast radius, quantify business impact, design and validate a backfill, communicate to stakeholders, and put a systemic (not just local) prevention in place.

Structured elaboration

• Scoping: determine exactly which date range, which tables, and which downstream consumers (dashboards, models, exports) were affected. This is often harder than the fix itself, because a bug that has been running for weeks has usually propagated into multiple derived tables, not just the one where it originated.
• Business impact: quantify the actual magnitude, not just "revenue was undercounted," but by how much, on which days, and whether any downstream decision (a forecast, a board number, a customer-facing calculation) was made using the bad data.
• Backfill design and validation: reprocess the affected range from the earliest untouched upstream source, not from the already-corrupted derived tables, and validate the backfilled numbers against an independent source (a finance export, a source-system total) before republishing, never trust the backfill just because the code change looks correct.
• Communication: tell stakeholders and, where financial or compliance-relevant, auditors, what the discrepancy was, its magnitude and duration, and what was corrected, before they discover the historical numbers changed on their own.
• Systemic prevention: the specific bug (a bad join, a rounding error) gets fixed, but the durable prevention is a class of automated check, for example a schema-assertion test or a reconciliation check running continuously, that would have caught this specific class of silent error within hours rather than weeks.

Worked example

A currency-conversion rounding bug accumulates a small error on every transaction, drifting a consolidated reporting total by $50,000 over several months before anyone notices, because each individual transaction's error is too small to trip any single-record validity check. The fix is not just correcting the rounding logic going forward, it requires backfilling every affected historical aggregate using the corrected logic, reconciling the backfilled totals against the audited books, and explicitly disclosing the correction to whoever relied on the pre-correction numbers, including, in this case, external auditors.

Trade-offs and pitfalls

The biggest risk in this whole process is moving too fast on the backfill: a corrected pipeline pushed live before its output has been validated against an independent source can introduce a second, different silent error on top of the first, and because trust in the numbers is already shaken, a second undetected error here is much more damaging than the original bug. Validate before you republish, every time, even under pressure to fix the dashboard quickly.

Direct answer

Keep a stalled dependency peer-to-peer as long as direct conversation is still making progress. Escalate when you hit a concrete trigger: a scope change that neither side can unilaterally absorb, genuinely conflicting priorities that only someone with visibility into both roadmaps can arbitrate, or a hard deadline-driven blocker where peer-to-peer conversation has already stalled.

Framework

Default: work it peer-to-peer. Most stalls are under-communication or unclear ownership, and a direct conversation or a short written proposal usually unsticks them without anyone else getting involved.

Concrete triggers to escalate.

• Scope change: the fix now requires work neither team budgeted for, and only a manager can reprioritize that.
• Conflicting priorities: both sides are acting rationally from their own team's goals, and the trade-off needs someone with visibility into both roadmaps to arbitrate.
• Hard blocker with a deadline: a fixed external date is genuinely at risk, and peer-to-peer conversation has already stalled past a reasonable window, for example no movement after two direct attempts over several days.
• Repeated pattern: the same kind of stall keeps recurring with the same team, which means the real issue is the working relationship or process, not this one dependency.

What to bring when you escalate. A short brief: what's blocked, what you've already tried peer-to-peer, the realistic options and their trade-offs, and the specific decision you need.

Worked example (applying the criteria)

Situation: your team's deliverable needs a schema change from another team that they've deprioritized for two weeks despite two direct requests.
Applying the criteria: this isn't just a communication gap, direct conversation was already tried twice with no movement. It's a conflicting-priorities case, the other team's roadmap has no room for this without reprioritizing something else, combined with a hard blocker, a fixed external deadline in three weeks that this schema change sits on the critical path for (meaning if this dependency slips, the final deadline slips by the same amount, unlike a dependency with buffer to absorb delay).
Action: escalated to the shared manager with a one-page brief covering what's blocked, the two peer-to-peer attempts and their outcome, and two options: the other team reprioritizes one sprint of work, or your team ships a temporary workaround with known limitations, along with the deadline risk if neither happens within the week.
Result: the shared manager reprioritized one sprint item, unblocking the schema change with two weeks to spare before the deadline. Both teams also agreed to flag scope-affecting asks earlier next time, so the same dependency doesn't reach this point again.

Trade-offs and pitfalls

• Escalating too early over normal friction burns trust and reads as an inability to work horizontally.
• Escalating too late, repeatedly trying peer-to-peer past the point it's actually working, puts the deadline at real risk and looks like poor judgment in hindsight.
• A vague escalation with no options and no specific ask wastes the leader's time compared with a brief that names the decision needed.

Direct answer
Detecting a structural break means testing whether a series' underlying parameters (mean, trend, variance) shifted at some point, using methods like the Chow test (tests a hypothesized break date), CUSUM (accumulates deviations to flag a sustained shift), or Bayesian change point detection (estimates a posterior distribution over where a break most likely occurred); attributing the break to a specific cause (like a pricing change) versus a coincident event requires comparing the break's timing and shape against what you'd expect that specific cause to produce, ideally with a control series that wasn't exposed to the same cause.

Structured elaboration

• Chow test: tests a SPECIFIC, pre-specified candidate break date by comparing the fit of one regression over the whole series against two separate regressions split at that date; an F-test determines whether the split significantly improves fit. Use it when you already have a hypothesis for WHEN the break happened (e.g. the exact date of a pricing change).
• CUSUM: accumulates signed deviations from a reference/target value over time and flags when the cumulative sum crosses a threshold; naturally suited to detecting a SUSTAINED shift (as opposed to a single outlier), and doesn't require knowing the break date in advance.
• Bayesian change point detection: puts a prior over possible break locations (and possibly the number of breaks) and returns a posterior distribution, which is useful when you're not confident there's exactly one break, or want an honest measure of uncertainty about WHERE the break occurred rather than a single point estimate.
• Attributing the break to pricing vs a coincident event: check whether the break's TIMING lines up precisely with the pricing change date (a break that starts 3 weeks before the price change is a red flag that something else is driving it); check whether the break's DIRECTION and MAGNITUDE make sense for the mechanism (a price increase should plausibly reduce volume, not increase it, absent some other explanation); and, most powerfully, compare against a CONTROL series not exposed to the pricing change (a comparable product/region where price didn't change) - if the control also shows a break at the same time, the true cause is more likely something coincident (a seasonal event, a macro shift) than the pricing change itself.

Worked example (executed)
Run against a synthetic 300-point series (seed=0) with an abrupt level shift of +5 at index 100, followed by a separate GRADUAL linear ramp of +5 starting at index 200 and completing by index 300, both with unit-variance Gaussian noise:

import numpy as np, ruptures as rpt
np.random.seed(0)
n = 300
x = np.zeros(n)
x[:100] = np.random.normal(0, 1, 100)
x[100:200] = np.random.normal(5, 1, 100)
ramp = np.linspace(0, 5, 100)
x[200:300] = 5 + ramp + np.random.normal(0, 1, 100)
algo = rpt.Pelt(model="rbf").fit(x.reshape(-1, 1))
result = algo.predict(pen=10)
print("result =", result)

Executed output: result = [100, 235, 300]. PELT located the abrupt shift's true onset (index 100) EXACTLY, but only flagged the gradual ramp at index 235 - thirty-five periods after its true onset at index 200 - a genuine, informative result: algorithms tuned for abrupt shifts (Chow test at a hypothesized date, standard CUSUM/PELT) can systematically under-detect or mis-locate a GRADUAL regime change, since there's no single sharp point where the "before" and "after" distributions are maximally separated. If a pricing change caused a gradual behavioral adaptation rather than an immediate jump, methods built around detecting sharp breaks will underperform, and a trend-based or rolling-regression approach may localize the shift better.

Trade-offs & pitfalls
At the scale of many series at once (e.g. 10 million SKU-store combinations), running full changepoint detection on every series individually is computationally prohibitive; a practical architecture screens cheaply first (a simple rolling-mean-shift heuristic) and reserves the expensive Bayesian/PELT-style methods for the subset flagged as plausible candidates, with human review prioritized toward breaks that are both large in magnitude AND business-critical, rather than trying to review every detected break. After a deployment or pricing change specifically, build the investigation triage into a repeatable runbook (a rollback threshold, a standard set of first checks) rather than an ad hoc analysis each time, since "did our recent change cause this" is a recurring question, not a one-off.