Microsoft Business Intelligence Analyst (Staff Level) Interview Preparation Guide

Direct answer

I would run it as a learning review with two jobs: find out where the gap came from, and find out which decisions and assumptions were wrong. I would bring a decomposition of the miss, a record of the key decisions, and an honest question about whether the target itself was sound. Attendees are the people who made decisions and the people who executed them, across functions. It ends with two or three changes, each with one owner and a date, written before people leave.

Who attends

Product, engineering, marketing, sales, support and analytics, each represented by someone who was in the work, plus an executive sponsor who listens first and speaks last (leadership talking early shapes everything). Keep it to about 8 to 10 people so everyone is heard.

Evidence I bring

• The original target and how it was derived, plus the assumptions behind it.
• A funnel breakdown: the path customers take, step by step (visit, sign up, activate), with the count at each step, showing where the shortfall arose.
• The decision log: what was decided, by whom, with what information.
• Customer evidence (support tickets, interview notes), not only the dashboard.

Worked example (illustrative): decomposing a 40% miss

Plain terms: a visit is someone arriving on the site, the sign-up rate is the share of visitors who create an account, and an activation is a new account that completes the first meaningful action (say, creating a first project). Target: 10,000 activations. Actual: 6,000, which is a 40% miss ((10,000 - 6,000) / 10,000 = 0.40).

Trace the actual column: 150,000 x 8% = 12,000 sign-ups, and 12,000 x 50% = 6,000 activations. Plan: 200,000 x 10% = 20,000 sign-ups, and 20,000 x 50% = 10,000.

Traffic alone would have given 7,500, and the sign-up rate alone 8,000, but the two shortfalls multiply (0.75 x 0.80 = 0.60), which explains the 40% miss. Activation behaved as planned. So the review spends its time on why traffic and sign-up fell short (campaign timing? pricing page? the target assumed 10% from a different audience?), not on onboarding.

Running it (90 minutes)

These sum to 90.

Avoiding finger-pointing

Describe decisions in terms of the information available at the time ("given what we knew then"), ask each function "what did you see that others did not?", and separate learning from performance review, which happens elsewhere.

Trade-offs and pitfalls

• Outcome bias (judging a decision by how it turned out rather than by how sound it was given what was known at the time): a bad result makes every decision look bad. Ask whether the decision was reasonable when taken.
• The target may have been the error. Say so if the evidence shows it.
• Share a short written summary and follow up on the changes at 30 days, or the review is theatre.

Direct answer

Resolve the conflict by treating "active user" as a versioned, explicitly-named metric in the conformed dimensional model rather than a single ambiguous column: define each team's variant as its own named metric with clear ownership and lineage, surface which definition each dashboard uses, and drive toward a single canonical default definition for genuinely cross-team reporting while allowing named exceptions where a team's variant is truly justified.

Structured elaboration

• Process: convene the disagreeing teams, surface each team's actual DEFINITION (not just their number) and why they need it that way (a "monthly active" definition for billing purposes is legitimately different from a "weekly active" definition for engagement tracking), and distinguish genuine business-need differences from accidental, historical inconsistency.
• Schema approach, versioned metric definitions: implement each surfaced definition as its own explicitly named metric (active_user_billing, active_user_engagement) in the semantic layer or metrics catalog, computed from the same underlying conformed user_dim and activity_fact, rather than as separately-maintained, potentially-diverging pipelines.
• Lineage: make each named metric's definition and its underlying SQL/logic visible and discoverable, so any dashboard consumer can see exactly which "active user" definition a given number represents, rather than a bare "Active Users" label with no indication of which team's definition it's using.
• Driving toward consensus: for reporting that genuinely needs ONE company-wide number (a board-level metric, for instance), lead a process to agree on a single canonical default definition, while still allowing the named team-specific variants to coexist for their legitimate internal purposes, clearly labeled as such.

Worked example

Marketing's "active user" counts anyone with a single app open in 30 days; billing's counts only paying customers with a qualifying usage event in the billing period. Rather than forcing one definition on both, the metrics catalog defines active_user_engagement and active_user_billing as two separate, explicitly named, independently governed metrics, both computed from the same activity_fact and user_dim, and every dashboard using either one displays which definition it's using. A quarterly board metric is separately agreed as a specific canonical definition, distinct from either team's operational metric, chosen deliberately for that purpose.

