Netflix Staff Business Intelligence Analyst Interview Preparation Guide

Direct answer
When visualizing a table of billions of event rows, preserve truthfulness by choosing pre-aggregation or materialized rollups as the default (exact, fast, and reproducible), reserving sampling only for exploratory views where you clearly disclose that it's a sample, and never silently computing an exact-looking number from a sampled query without labeling it as an estimate.

Structured elaboration

1. Aggregation: compute and store the rollups the dashboard actually needs (daily/hourly sums, counts, distincts) ahead of time; this is exact and fast, and should be the default approach for any headline metric. The con: a rollup only answers the questions its pre-chosen grain supports, so an analyst who needs a dimension that was not included in the rollup has to wait for a schema change, not just a new query.
2. Precomputation/materialized views: for metrics that require expensive operations (distinct counts, percentiles) at billions-of-rows scale, precompute them on a schedule rather than live, accepting a small latency trade-off for reliability and speed.
3. Incremental refresh: rather than recomputing the full historical rollup every time, append only the newly-arrived data's contribution, keeping refresh cost proportional to new volume, not total history. The con: late-arriving or subsequently-corrected upstream records require an explicit reconciliation/backfill step, or the incremental rollup silently drifts away from what a full recompute would show.
4. Sampling: appropriate for exploratory, interactive slicing where exact precision matters less than responsiveness, but the dashboard must clearly disclose "based on a sample of N%" wherever a sampled number is shown, since a sampled count or distinct-count can differ from the true value by a material margin, especially for rare categories.
5. Metrics unsafe to compute on a sample: distinct counts (e.g. unique users) and any rare-event count (e.g. a specific error type that occurs in a tiny fraction of rows) are especially unsafe to estimate from a small sample, since sampling variance is proportionally much larger for rare or high-cardinality measures than for a simple sum or average.

Worked example
A billions-of-rows events table: daily unique-user counts are computed via a precomputed, incrementally-refreshed rollup (exact, not sampled), while an exploratory "drill into raw events for this specific anomaly" view runs against a 1% sample with a visible "based on a 1% sample, expect +/- some variance" disclosure, since that use case is about pattern discovery, not an exact reported number.

Trade-offs and pitfalls
The most damaging failure mode is silently showing a sampled estimate formatted exactly like an exact number (no disclosure), which lets a viewer unknowingly treat a noisy estimate as ground truth; always label sampled numbers distinctly.

Approach/framework:

1. Define objectives: reduce duplicate work, lower maintenance cost, speed time-to-insight, and increase self-serve adoption.
2. Baseline: measure current state for comparison.
3. Run phased rollout + experiments and measure impact.
4. Quantify ROI in dollars and intangible benefits.

Baseline metrics to collect (current-state, 4–6 weeks):

• Inventory: count dashboards, owners, overlapping KPIs, data sources.
• Usage: active users/week, sessions per dashboard, time on dashboard, query counts (from BI tool logs).
• Time-to-insight (TTI): average time from question to answer (survey + timed tasks with sample users).
• Maintenance effort: engineer/analyst hours/week spent on updates/bug-fixes (timesheets).
• Error/quality incidents: number of data issues or discrepancies reported/month.
• Cost: BI tool license cost allocation, infra/query cost, and estimated analyst hourly rates.

Phased rollout / experiments:

• Phase 0 — Pilot: consolidate 2–3 high-overlap dashboards into portal for one business unit.
  • Run A/B with control group using legacy dashboards vs treatment using portal.
  • Run usability testing and timed tasks to measure TTI.
• Phase 1 — Expand: add more dashboards and users; introduce guided templates and embedded help.
• Phase 2 — Organization-wide: decommission legacy dashboards after migration and training.

Metrics to track during experiments:

• Reduced TTI: mean and median TTI in minutes; proportion of questions answered within target SLA (e.g., <15 min).
• Self-serve adoption: % of users performing ad-hoc queries, number of saved reports, decrease in support tickets for data requests.
• Maintenance cost reduction: analyst hours/month before vs after × hourly rate; reduction in duplicated ETL jobs or reports.
• Query & infra cost: change in query volume/cost from centralization and optimized queries.
• Data quality incidents: count and time-to-resolution.
• User satisfaction: SUS or NPS survey scores pre/post; qualitative feedback.

Quantifying ROI:

• Calculate annual savings = (reduced analyst hours × hourly rate) + (reduced BI tooling/infra costs) + (time saved by stakeholders valued at their hourly rate).
• Add soft benefits: faster decisions → estimated revenue uplift or cost avoidance (use examples: faster campaign pivots, inventory decreases).
• Subtract migration cost: development hours, training, short-term productivity loss.

Example:

• Baseline: 200 analyst-hours/month on maintenance. After pilot: 120 hours → savings 80 hrs × $60 = $4,800/mo.
• TTI improvement: median 2 hours → 20 minutes; if 50 decision-makers save 100 minutes/month each → valued time saved = 50×100/60×$80 ≈ $6,667/mo.
• Net annualized ROI = (savings + decision-time value) × 12 − migration costs.

Key considerations & risks:

• Account for hidden migration costs and change management.
• Use mixed metrics (quantitative + surveys) to capture satisfaction and adoption.
• Iterate: use pilot learnings to refine data models, governance, and training.

This approach provides measurable before/after comparisons, a low-risk phased rollout, and a dollar-backed ROI combining operational savings and faster business decisions.

Direct answer

Cite one specific, verifiable thing from the company's own public materials (a product decision, an engineering post, a case study), explain concretely why it matters to you, and connect it to a specific piece of your background. Anything that could be copy-pasted into a different company's answer with a find-and-replace is too generic to count.

The framework

1. Name the discovery trigger: how you actually came across the company (a product you used, a post you read, a talk you saw). Optional, but it strengthens credibility because it shows the interest predates the interview.
2. Cite one or two specific, checkable details from their public materials: a product or architecture choice, a stated mission line, a case study result, an engineering blog post. Public materials also include how they compare to a competitor; researching that difference is stronger evidence of real homework than surface reading.
3. Explain why that specific detail matters to you, personally or professionally, in one concrete sentence.
4. Close by connecting it to what you'd bring: a skill, a past project, a stated short-term or long-term goal.

Same move, one altitude up (industry instead of product): "what excites you about our product" and "what excites you about our industry" are two distinct framings of this question, and the construction is the same, just zoomed out. Instead of a product or architecture detail, name one concrete shift or problem in the industry the company operates in, something specific enough that you could be wrong about it, not a vague "this industry is exciting." Then connect it to your background the same way: "[Industry, e.g. healthcare payments] is being reshaped by [specific shift, e.g. the move to real-time claims adjudication], and that's directly related to [a piece of your background, e.g. work you did on a low-latency transaction system], which is part of why this company's position in that shift is what drew me in." The same generic-versus-specific test applies at this altitude: a claim true of every company in the space ("AI is transforming everything") is exactly as weak here as "you're an industry leader" is at the company level.

This same content compresses into a one-page memo or a 60-second pitch: discovery trigger in one sentence, the specific detail plus why it matters in two sentences, the connection to your background in one sentence.

Worked example

I came across [company]'s work through [discovery trigger, e.g. their engineering blog, a product I used, a conference talk]. What stood out was [specific detail, e.g. "a post describing how they redesigned a workflow to solve a particular reliability problem"], because it's the same problem I ran into when I [connect to your background]. That's the kind of work I want to be doing, and I'd bring [a specific skill or experience] to it.

