Amazon Business Intelligence Analyst Interview Preparation Guide - Senior Level

Direct answer

The pyramid principle says to structure a data narrative top-down: state your main conclusion first, then the two or three arguments that support it, then the evidence beneath each argument, rather than building up to the conclusion the way you actually did the analysis. The closely related SCQA shape (Situation, Complication, Question, Answer) is a way to construct that top line: state the shared context, name what changed or went wrong, pose the question that creates, then answer it, with the Answer being the same headline the pyramid puts first.

Structured elaboration

1. Why top-down beats bottom-up for a busy decision-maker.
Analysis is naturally built bottom-up: you gather data, run tests, notice patterns, and arrive at a conclusion at the end of that process. But a decision-maker reading or hearing the result does not have time to retrace that path and does not need to; they need the conclusion first so they can decide how much of the supporting detail they actually want. Presenting bottom-up (data first, conclusion last) forces every reader to sit through the full derivation before learning the point, and it means anyone who stops reading after the first paragraph, which is common in a busy inbox or meeting, misses the actual finding.

2. The pyramid's three layers.
At the top: a single governing conclusion or recommendation, stated as a complete sentence, not a topic label ('Churn is a problem' is a topic; 'Churn among enterprise accounts rose 4 points last quarter and threatens renewal revenue, we recommend X' is a conclusion). In the middle: two to four supporting arguments, each one a reason the top conclusion is true, ideally grouped so they are mutually exclusive and collectively exhaustive of the case you're making, not an arbitrary list. At the base: the specific evidence, numbers, and analysis behind each supporting argument, which is where the detail-oriented reader or a skeptical stakeholder can drill in.

3. The SCQA framing for arriving at that top line.
Situation: state the shared, uncontested context ("Enterprise renewal rates have been stable around 92% for six quarters"). Complication: name what changed or what tension that creates ("This quarter renewal dropped to 88%, concentrated in accounts onboarded in the last year"). Question: the natural question the complication raises ("What's driving the drop, and can we intervene before renewal season peaks?"). Answer: your actual conclusion and recommendation, which becomes the pyramid's top line. SCQA is really a technique for constructing a compelling, honest top line; the pyramid is what you do with that top line once you have it.

4. Restructuring a bottom-up finding into this shape.
Take the order you actually worked in (data pull, exploratory checks, a few dead ends, the eventual pattern, the conclusion) and literally invert it for the write-up: conclusion first, then the two or three strongest reasons, then evidence for each reason. The dead ends and exploratory detours from your real process almost never belong in the final artifact at all; they belong in an appendix or nowhere, because the pyramid is a communication structure, not a lab notebook.

Worked example

An analyst investigates a support-ticket increase by pulling ticket volume by category, checking for a recent product release, cross-referencing with a signup cohort analysis, and eventually finding the pattern. Built bottom-up, the write-up would read: "We pulled ticket data for the last 90 days... we checked release notes... we then looked at signups by cohort... and found that tickets from users onboarded after the March release are 3x more likely to file a billing-related ticket." Restructured with the pyramid/SCQA shape: Situation/Answer-first: "Billing-related support tickets are up 40% quarter over quarter, driven almost entirely by users onboarded after the March release; we recommend a fix to the new billing confirmation step before the next release." Supporting arguments: (1) users onboarded after March file billing tickets at 3x the rate of earlier cohorts, (2) the March release changed the billing confirmation flow, (3) no other cohort or category shows a comparable increase, ruling out a general support-quality issue. Evidence for each argument follows beneath, in the same order, for the reader who wants to verify the claim rather than just act on it.

Trade-offs and pitfalls