Trade-offs and pitfalls

The tempting shortcut, picking one team's definition and forcing everyone to use it, usually just pushes the disagreement underground (the losing team builds a shadow metric outside the governed system) rather than resolving it. Explicitly naming and governing multiple legitimate definitions, with visible lineage, costs more upfront design work but avoids both the shadow-metric problem and the "silent redefinition" problem that erodes trust in the metrics catalog over time.

Direct answer
Different companies name the same underlying idea, owning an outcome end to end and beyond your formally assigned scope, under different labels. Recognizing which of a specific company's named principles maps to that idea, and then having a real, specific story ready, is the actual skill being tested.

Structured elaboration

1. Read the company's actual published list and identify the principle whose description centers on end-to-end accountability and going beyond formal scope, rather than assuming it is whichever principle happens to sound closest to the word "ownership."
2. Select a real story where you did something that was, strictly, not your job, or continued past the point where you could have handed it off to someone else.
3. Structure it briefly: what you noticed, why you didn't wait for someone else to take it on, what you actually did through to completion, and the outcome.
4. Include one honest lesson, ideally something you would do differently next time; a story with no self-critique at all tends to read as less genuine.

Worked example
A project's launch depended on a piece of infrastructure owned by a team that had deprioritized it. Rather than escalating and waiting, or quietly working around the gap, the candidate built the missing piece directly, with the owning team's agreement, on a tight timeline, then handed it back afterward with documentation so that team could maintain it going forward, and followed up a month later to confirm it had actually been adopted rather than quietly abandoned. The lesson: doing the initial work wasn't the hard part; making sure ownership genuinely transferred back afterward, rather than quietly staying with the person who had stepped in, was the part that mattered most and the part that was easiest to skip.

Trade-offs and pitfalls
A story where you took something over and never handed it back can read as scope-grabbing rather than ownership; the follow-through and handoff matter as much as the initial action. Mapping too literally from a principle's name, rather than its actual published description, risks picking the wrong principle for a company whose specific wording differs from what the word alone suggests. A story with no genuine lesson or self-critique often reads as rehearsed rather than reflective.

Direct answer
Autonomy should track demonstrated judgment in a specific domain, not tenure or title, and it should be granted and withdrawn through visible, structural mechanisms, not just a private mental model of how much you trust someone. As someone grows from junior to senior, both the default level of guidance and the criteria for changing it should become more explicit, not less.

What determines the level, not just the person's level

• Domain-specific, not global: someone can have earned full autonomy in one area (their core service) and need more guidance in an adjacent one (security-sensitive changes) they haven't touched before. Treating autonomy as a single dial per person rather than per domain misjudges both directions.
• Base it on evidence: track record of decisions in that specific domain, not just general seniority or how long they've been on the team.

The conversation isn't enough, structure it

• Guidance and autonomy shouldn't live only in how much you check in; they should be encoded in the system itself. Concretely: mandatory review gates on certain categories of change, feature flags that let risky work ship dark before it's fully trusted, and automated checks (tests, linting, policy gates) that catch the class of mistake a specific person is prone to, rather than relying on a human remembering to look for it.
• This matters especially early: a junior engineer with a mandatory review gate on production-config changes isn't being distrusted personally, the system is compensating for a domain they haven't yet built judgment in, and that's a much less fraught conversation than "I don't trust your judgment yet."

Moving the dial, in both directions

• Define, in advance, what "graduating" out of a guardrail looks like: a number of changes in that domain reviewed without a significant issue, or a specific type of decision made correctly under supervision. Vague criteria ("when I feel comfortable") makes the process feel arbitrary to the person on the other side of it.
• The dial also needs to move backward cleanly. If someone senior makes a judgment error in a domain, temporarily reintroducing a guardrail (an extra review, a smaller blast radius) shouldn't read as a permanent demotion; it should be scoped to the specific domain and have the same kind of explicit, objective path back out.

How this shifts junior to senior

• Junior: guidance is broad and mostly structural (required reviews, smaller scoped tasks, pairing), because there isn't yet enough track record to know where the real gaps are.
• Mid-level: guidance narrows to the specific domains where judgment hasn't been tested yet, while proven domains get real autonomy.
• Senior: guidance becomes mostly about the highest-blast-radius decisions (irreversible changes, cross-team commitments) rather than day-to-day execution, and the structural safeguards that remain exist because the stakes are higher, not because trust is lower.