(Domain swap: a Solutions Architect might cite a published case study's architecture pattern; a Product Designer might cite a design-system decision documented publicly; a Cybersecurity Engineer might cite a disclosed incident post-mortem.)

Trade-offs and pitfalls

A detail that's true of almost every company in the space (e.g. "you move fast" or "you care about your customers") signals a skim of the homepage, not research into this company specifically.

Direct answer: ROWS BETWEEN 6 PRECEDING AND CURRENT ROW always averages exactly 7 physical rows, so on a day with a missing predecessor it silently reaches further back in calendar time to fill the count: "7 rows ago" can span more than 7 calendar days. RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW stays strictly bounded by the calendar: it always covers today back through exactly 6 days ago, but on a day with a gap just before it, that span contains fewer than 7 rows, so the average is computed over fewer observations than usual. For a genuine calendar week you want RANGE: it is the version whose window boundary actually means what "7-day moving average" claims.

Structured elaboration

• ROWS is positional: it counts physical rows in sort order regardless of what date value they carry. A gap in the calendar doesn't shrink the window; it just means the 7 rows it grabs span more real time than 7 days.
• RANGE is calendar-based: it looks at the ORDER BY expression's value (metric_date) and includes every row whose date falls within 6 days back of the current row's date. A missing date simply isn't there to include; RANGE does not compensate by reaching further back, it just returns fewer rows for that window.
• Neither version errors or warns when a date is missing. The output row count changes (fewer averaged observations under RANGE, no change under ROWS) but the query silently returns a number every time either way.

Worked example

Table daily_metrics(metric_date, metric_value), metric_date = 10, 20, 40, 50, 60, 70, 80, 90 on Jan 1, 2, 4, 5, 6, 7, 8, 9 (Jan 3 is missing).

SELECT
  metric_date, metric_value,
  AVG(metric_value) OVER (ORDER BY metric_date
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS ma_7_rows,
  AVG(metric_value) OVER (ORDER BY metric_date
    RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW) AS ma_7_days
FROM daily_metrics
ORDER BY metric_date;

Verified in DuckDB. At metric_date = 2025-01-08:

• ma_7_rows = (10+20+40+50+60+70+80) / 7 = 47.14, built from the 7 physical rows Jan 1 through Jan 8 (an 8-calendar-day span, because Jan 3's absence made ROWS reach one row further back than a clean week would).
• ma_7_days = (20+40+50+60+70+80) / 6 = 53.33, built from only the 6 rows that actually fall within Jan 2 through Jan 8 (RANGE correctly excludes Jan 1, which is 7 days back, but has only 6 real observations to average, not 7).

Both numbers are "correct" for what they're defined to compute; they disagree because they're answering different questions once a gap exists.

Key points

• ROWS: fixed observation count, variable calendar span.
• RANGE: fixed calendar span, variable observation count.
• Neither one is "the moving average with gaps fixed"; RANGE is the closer match to the plain-English "7-day calendar average," with the caveat that its sample size silently shrinks around gaps.

Complexity
Both frame types require one sort of the partition by metric_date (O(n log n)) followed by a single incremental pass (O(n)) that most engines implement as a sliding-window accumulator (add the newly-in-frame rows, subtract the newly-out-of-frame rows) rather than recomputing the sum from scratch at every row.

Edge cases

• Multiple rows on the same metric_date: ROWS treats each as a separate physical row toward its count of 7; RANGE includes every same-date row as part of the same day (aggregate to one row per date first if you want a true daily series before either frame runs).
• The first few rows of the series: both frames just use however many prior rows or days actually exist, so early averages are computed over less than 7 observations, which is expected, not a bug.
• If you want a real week's worth of RANGE-based observations even across gaps, the standard fix is to build a complete calendar-date spine (a recursive common table expression, or CTE, written WITH RECURSIVE, or a built-in generate_series) and LEFT JOIN the metric onto every date, so missing days become explicit zero- or NULL-valued rows rather than absent ones, before applying the RANGE frame.

Trade-offs & pitfalls

This is a related but distinct failure from readings that arrive at irregular sub-day intervals (seconds apart one moment, hours apart the next): that case, where RANGE can't even express "last N readings" at all regardless of how you tune the interval, is a deeper problem than the whole-day gaps here, where RANGE's semantics are at least still coherent, just narrower in sample size around a gap.

Pick ROWS when the requirement is really "the last 7 observations" and gaps in the underlying calendar are irrelevant (e.g., the data is pre-aggregated to one row per period and every period matters equally). Pick RANGE when the requirement is a genuine calendar quantity ("trailing 7 calendar days") and you're prepared for the sample size to shrink near gaps, or you've pre-filled the gaps with a calendar spine so it doesn't.

Direct answer

Never put three products with different scale on a shared dashboard as raw counts; normalize with per-user rates for monetization efficiency, indexed baselines for trend comparison, and cohort-normalized metrics for lifecycle-stage comparison, and show all three alongside the raw volumes so the CEO can see both scale and health without conflating them.

Structured elaboration

Always show the normalized figure next to the raw volume and the sample size behind it; a normalized metric computed on a tiny user base is a different kind of number than the same metric computed on millions of users, and the CEO needs both to judge how much to trust a comparison.

Worked example

Product A: $2,000,000 in monthly revenue against 1,000,000 MAU.
Product B: $50,000 in monthly revenue against 500,000 MAU.

Product A monetizes each active user 20 times more efficiently than Product B, a comparison the raw revenue totals alone would have obscured (Product A's revenue is 40 times Product B's, but its user base is only 2 times larger).

For indexed trend comparison, suppose Product C had a 8,000 daily active user (DAU) baseline three months ago and now has 9,200:

Product C is running at an index of 115, meaning 15% growth off its own baseline, a comparison that is meaningful even if Product C's absolute DAU is far smaller than the other two products' absolute DAU.

Trade-offs & pitfalls

Per-user rates can make a small, niche product look artificially strong if its tiny denominator amplifies noise; always pair the rate with the underlying sample size. Indexed baselines communicate trend well but hide absolute scale entirely, so a product growing fast off a tiny base can visually dominate a chart next to a much larger, more important product that is merely stable; label the chart with both the index and the underlying absolute number. Cohort normalization is the most honest comparison for lifecycle-stage questions but requires a consistent definition of "active user" and cohort start date across all three products, and if the products' event instrumentation differs even slightly, the comparison quietly stops being apples to apples while still looking clean on the dashboard.

Start with scope and reproducibility

• Ask the stakeholder which report, timeframe, filters, and exact numbers don’t match. Reproduce the mismatch yourself using the same user account, filters, and timeframe.

Source extract checks

• Verify extract schedule and watermark: confirm last successful refresh/time and row counts.
• Run a direct count/aggregation on source DB to compare:

SELECT COUNT(*) AS rows, SUM(amount) AS total
FROM sales
WHERE sale_date BETWEEN '2025-01-01' AND '2025-01-31';

• Check incremental extract logic for missed or duplicated batches (timestamps, CDC windows).

ETL/Transformation checks

• Review ETL job logs for errors, warnings, restart points, duplicates.
• Validate intermediate staging tables: row counts, distinct keys, NULL patterns.
• Re-run critical transformation SQL for a small sample and compare before/after values.

Joins and keys

• Examine join types (INNER vs LEFT) that can drop rows; test key cardinality:

-- find orphaned fact rows
SELECT f.id FROM fact f
LEFT JOIN dim d ON f.dim_id = d.id
WHERE d.id IS NULL;

• Check for many-to-many or duplicated dimension keys causing inflated totals.

DAX / Tableau calculations and filters

• Inspect calculation definitions, context modifiers, and filter scopes.
• For Power BI, test measure with ALL/REMOVEFILTERS to isolate filter impact:

TotalSalesNoFilters = CALCULATE([TotalSales], ALL('Date'))

• In Tableau, verify table calculations, LOD expressions, and whether dashboard filters are applied at worksheet vs dashboard level.

Timezone and currency conversions

• Confirm source timestamps’ timezone and any conversion applied during ETL or visuals.
• Verify currency rates: source currency, conversion rate table validity, and whether conversion applied before/after aggregation.

Compare row-level values

• For a small date/customer sample, trace a single transaction from source -> staging -> warehouse -> visualization to see where value diverges.

Performance and caching

• Check dashboard cache, materialized views, or aggregates that may be stale.

Documentation and communication

• Log each check, SQL queries and results, timestamps, and screenshots. Summarize findings: root cause, evidence (diffs, counts), impact, and recommended fix (code change, re-run ETL, refresh cache, or filter adjustment).
• Provide an action plan with owner, estimate, and verification steps. Share results with stakeholder and close loop after confirmation.

This systematic trace-first approach isolates the layer causing discrepancy and produces reproducible evidence for fixes.

Situation: You're evaluating a recommender whose business goal is to increase total watch minutes. Offline metrics (precision/recall, NDCG, MAP) are useful proxies but have limits; as a BI analyst you need to translate them to expected impact on online KPIs (watch minutes, retention).

Comparison / what they measure:

• Precision/Recall: measure relevance/binary hit-rate on held-out interactions. Good for "does the user click/watch at least once" but ignore watch duration and sequential effects.
• NDCG: ranks items by graded relevance; rewards putting highly relevant items early. Better proxy when position matters and when relevance correlates with duration.
• MAP: average precision across queries/users; emphasizes correct ranking of relevant items across the list, useful for consistent relevance but still ignores time spent.

Online KPI alignment:

• Watch minutes depend on both selection and engagement length — a clicked item may yield 30s or 30min. Retention depends on long-term satisfaction and cohort effects (e.g., repeated good recommendations).

Pitfalls when offline diverges from online:

• Label bias: training/eval labels reflect past exposure, not true preference.
• Exposure / position bias: historical position effects inflate metrics.
• Short-session clicks dominating labels lead to misleadingly high precision but low minutes.
• Distribution shift between offline test set and live traffic.

Methods to reduce the gap:

• Use enriched labels: weight interactions by watch duration (e.g., minutes-weighted relevance) or use graded labels for NDCG.
• Session-aware and sequential offline simulations: evaluate predicted session watch-time, not just clicks.
• Counterfactual / causal approaches: inverse propensity scoring to correct exposure bias.
• Build surrogate offline KPIs that map to business metrics (predicted watch minutes per impression) and validate with small A/B tests.
• Continuous validation: ship small, time-boxed experiments and instrument dashboards that compare offline predictions vs. real watch minutes/retention by cohort.
• Monitor uplift and long-term metrics (D7/D30 retention) not just immediate watch minutes.

Practical BI actions:

• Create dashboards showing correlation between offline metrics and online watch minutes by cohort, content-type, and user segments.
• Add experiment telemetry: predicted vs. observed watch minutes, click-to-watch-duration distribution, and propensity-corrected lifts to quickly detect divergence and guide model iteration.

Days 0–14 — Learn context & inventory

• Meet stakeholders (analytics, engineering, product, ops) to map critical reports and SLAs.
• Inventory Looker artifacts: Projects, model files (.model.lkml), explore files, view files, dashboards, Looks, PDTs, persistent derived tables, datagroups, scheduled looks, Git branches.
• Run exploratory queries: open top 10 slowest dashboards, note runtime, user, frequency.

Days 15–30 — Inspect models and surface issues

• Review LookML patterns: excessive derived_table SQL, many joins with 1:n without pre-aggregation, poorly scoped measures (SELECT * patterns), misuse of sql_table_name vs derived_table.
• Check explore definitions: always_filter, access_filters causing row-level UDFs, joins with sql_on using non-indexed columns.
• Look at PDTs and datagroups: long build times, queuing, high refresh frequency.
• Query artifacts: examine generated SQL for top slow queries — indicators: full table scans, correlated subqueries, heavy DISTINCTs, CROSS JOINs, repeated window functions, wide SELECT lists.
• Metrics: average dashboard load time, 95th percentile query duration, cache hit rate, PDT build success rate.

Days 31–45 — Prioritize & prototype fixes

• Quick wins: add derived_table indexes by moving heavy calculations to materialized views/PDTs, restrict measures with user_attributes/filters, add persistent derived tables for repeated expensive aggregations, set sql_table_name to reference optimized views.
• Model changes: remove SELECT * in sql_table_name, define appropriate primary_key and dimension keys, convert expensive joins into aggregated derived tables, add templated filters to limit row counts.
• Test: run before/after query plans, measure runtime and cost; deploy on feature branch and validate with stakeholders.

Days 46–60 — Rollout, monitoring, docs

• Deploy changes via Git flow, schedule low-impact releases. Update documentation: model diagrams, dependency graph for PDTs, runbook for failures.
• Establish monitoring: Looker System Activity dashboards (query_history, dashboard_views, pdt_builds), alerts for slow queries and PDT failures, monthly review cadence.
• Hand off: train analysts on new best practices (use of persistent derived tables, avoiding heavy row-level calculations) and propose SLA for dashboard performance.

Key SQL/model-level red flags to watch:

• Generated SQL with large unbounded WHERE clauses, many nested SELECT DISTINCT, repeated full-table scans (no WHERE on indexed cols), JOINs without ON using equality on non-indexed expressions, long-running window functions, frequent cache misses and high PDT build queues.

This plan balances rapid discovery, targeted remediation, stakeholder validation, and sustainable monitoring so Looker models become more performant and maintainable.

Direct answer
A mentoring relationship going badly is rarely one big failure; it's usually a slow accumulation of choices, like taking on too much of the work yourself to protect the outcome, that quietly undercut the mentee's growth. The honest answer names a specific relationship, is candid about what you did (not just what the mentee did), and shows what changed in how you mentor afterward.

What "went badly" usually looks like

• Common patterns: being too directive and doing the hard parts yourself to protect delivery; giving feedback too infrequently or too late to be actionable; misjudging the mentee's actual gap (treating a confidence problem as a skill problem, or the reverse); or disengaging when the relationship got effortful.
• A strong answer picks one specific pattern and owns your part in it, rather than a vague "they weren't a good fit."

What separates a senior answer from a junior one

• Junior answers blame the mentee ("they just weren't receptive") or stay abstract ("communication could have been better"). Senior answers identify a decision you made and trace its actual effect: what you did, what it produced, and why it made sense to you at the time even though it was wrong.
• Senior answers also show what changed structurally afterward, not just an apology or a resolution to "communicate better." Concrete changes: an explicit mentoring agreement up front, checkpoints instead of open-ended availability, deliberately handing over ownership even when it's slower.

How to close it out

• End on what you'd do differently now, stated specifically enough that it's clear you'd actually behave differently in the next relationship, not just that you feel bad about the last one.

Worked example
During a stretch project with a hard deadline, I mentored a junior engineer by taking over the riskiest parts myself rather than coaching them through it, to keep the timeline safe. That worked in the short term, but it meant they never built confidence handling ambiguity or incidents on their own, and toward the end of the project they told me directly that they felt sidelined rather than developed. That was the moment it became clear the relationship hadn't done what I'd intended, even though the project itself shipped fine.

What I changed afterward: instead of stepping in when something got risky, I started requiring myself to narrate my reasoning out loud and have the mentee drive, only taking over if there was a genuine, immediate risk. I also set an explicit checkpoint (a short regular sync, not just "come find me") so growth stalls would surface early instead of only becoming visible at the end of a project. The relationship after that wasn't measured by how smoothly the project went; it was measured by whether the mentee could handle the next similar situation without me in the room, which is a slower thing to build but the actual point of mentoring.

Trade-offs and pitfalls

• The tempting failure mode is optimizing for the deliverable (visible and rewarded) at the expense of the mentee's growth (slower and less visible), especially under deadline pressure.
• Being self-critical is necessary but insufficient; an answer that's all remorse with no concrete process change reads as unreflective in a different way.
• Watch for over-correcting into never stepping in, which just replaces one failure mode (too directive) with another (abandoning someone to a mistake they can't yet recover from alone).

Direct answer. When two related datasets that should match at the transaction level don't (product analytics counting more purchases than billing counts payments, or reported prices differing from what was actually charged), the reconciliation needs to happen at the RECORD level, not the aggregate level, because an aggregate gap can hide multiple offsetting errors that only a row-by-row match reveals.

Structured elaboration. Join the two datasets on the most reliable shared key available (a transaction ID if both systems share one, or a composite key of user ID plus timestamp plus amount if not), and bucket every record into matched, unmatched-in-source-A-only, or unmatched-in-source-B-only. For the unmatched buckets, look for the specific mechanical causes: duplication (the same real transaction appearing twice in one source, often from a retry or a double-fired event), delayed billing (a transaction that's real in both but hasn't been fully processed in the slower system yet, a timing difference rather than a true gap), refunds (a transaction reversed in one system but the analytics-side record never got updated to reflect it), and a genuine pricing-system bug (the two systems computing different amounts for the same transaction because of a stale price, a currency-conversion difference, or a promo-code application bug). Compute the matched-versus-unmatched RATE as the headline reconciliation metric, and quantify the dollar impact of each bucket separately so the business impact of a real bug is distinguished from the size of a merely-timing-related gap.

Worked example. Product analytics reports 100,000 purchases for a week while billing reports 95,000 billed payments. Joining on transaction ID: roughly 3,500 of the 5,000-record gap are transactions still pending settlement (a timing difference that will resolve as billing catches up), about 1,200 are duplicate analytics events from a known retry bug in the checkout flow (a real data-quality issue inflating the analytics count), and the remaining 300 are refunded transactions where the analytics event was never reversed. None of the gap turns out to be a pricing-system bug in this case, which is itself a useful, specific finding to report rather than a vague '5% off.'

Trade-offs and pitfalls. A composite key (rather than a true shared transaction ID) risks both false matches (two different transactions coincidentally sharing user, near-timestamp, and amount) and false non-matches (the same transaction with a slightly different recorded timestamp across systems); when only a composite key is available, use a tolerance window on timestamp and amount and explicitly flag near-matches for manual review rather than silently accepting or rejecting them.