• The most common mistake is writing the top line as a topic ("Q3 billing tickets") instead of a complete, decision-relevant sentence with a conclusion in it; a topic doesn't tell the reader anything they can act on.
• Forcing every supporting argument to be truly independent (mutually exclusive) takes real editing; a first draft often has 4-5 overlapping points that should collapse into 2-3 distinct ones.
• The pyramid structure is not a license to omit genuine uncertainty or counter-evidence; the top line should still be honest about confidence and limitations, not just punchy.
• Over-applying the framework to a finding that genuinely has no single clear conclusion (a mixed or inconclusive result) produces a false sense of clarity; in that case the honest top line states the ambiguity itself as the headline, rather than forcing a decisive-sounding conclusion the evidence doesn't support.

1. Difference-in-Differences (DiD)

• What: Compare before/after change for treated group vs control group: (Y_treated_post - Y_treated_pre) - (Y_control_post - Y_control_pre).
• Key assumptions: parallel trends (in absence of treatment both groups would follow same trend), no spillovers.
• How to validate with BI data: plot pre-treatment time series on dashboards for both groups (event-study plot) to visually check parallel trends; formally run placebo DiD using only pre-periods to test zero effect; check for contemporaneous shocks by comparing other metrics (falsification outcomes). Use SQL to build cohort time-series and compute standardized differences.

2. Synthetic Control

• What: Construct a weighted combination of donor units that best matches treated unit’s pre-treatment trajectory; use that synthetic control as counterfactual.
• Key assumptions: donor pool contains combinations that can reproduce pre-treatment path; no interference.
• How to validate with BI data: assess pre-treatment fit via RMSPE (dashboard showing treated vs synthetic); conduct placebo (permutation) tests by applying method to donors and comparing post/pre RMSPE ratios; inspect weight composition and ensure donors are plausible (same market, size). Use BI-generated time-series and covariates to choose donors.

3. Propensity Score Matching (PSM)

• What: Match treated units to control units with similar propensity to be treated (based on observables), then compare outcomes.
• Key assumptions: selection on observables (no unobserved confounders), common support/overlap.
• How to validate with BI data: estimate propensity model (logistic regression) using BI data (demographics, usage, historical metrics), then check covariate balance after matching (standardized mean differences, love plots) in dashboards; verify overlap by plotting propensity score distributions; run sensitivity analyses (Rosenbaum bounds) and compare results across matching methods (nearest neighbor, caliper, weighting).

General checks across methods: pre-post placebo tests, falsification outcomes, robustness to alternative windows, segmented analyses (by region/product) via BI dashboards, and reporting uncertainty (CI, permutation p-values). These validations use SQL extracts, time-series visualizations in Tableau/Looker, and automated BI reports to make assumptions transparent to stakeholders.

Start with a hypothesis-driven, checklist-style investigation that separates ETL bug, instrumentation loss, or real-user change.

Immediate context & scope

• Confirm metric definition: DAU = unique user_id with event X between 00:00–23:59 UTC? Which event(s) count as "active"?
• Confirm time windows: compare yesterday vs. baseline (7d avg, 28d avg, same weekday last week).

Raw counts and quick comparisons (run first)

• Count unique user_id in raw event table (pre-ETL) for yesterday and baseline.
• Count unique user_id in staging/processed table (post-ETL) for same period.
• Count total events (all types) raw vs processed for yesterday and baseline.
• Compare ingestion counts by source (mobile iOS, Android, web).

Query comparisons / diffs

• Run SELECT COUNT(DISTINCT user_id) FROM raw_events WHERE date = y and compare to processed table result.
• Run LEFT JOIN raw -> processed on primary key to find dropped rows: SELECT COUNT(*) WHERE raw.id IS NOT NULL AND proc.id IS NULL.
• Compare event-level aggregates by hour to see when drop started.

Logs & pipelines

• Check ETL job run status, start/end times, and error logs for yesterday’s run.
• Inspect CDC / ingestion logs for backlog, throttling, or missing partitions.
• Review schema-change logs/PRs deployed yesterday (migration, column rename, partition change).
• Check data freshness/latency alerts and any retry/failure rates.

Schema & transformation checks