Worked example
A mid-level engineer had strong judgment in their core service but hadn't touched the deployment pipeline before. Rather than a blanket "you need approval on everything" or "you're trusted, go ahead," the guidance was scoped to that specific gap: full autonomy on their usual work, a mandatory review plus a feature flag for anything touching the deploy pipeline, with an explicit criterion stated up front (three pipeline changes reviewed cleanly, then the mandatory review comes off for that category specifically). That made the guardrail feel like a scoped, temporary compensation for an actual gap rather than a general judgment about their competence, and removing it was a specific, visible moment rather than something that just quietly happened.

Trade-offs and pitfalls

• Treating autonomy as all-or-nothing per person, rather than per domain, either over-restricts someone who's earned trust in most areas or over-extends them into an area they haven't proven yet.
• Relying purely on personal judgment about who to trust, without structural backstops (review gates, flags, automated checks), doesn't scale past a small team and creates inconsistency that reads as favoritism.
• Leaving the criteria for regaining autonomy vague turns a guardrail into something that feels indefinite and punitive, even when it was scoped and reasonable at the start.

Direct answer. A correlation only tells you that two things move together; it says nothing about why. Three general mechanisms besides direct causation can produce a correlation: a shared confounder that drives both variables, reverse causation (the effect actually precedes the presumed cause), and plain coincidence in a noisy sample. The next concrete step is not to argue in the abstract but to ask what would happen to the correlation if you could intervene on one variable while holding everything else fixed, which is exactly what an experiment (or a well-designed quasi-experiment) lets you check.

Structured elaboration. Walk a stakeholder through each mechanism with a question they can ask themselves:

• Confounding: is there a third factor plausibly driving both series? (Ice cream sales and drowning both rise with summer heat.)
• Reverse causation: could the "outcome" actually be causing the "cause"? (Struggling users might seek out a help feature, so help-feature usage correlates with struggling, not the other way around.)
• Coincidence: how much data is this based on, and did you check other time periods or segments? A correlation computed on one quarter of noisy data is weak evidence on its own.

Once you've ruled these out qualitatively, the real test is whether the relationship survives an intervention: randomize who gets the treatment, or find a situation where assignment was effectively random (a policy cutoff, a staggered rollout) and see if the effect holds.

Worked example. Suppose weekly push notifications sent and weekly active users (WAU) are strongly positively correlated ($r = 0.82$) over the last year. A marketer wants to conclude notifications drive WAU. Before agreeing: check for a shared confounder (both notification volume and WAU tend to rise around product launches and holidays), check reverse causation (the team may deliberately send more notifications because WAU dipped, to try to recover it, which would produce a correlation with the wrong sign of causality), and check the sample (is $r=0.82$ stable across quarters, or driven by one holiday spike?). The decisive next step is a holdout: stop sending notifications to a random 10% of users for two weeks and compare WAU between that holdout and the rest.

Trade-offs and pitfalls. The most common mistake is treating "we found a plausible confounder" as proof the relationship isn't causal at all, when the correct conclusion is usually "we can't tell yet, here's how we'd find out." A second pitfall is stopping at qualitative reasoning when a cheap experiment or natural-experiment check is available; qualitative reasoning is a screening step, not a substitute for evidence.

Analytical warehouses prefer columnar formats like Parquet or ORC because most analytical queries touch a small number of columns across a huge number of rows, and columnar storage is built specifically to exploit that pattern. Row-oriented storage, by contrast, is built for the opposite pattern: reading or writing one whole record at a time.

Why columnar wins for analytics

In row-oriented storage, all the columns for a single row sit next to each other on disk, so reading even one column means reading the whole row. In columnar storage, all the values for a single column sit together instead. That single layout change explains most of the benefit:

Less data read off disk. If a query only needs three columns out of fifty, columnar storage lets the engine read only those three columns' worth of bytes; row storage would have to read all fifty columns for every row, then discard the ones it didn't need.

Compression. Values within a single column tend to be far more similar to each other than a mixed row of different columns is (a status column might have only a handful of distinct values, for instance). That similarity compresses much better, and formats like Parquet and ORC take advantage of it with column-specific encodings, which further reduces the bytes actually read from disk.