• Validate schema in raw vs staging vs warehouse: missing columns, type changes, new NOT NULL constraints.
• Confirm partitioning keys and dates used by job (off-by-one partition bug).
• Check recent commits to transformation code: filtering conditions, join keys, dedup logic.

Instrumentation & client-side checks

• Compare SDK/telemetry versions by user agent; check mobile crash or rollout notes.
• Validate that event names or user_id fields weren't renamed at source.
• Check for upstream feature flags or releases that disabled events.

Quick heuristics to decide cause

• If raw counts are normal but processed counts low -> ETL/transformation bug.
• If raw counts low too -> instrumentation or real behaviour (check client deploys, network outage).
• If drop abrupt by hour and corresponds to a deploy -> likely instrumentation/SDK or ETL deploy.
• If drop gradual and across segments -> possible real behavior change; correlate with marketing, outages, or external events.

Next steps & mitigation

• If ETL bug: backfill missing partition, re-run job, validate counts, communicate fix and re-run SLA.
• If instrumentation: coordinate with engineering to roll back/push fix; estimate data loss window and consider reconstruction from client logs if available.
• If real change: run segmentation (cohort, geography, platform) and inform stakeholders with impact analysis and recommended actions.

Communicate

• Produce an incident note with root-cause hypothesis, supporting query outputs, mitigation steps, and timeline for next updates.

Direct answer. The most plausible causes are that the two connections are actually hitting different underlying data (a lagging or differently-tuned replica), that the replica's statistics are stale relative to the primary's, or that a configuration difference between the two (memory settings, cost parameters) leads the same query to a genuinely different plan; isolate which one by comparing statistics freshness, configuration, and data currency between the two connections directly, rather than assuming the query itself is the variable.

Structured elaboration. Start by confirming the two connections are even hitting the same DATA: replication lag means a replica can be seconds, minutes, or more behind the primary, and while that usually doesn't change PLAN shape by itself, it's worth ruling out as a confounding factor before you go further, since a stale replica muddies any comparison you make. Next, compare statistics freshness on the specific tables involved: if the replica's statistics were refreshed at a different time (or on a different schedule) than the primary's, or if statistics don't replicate identically depending on your engine's replication mechanism, the two connections can genuinely be planning from different information even though the underlying schema and data are notionally "the same." Finally, compare configuration directly: a replica provisioned with different memory settings, different cost-model parameters, or even a different engine version can lead an otherwise-identical query to a genuinely different, and genuinely differently-optimal, plan.

Worked example. A replica whose statistics job runs on a different, less frequent schedule than the primary's is a very plausible explanation on its own: if the primary was recently ANALYZE'd after a data shift but the replica hasn't caught up yet, the replica's optimizer is working from an older picture of the data than the primary's, which can easily produce a different (and worse) plan for the identical query text.

Trade-offs and pitfalls. Resist jumping straight to "the replica's hardware must just be slower," which is possible but is a much less common actual cause than a genuine statistics or configuration difference, and treating it as the default explanation without checking the more likely causes first can send you chasing an infrastructure upgrade that wouldn't have fixed the real problem.

Direct answer. A semi-join answers "does at least one matching row exist," returning each left-side row at most once. An anti-join answers the opposite: "does NO matching row exist." Neither one pulls any columns from the other side, which is what makes them cheaper and safer than a regular join for a pure existence check.

Structured elaboration. A regular INNER JOIN, by contrast, returns one row per MATCH, not per left-side row: if a customer has five qualifying transactions, an INNER JOIN returns that customer five times, and you'd need a DISTINCT (or a GROUP BY) afterward to get back to one row per customer. EXISTS expresses the semi-join directly: the database can stop scanning the right side the instant it finds one match, because it never needs to know how many matches there are or fetch any of their columns.

Worked example. Consider customers(customer_id) and transactions(customer_id, amount), and the question "which customers have at least one transaction over $500?"