Skipping data that can't match a filter. Columnar file formats keep summary statistics (like the minimum and maximum value) for chunks of each column. If a query filters on a date range, the engine can check those statistics and skip entire chunks that fall outside the range without reading them at all, on top of the column-level savings already described.

Worked example

Consider a query that computes total revenue for one product category last month, against a wide events table with fifty columns. In row-oriented storage, computing that aggregate still means reading every column of every row in the relevant time range, most of which the query never uses. In columnar storage, the engine reads only the category and revenue columns (plus whatever it needs to apply the date filter), and if the data is organized so most chunks clearly fall outside last month's date range, it can skip those chunks entirely. The net effect is that a query touching two or three columns out of fifty can end up reading a small fraction of the bytes a row-oriented equivalent would.

Trade-offs and pitfalls

Columnar formats aren't universally better: for a workload that reads or writes entire records at a time, like an online transaction touching every field of a single order, row-oriented storage is the better fit, because columnar formats pay a real cost when you need to reconstruct a whole row from scattered column files. This is exactly why transactional (OLTP) systems still use row-oriented storage even though analytical (OLAP) systems have moved to columnar: the two are optimized for genuinely different access patterns, not one being an outdated version of the other.

Direct answer

Test whether missingness is informative by comparing the outcome (or another variable of interest) between rows where the field is missing and rows where it's present; if the missing group looks systematically different, the missingness itself is carrying signal, not just noise to be discarded. If the field is missing much more for one subgroup (a demographic group, a customer segment) than another, that's worth flagging as a potential bias risk before anyone builds on the data, not just a modeling nuisance to route around.

What this finding implies