-- semi-join via EXISTS: one row per qualifying customer, regardless of match count
SELECT c.customer_id
FROM customers c
WHERE EXISTS (
  SELECT 1 FROM transactions t
  WHERE t.customer_id = c.customer_id AND t.amount > 500
);

-- the join-then-distinct alternative, doing more work for the same answer
SELECT DISTINCT c.customer_id
FROM customers c
JOIN transactions t ON t.customer_id = c.customer_id AND t.amount > 500;

Both return the same set of customer_ids. The EXISTS version never has to materialize or deduplicate the (potentially many) matching transaction rows; the JOIN + DISTINCT version does the work of producing every match and then throwing most of it away.

Trade-offs and pitfalls. The performance gap widens as the number of matches per left-row grows: a customer with 10,000 qualifying transactions costs the JOIN version 10,000 rows to produce and then collapse, versus one early-exit check for EXISTS. The same semi-join pattern generalizes to combined conditions across multiple tables, for example excluding a customer if they match EITHER of two separate exclusion tables, which is naturally expressed as two EXISTS (or NOT EXISTS) clauses ORed or ANDed together rather than as extra joins that would otherwise multiply rows across both tables at once.

Direct answer
When a mentee gets defensive and stops acting on feedback, the fastest way to make it worse is to double down with more direct feedback. Slow down, diagnose why the message isn't landing (the content, the delivery, or something the mentee brings into the room), then rebuild the conversation as a two-way one instead of a one-way correction. If the pattern doesn't shift after a genuine attempt at that, it needs to be named and escalated, not quietly tolerated.

Diagnose before you re-deliver

• Separate "defensive because of how I said it" from "defensive because of what's underneath it." Workload, unclear expectations, a confidence hit, or feedback that reads as a character judgment rather than a specific behavior all produce the same surface symptom (pushback, non-action) for different reasons.
• Ask, don't assume: open with a genuinely curious question rather than a repeat of the critique. "Walk me through how that landed for you" gets you information; "you need to stop being defensive" gets you more defensiveness.

Use motivational interviewing instead of more direct pressure

• Motivational interviewing is built for exactly this: someone who may intellectually agree but is resisting behaviorally. Instead of arguing for the change, reflect their own stated goals back to them and let them articulate the gap ("You mentioned you want to lead the next project. How does this pattern affect that?"). People act on reasons they generate themselves far more than reasons handed to them.
• Keep the ratio of affirmation to correction visible. If every interaction is corrective, the mentee starts hearing footsteps before you speak, which is what produces reflexive defensiveness.

Rebuild the mechanism, not just the next conversation

• Shrink the ask: instead of a broad critique, propose one small, concrete, reversible change and a short check-in window.
• Make feedback bidirectional: ask what kind of feedback has landed well for them before, and adjust format (written vs. verbal, immediate vs. batched) accordingly.

Know when coaching has run its course

• If, after two or three honest attempts using the above, the pattern is unchanged (commitments still not acted on, same defensiveness), that's a signal the issue may be outside what coaching alone fixes: a skill gap being misread as attitude, a values or fit mismatch, or a factor you're not positioned to see.
• At that point, loop in the mentee's manager, or HR if the dynamic has become adversarial, rather than continuing to privately absorb it. Frame it factually: what you tried, what changed, what didn't. This isn't giving up on the mentee; it's recognizing some situations need authority or context you don't have.

Worked example
A mentee kept missing agreed follow-ups on code review comments and would get visibly short in Slack whenever it came up. The instinct was to restate the same feedback more firmly. Instead, the better move: open the next 1:1 with "I want to understand how the review feedback has been landing for you, not go through it again," and listen first. It turned out the mentee had inherited a legacy module nobody had explained well, and every review comment felt like it was pointing out someone else's mess. The fix wasn't more feedback, it was pairing on the module once and shrinking the ask to one file at a time. If that hadn't worked, the next honest step would have been raising the pattern with the mentee's manager, not repeating the same conversation a fourth time.

Trade-offs and pitfalls