If missingness is informative (say, customers who churned are missing "last login date" far more often than customers who didn't), the fact that it's missing is itself a usable signal, and naively dropping or blindly imputing those rows would throw that signal away. If the missingness concentrates in a specific demographic group, that's a fairness and data-collection concern that goes beyond modeling: it might mean that group is measured worse, served worse, or systematically opts out of whatever generates that field, any of which deserves its own investigation before you treat the rest of the analysis as representative of that group.

Worked example

In a churn dataset, last_login is missing far more often for customers who eventually churned than for those who didn't. Testing this concretely: compute the churn rate separately for rows with last_login present versus missing. If the missing group churns at a meaningfully higher rate than the non-missing group, that's evidence the missingness itself is informative, likely because churned customers simply stopped generating login events, which is precisely the signal a model needs, not noise to impute away. Separately, checking last_login missingness by demographic group and finding it's twice as common in one segment would be a distinct finding worth its own investigation into whether that segment is tracked less reliably.

Trade-offs and pitfalls

This is a discovery step, not a fix: once you've established that missingness is informative, deciding HOW to encode that (an explicit "missing" category, a missingness-indicator feature, or a different treatment entirely) is a downstream handling decision. Don't conflate "informative missingness" with "therefore fine to leave unaddressed": informative missingness that concentrates in a protected group is a red flag worth escalating, not a convenient feature to exploit without further thought.

Direct answer. The data owner is accountable for the business decisions about a dataset, who can use it, for what, and what risk is acceptable. The data steward is the person who actually enforces quality, definitions, and policy day to day. The data custodian is the technical role that operates and secures the infrastructure the data lives on. On a shared table like customer_master, those are typically three different people with three different daily jobs.

The three roles, each grounded in customer_master

• Data owner: typically a business leader, for example the head of Sales Ops or Customer Success, accountable for how customer_master is used and who's allowed near it. Daily task: approving or denying a new team's request for read access to customer_master, weighing business value against the sensitivity of the fields requested.
• Data steward: typically a senior analyst or embedded data engineer responsible for the table's quality and definitions in practice. Daily task: reviewing an automated data-quality alert that customer_master's email field had a spike in nulls overnight, tracing it to an upstream schema change, and coordinating the fix with the producing team before it breaks downstream dashboards.
• Data custodian: typically a data engineer or platform/DBA (database administrator) responsible for the technical infrastructure. Daily task: applying a scheduled access-control change to customer_master, for example revoking a departed employee's credentials or provisioning a newly approved read grant, and confirming the table's backup and encryption settings meet the organization's baseline.

The distinction that matters in practice. The owner decides what should happen, the steward makes sure it actually keeps happening correctly day to day, and the custodian makes it technically true. A common confusion is conflating steward and custodian because both do hands-on work; the difference is the steward owns correctness and policy compliance, while the custodian owns the infrastructure that stores and secures it.

Convincing a reluctant team to accept stewardship for customer_master

• Lead with what's already costing them, not with a new obligation: point to a specific recurring pain, repeated data-quality tickets, ambiguous field definitions causing arguments in meetings, that stewardship would actually fix.
• Make the ask small and bounded: propose a defined, modest time commitment, reviewing quality alerts and approving definition changes, rather than an open-ended responsibility.
• Show, don't just tell: if a comparable table already has a steward and fewer quality incidents or faster resolution, use that as the case for what stewardship buys the team, rather than asserting the benefit abstractly.
• Give real authority along with the responsibility: a team is far more willing to own quality for a table if it also gets real say over who's granted access and how it's used, not just the cleanup work when something breaks.

Trade-offs and pitfalls

• The most common failure is naming a steward without giving real authority or dedicated time, producing a title with no behavior change; stewardship needs real decision rights, not just a name in a wiki page.
• Treating the owner as a rubber stamp instead of the actual accountable decision-maker means access and use-case decisions default to whoever asks loudest, exactly the ambiguity a governance program exists to prevent.

Direct answer. Compare Snowflake, BigQuery, and Redshift on five axes: architecture model (how compute and storage separate), concurrency handling, pricing model, storage format support, and operational overhead. There is no universal winner; the right choice depends on your team's existing cloud, your query concurrency profile, and how predictable your workload is.

Structured elaboration.

Three platform-specific units in that table are worth defining plainly, since the question is explicitly asking about concurrency handling and pricing: a Snowflake compute credit is its per-second billing unit for warehouse compute, so a bigger or longer-running warehouse simply burns credits faster. A BigQuery slot is the platform's unit of parallel query-processing capacity; the "shared slot pool" is the pot of these units Google draws from to run your query, and a slot reservation just reserves a guaranteed number of them for you instead of sharing the pool with every other BigQuery customer. A Redshift WLM (Workload Management) queue is a named lane that routes a query to a specific, bounded share of the cluster's memory and concurrency; hitting a concurrency limit means that particular queue's lane is full, not that the whole cluster is out of capacity.

Worked example. For a fast-growing team with roughly 500 analysts running around 10,000 BI queries a day against a 10TB active dataset, concurrency handling is the deciding factor more than raw performance: Snowflake's ability to spin up independent warehouses per team or workload avoids one group's heavy queries starving another's dashboard, and its per-second billing means idle warehouses cost nothing when auto-suspended. BigQuery is an equally strong fit if the team is already GCP-native and wants zero cluster management, especially if the query pattern is bursty rather than continuously heavy, since on-demand pricing avoids paying for idle capacity at all. Redshift becomes the stronger choice when the workload is large and steady enough that reserved/provisioned capacity is cheaper than pay-per-use, or when the team already has deep AWS-ecosystem integration (IAM, Glue, Lake Formation) that reduces the value of switching platforms. At petabyte scale with a high-concurrency BI user base, total cost of ownership becomes the deciding axis rather than raw price-per-query, since the storage-versus-compute separation and auto-scaling behavior of Snowflake or BigQuery tend to avoid the manual capacity-planning overhead that a large provisioned Redshift cluster requires, while a spiky, bursty query pattern specifically favors either platform's auto-scaling over a fixed-size cluster.

Trade-offs and pitfalls. Benchmarking these platforms fairly is hard: comparing default settings without tuning distribution/clustering keys, using a dataset too small to expose real concurrency behavior, or ignoring egress and data-transfer cost between your existing systems and the new platform will all produce misleading conclusions. Vendor lock-in is real in all three directions (proprietary SQL extensions, proprietary storage formats, ecosystem integrations), so weigh switching cost alongside today's price and performance, not just today's benchmark numbers.

Direct answer: For each user, number the activity dates in order with ROW_NUMBER(), then subtract that row number (in days) from the actual date. Within one unbroken run of consecutive days, the date increases by exactly 1 each row while the row number also increases by exactly 1, so date - row_number is a constant for the entire run and jumps to a new constant the moment there's a gap. That constant is a ready-made, stable group id: group by it (per user) and aggregate to get each streak's start, end, and length.

Structured elaboration

Why the trick works, concretely. If a user is active on Jan 1, 2, 3 (three consecutive days), their row numbers are 1, 2, 3. date - row_number, expressed as date - (row_number * INTERVAL 1 day) so both sides are dates, gives Dec 31, Dec 31, Dec 31 for all three rows: the row number is climbing at exactly the same rate as the date, so the difference is invariant. The moment there's a gap (say the next activity is Jan 5, skipping Jan 4), the row number continues climbing by 1 (to 4) but the date jumps by 2, so date - row_number shifts to a new constant. Every row in a contiguous run shares one constant; every gap produces a new constant. That is why grouping by this value is safe and deterministic, unlike an arbitrary running counter that would need a separate flag-and-cumsum step (the LAG-based alternative below does exactly that instead).

WITH numbered AS (
  SELECT user_id, activity_date,
    ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY activity_date) AS rn
  FROM activity
),
grouped AS (
  SELECT user_id, activity_date,
    activity_date - (rn * INTERVAL '1 day') AS island_id
  FROM numbered
)
SELECT user_id, island_id,
  MIN(activity_date) AS streak_start, MAX(activity_date) AS streak_end, COUNT(*) AS streak_length
FROM grouped
GROUP BY user_id, island_id
ORDER BY user_id, streak_start;

LAG-based equivalent. Instead of arithmetic on the date, compare each row directly to the previous one: flag a new streak whenever activity_date <> prev_date + 1, then take a running SUM of that flag as the group id. This produces the identical grouping, at the cost of one extra window pass; it generalizes more naturally when the gap rule is not a fixed "+1 day" (see below).

Worked example (executed in DuckDB). User 1's activity dates: Jan 1, 2, 3 (a 3-day streak), then Jan 5, 6 (a 2-day streak after a 1-day gap), then Jan 10 (an isolated day).

user_id | streak_start | streak_end | streak_length
1       | 2025-01-01   | 2025-01-03 | 3
1       | 2025-01-05   | 2025-01-06 | 2
1       | 2025-01-10   | 2025-01-10 | 1

The island_id values produced internally were three distinct dates (one per run), confirming the arithmetic correctly separated the three streaks without any explicit gap-detection logic.

Generalizing the same island logic

• Coarser granularity (3+ consecutive weeks). Replace "day" with "week": truncate each activity date to its week start (e.g. date_trunc('week', activity_date)), dedupe to one row per (user, week), then apply the identical date - row_number trick using INTERVAL '1 week' instead of '1 day'. The mechanism is unchanged; only the unit of contiguity changes.
• A per-user variable gap threshold. If "consecutive" means something other than a fixed 1-day gap per user (e.g. some users are only expected to be active every other day), the date-minus-row-number arithmetic trick stops applying cleanly, because it depends on the gap being a fixed, known constant. Switch to the LAG-based form and compare against a per-user threshold column instead of a literal + 1: CASE WHEN activity_date > prev_date + gap_threshold THEN 1 ELSE 0 END.
• A tolerance window on the contiguity test. If a single missed day should still count as "the same streak" (a grace-day rule), change the LAG comparison from <> prev_date + 1 to > prev_date + tolerance_days, i.e. only break the streak when the gap exceeds the tolerance, not on any gap at all.
• The same pattern on a non-boolean series. The identical island logic applies to "3+ consecutive days of declining revenue" or "consecutive growing-revenue days": instead of flagging by date contiguity, flag each row by CASE WHEN revenue < LAG(revenue) OVER (...) THEN 1 ELSE 0 END (a direction change breaks the streak) and take the running SUM of direction-changes as the group id. The grouping mechanism (a monotonically non-decreasing counter that only increments at a boundary) is exactly the same; only the definition of "boundary" changes.

Trade-offs & pitfalls

• Deduplicate same-day activity before ranking (GROUP BY user_id, activity_date first); otherwise a duplicate row inflates streak_length without representing a real extra day.
• The date-minus-row-number trick specifically needs a fixed, known step size (1 day, 1 week); once the gap rule is conditional or per-user, fall back to the LAG-and-cumulative-sum form, which handles any boundary condition you can express as a boolean.
• date - row_number only produces a stable id within one user's partition; always include user_id in the final GROUP BY, or two different users' unrelated streaks that happen to land on the same constant will merge.