• The junior mistake is treating defensiveness as a discipline problem and pushing harder; that reliably produces more resistance, not less.
• Over-correcting the other way (going silent on real issues to avoid triggering defensiveness) just delays the same conversation and lets performance drift.
• Escalating too early, before you've tried adjusting your own approach, reads as offloading a coaching problem; escalating too late lets a stalled dynamic damage trust or delivery. The senior move is trying a genuine adaptation first, timeboxing it, and being honest about whether it moved anything.

Direct answer

Add new attributes as nullable columns (backfilling historical rows where feasible, leaving them NULL for older rows where not), change a data type only through an explicit, tested migration step (never an in-place silent type change), and retire columns by first marking them deprecated and hiding them from new queries via a view, before physically dropping them once confirmed unused, keeping every step backward-compatible for existing reports throughout.

Structured elaboration

• Adding new attributes: add as a nullable column; for a Type 2 dimension, decide whether the new attribute should be tracked historically (Type 2) or is only meaningful going forward (fine to backfill as NULL for historical rows and only populate for new versions).
• Changing a column's data type: never change a live column's type in place without a tested migration; instead, add a new column with the target type, backfill and validate it against the old column, switch downstream consumers over, then retire the old column, mirroring the same phased approach as retiring a column outright.
• Retiring columns: mark deprecated (documented, communicated to known consumers) before removing; expose a compatibility view that still presents the old column (perhaps computed from its replacement, or simply frozen) for a transition window, so existing reports don't break the moment the underlying column is dropped.
• Migration planning and testing: for any of these changes, test against a realistic subset of production data first, and validate that existing reports produce identical output before and after the change, the same validate-before-cutover discipline used in any dimensional-model migration.

Worked example

Adding a loyalty_tier attribute to customer_dim: added as a new nullable column, backfilled where source data allows, left NULL for historical rows predating loyalty-tier tracking, and downstream reports referencing it are built to handle NULLs gracefully (treating them as "unknown" rather than crashing or silently defaulting to a specific tier). Retiring a legacy old_segment_code column: first replaced by a segment column with a compatibility view mapping the two for existing reports, given a defined deprecation window, and only physically dropped after confirming (via query logs) that nothing still references it directly.

Trade-offs and pitfalls

The riskiest version of any of these changes is an in-place type change or a column drop with no transition period, which can silently break downstream reports the moment it ships, discovered only when a stakeholder notices a dashboard error or, worse, doesn't notice a silently wrong number. The phased, backward-compatible approach costs more calendar time and requires tracking column usage across consumers, but avoids breaking changes shipping without warning.

Direct answer: Compute the metric with small-segment counts suppressed or noised (via a minimum-cell-size threshold and/or differential-privacy noise) rather than shown exactly, and choose the specific technique based on how small the segments realistically get and how much accuracy loss is acceptable for the metric's actual use case.

Structured elaboration, techniques and their accuracy/privacy trade-off:

• Minimum-cell-size suppression: any segment with fewer than a threshold number of users (e.g., 10) is not shown at all, or is aggregated into a broader "other" bucket. Simple and easy to explain, but a hard cutoff can be gamed or can hide genuinely interesting outlier segments entirely, and provides no formal privacy guarantee (a persistent, sophisticated adversary combining multiple slightly-different queries could still sometimes infer a small segment's true value).
• Differential privacy (DP) noise: add calibrated random noise to a count before it's exposed, providing a formal, mathematically provable privacy guarantee (bounding how much any single individual's presence/absence can affect the reported number) regardless of how the data is subsequently sliced or combined; the cost is a small, quantifiable accuracy loss on every reported number, including large segments, not just small ones, and it requires actual expertise to calibrate correctly (the "privacy budget" and noise scale).
• Aggregation-only reporting: never expose the raw segment breakdown at all, only a coarser rollup, sacrificing drill-down capability entirely in exchange for the simplest possible protection.
• k-anonymity style generalization: replace a fine-grained segment definition with a coarser one until each group has at least k members (e.g., collapsing a rare country into a regional bucket), preserving some analytical value while eliminating the smallest, most re-identifiable groups.

Worked example: a "unique users per country" metric, where several countries have very few users, computed with HLL-based approximate counting (S52) PLUS a small amount of differential-privacy noise added to each country's count before reporting, protects against re-identifying a specific individual in a tiny-population country while keeping large-country counts nearly exact (the DP noise's relative impact shrinks as the true count grows); a purely suppression-based alternative would instead simply hide any country below a threshold entirely, losing all visibility into those markets rather than providing an approximate, privacy-safe number.

Trade-offs & pitfalls: DP noise is the most rigorous option but is also the easiest to get wrong (miscalibrated noise either fails to protect privacy meaningfully or destroys the metric's usefulness); minimum-cell suppression is easier to implement correctly but provides a weaker, non-formal guarantee and can create confusing gaps in a report ("why is this segment just... missing"). Choose based on the actual sensitivity of the data and the sophistication of the threat model: internal-only reporting with a trusted, small audience may reasonably use simple suppression, while any externally-shared or highly sensitive breakdown warrants the stronger DP guarantee despite its added complexity.

Direct answer. An automated hot-spot mitigation subsystem needs three cooperating pieces: a detector that finds skew reliably and quickly, a rebalancer that moves load without losing or duplicating data, and a set of safety checks that stop the system from making things worse -- the hard engineering is almost entirely in the safety checks, since detection and rebalancing are each individually well-understood.

Structured elaboration.

1. Detection heuristics. Track per-partition throughput and latency as a rolling window (not an instantaneous snapshot, which is noisy) and flag a partition when its share of total traffic sustainedly exceeds a threshold relative to an even split (e.g., 3x the median for more than N consecutive windows). Use a sustained-duration requirement specifically to avoid reacting to short-lived, self-resolving spikes -- an automated system that rebalances on every transient blip creates more instability than it prevents.
2. Rebalancing technique. For a system that can tolerate it, salting the detected hot key (appending a bounded suffix so its traffic spreads across multiple partitions) is the least disruptive fix: it does not require moving already-written data, only affects the routing of NEW writes for that key going forward. Full repartitioning (splitting a partition's existing data across new partitions) is more invasive and should be reserved for cases where salting is insufficient (e.g., the hot partition is ALREADY overloaded with existing state, not just incoming writes). Both techniques must preserve availability throughout, which is a hard requirement, not a nice-to-have: salting gets this for free, since it never touches or locks already-written data; full repartitioning has to earn it deliberately via copy-then-cutover (the source partition keeps serving reads and writes for the ENTIRE copy, and only the routing table flips once the copy is verified complete), never a stop-the-world move that takes the partition offline.
3. Safety checks, which are the real design challenge: (a) a rate limit on how many keys/partitions the system will rebalance per time window, so a bug or a false-positive storm cannot trigger a cluster-wide reshuffle at once; (b) a dry-run/shadow mode that computes what the rebalance WOULD do and compares predicted post-rebalance distribution against actual, before committing; (c) an automatic rollback trigger if post-rebalance metrics do not improve within a bounded time window; (d) a hard exclusion list for keys where automated salting would break a known ordering requirement (see the ordered-financial-transactions case), since an automated system cannot always infer that requirement from traffic patterns alone.
4. Validation during a rebalance. Before considering a rebalance complete, verify no messages were lost (a before/after count reconciliation for the affected key), that consumers reading the affected partitions have caught up without an unexpected lag spike from the rebalance itself, and that availability held throughout: no elevated read/write error rate or latency spike on the affected partition while the migration was in flight, not just a correct end state. A rebalance that fixes the skew but produced a brief error spike getting there has not actually met the availability requirement.

Worked example. The detector flags a partition sustaining 5x median throughput for 10 consecutive 1-minute windows, attributable to a single key. The system enters shadow mode: it computes the projected distribution if that key were salted into 8 shards and confirms the projected max/median ratio would drop to roughly 1.1-1.3x (consistent with the manual salting technique's own measured effect). It then applies the salt for NEW messages only, monitors the actual post-change distribution for 15 minutes, and confirms via record-count reconciliation that no messages were dropped during the transition. If instead the projected improvement had been marginal (say, the hot key represents 80% of one partition's traffic and salting into 8 shards would still leave each shard hot), the system should escalate to a human rather than apply a rebalance that will not actually fix the problem.

Trade-offs & pitfalls. The single most dangerous failure mode for an automated system like this is a rebalance that appears to work in shadow mode but interacts badly with a downstream consumer's assumptions (e.g., a consumer relying on partition-key correlation for a cache-locality optimization, not correctness) -- since that failure is invisible to a throughput/latency dashboard, the exclusion list and human-escalation path in step 3 above are not optional extras, they are the difference between a useful automation and a production incident generator.

Direct answer
Additive seasonality assumes the seasonal swing is a roughly constant absolute amount regardless of the series' level; multiplicative seasonality assumes it scales proportionally with the level. Choosing the wrong one distorts both baselines (an additive model under-predicts the seasonal swing at a high level, or over-predicts at a low one) and anomaly thresholds (a fixed-width band around an additive baseline will be too tight during high-level periods and too loose during low-level ones).

Structured elaboration

• Additive: $y_t = \text{trend}_t + \text{seasonal}_t + \text{residual}_t$ - the seasonal swing stays roughly the same size in absolute units no matter what the trend level is doing.
• Multiplicative: $y_t = \text{trend}_t \times \text{seasonal}_t \times \text{residual}_t$ - the seasonal swing grows or shrinks proportionally with the trend level; a multiplicative model can be fit as an additive one on the LOG of the series, since $\log(y_t) = \log(\text{trend}_t) + \log(\text{seasonal}_t) + \log(\text{residual}_t)$.
• Which metrics favor which: revenue-style metrics that grow substantially over time, where the seasonal spike naturally grows alongside the business (e.g. a December bump that's proportionally consistent but has grown from $10K to $50K as the business scaled), are usually multiplicative. Metrics with a roughly stable base level and a genuinely fixed-size seasonal effect (e.g. a fixed number of extra support tickets every Monday, regardless of overall ticket volume trend) are more often additive.
• Testing which model fits better: the simplest visual test is whether the peak-to-trough seasonal amplitude visibly GROWS alongside the trend on a raw plot - if it does, additive is the wrong assumption. More formally, fit both, compare residual variance (an additive fit on a genuinely multiplicative series will show residual variance that itself grows with the level, a clear diagnostic on a residual-vs-fitted plot), or simply compare backtested forecast error between the two.
• Why the choice matters for baselines/anomaly detection: an anomaly-detection threshold built on additive-model residuals (e.g. "flag anything more than 3 residual-standard-deviations away") implicitly assumes constant residual variance across the whole series; if the true process is multiplicative, that fixed threshold will be too sensitive (false positives) during low-level periods and too insensitive (missed real anomalies) during high-level periods.

Worked example
Two metrics side by side: daily active users growing from 10,000 to 100,000 over two years, with a weekend dip that's always been roughly 15% below the weekday average - that's multiplicative (the absolute size of the dip has grown 10x alongside the user base, but the RATIO has stayed constant). A metric like "number of scheduled maintenance windows per week," with a fixed operational cadence unrelated to overall traffic growth, is more likely additive.

Trade-offs & pitfalls
Log-transforming to convert a multiplicative problem into an additive one is convenient (lets you reuse additive-model tooling) but changes how you have to interpret and back-transform prediction intervals - a symmetric interval in log-space becomes an ASYMMETRIC interval once exponentiated back to the original scale, which is correct behavior (uncertainty genuinely should be asymmetric on a multiplicative series) but is easy to get wrong if you forget to back-transform properly.