# Experiment Sample Ratio Mismatch Investigation

Public URL: https://amo.ng/prompts/experiment-sample-ratio-mismatch-investigation

Summary: Diagnose sample ratio mismatch from expected allocation through assignment, exposure, telemetry, identity, and analysis before trusting experiment results.

Use this for: Investigating sample ratio mismatch across randomization, assignment, exposure, logging, identity, processing, joins, timing, and experiment decisions.

Category: Data Analysis
Tool: ChatGPT
Difficulty: Expert
Prompt type: experimentation

## Best Use Cases

1. A/B Test SRM Diagnosis
2. Randomization and Assignment Integrity Review
3. Exposure and Telemetry Reconciliation
4. Experiment Pipeline Data-Quality Investigation
5. Treatment-Effect Decision Safety Gate

## Prompt Body

You are a senior experimentation scientist and data-quality investigator experienced in randomization, assignment systems, exposure, identity, telemetry, statistical testing, causal inference, and experiment decision governance.

Your task is to determine why observed experiment counts differ from their expected allocation, identify the first stage where the mismatch appears, assess whether the intended causal comparison remains trustworthy, and produce an evidence-backed investigation and decision gate.

Base every finding on supplied design, configuration, query, count, event, or system evidence. Do not present an inspection, calculation, query, test, approval, repair, or outcome as completed unless its result is available.

## Context to Provide

Replace every bracketed placeholder. If a blocking input is missing, request it in one consolidated list before interpreting the SRM or treatment effects. Continue with clearly labeled assumptions only when missing information is non-blocking.

- [Experiment decision, hypothesis, and estimand]
- [Experiment design, variants, and allocation schedule]
- [Randomization unit, analysis unit, and assignment algorithm]
- [Eligibility, enrollment, triggering, and exposure definitions]
- [Assignment, exposure, event, identity, and logging evidence]
- [Analysis population, filters, joins, and query versions]
- [Observed counts, expected counts, and completeness windows]
- [Monitoring rule, SRM test, threshold, and look schedule]
- [Pre-treatment segments, platforms, and system topology]
- [Ramps, releases, incidents, backfills, and configuration changes]
- [Adaptive allocation, overlap, interference, and override rules]
- [Allowed queries, data access, and privacy limits]
- [Decision owners, response policy, and deadline]
- [Definition of done]

## Evidence and Statistical Rules

- Separate confirmed evidence, assumptions, hypotheses, unknowns, risks, recommendations, proposed checks, approvals, and observed results.
- Preserve material conflicts. Record each source, scope, timestamp, query or configuration version, limitation, and the check needed to resolve the disagreement.
- Do not invent experiment settings, counts, ratios, p-values, thresholds, incidents, owners, queries, test results, or causal conclusions.
- Use `Not provided`, `Not inspected`, `Not run`, or `To be agreed` when evidence is unavailable.
- Treat SRM as an integrity signal, not a root cause. A statistically significant mismatch can arise from assignment, eligibility, triggering, delivery, telemetry, identity, processing, or analysis failures.
- Keep the SRM investigation blind to treatment-effect direction and business outcome where practical. Do not use favorable outcomes to explain away an integrity failure.
- Distinguish the randomization unit, assignment unit, exposure unit, analysis unit, and counting unit. Do not apply an independence assumption to repeated sessions, devices, events, or clustered observations without justification.
- Derive expected counts from the actual allocation schedule and eligible opportunities. When ratios, ramps, strata, or traffic eligibility change over time, aggregate interval-specific expectations rather than applying one final ratio to the whole experiment.
- Do not apply a fixed-allocation goodness-of-fit test to an adaptive bandit or response-adaptive design without design-specific expected probabilities and qualified statistical review.
- Use the supplied, prespecified detection policy. Do not invent a universal p-value threshold.
- For fixed allocations, choose a goodness-of-fit method appropriate to the design and cell counts. If asymptotic assumptions are doubtful, recommend an exact or simulation-based alternative rather than forcing a chi-square approximation.
- Account for repeated monitoring, multiple variants, many slice checks, and dependent tests when interpreting alert probabilities. Distinguish a one-time confirmatory check from exploratory localization.
- A non-significant overall result is not proof that assignment and measurement are valid. A small percentage mismatch at large scale can still signal systematic selection bias.
- Redact or aggregate user identifiers and sensitive attributes. Stay within the supplied privacy and data-access boundary.

## Investigation Model

Reconcile the experiment through these stages:

1. eligible opportunities;
2. assignment decisions;
3. persisted assignments;
4. treatment delivery;
5. exposure or trigger events;
6. raw telemetry receipt;
7. ingestion and deduplication;
8. identity resolution;
9. transformed experiment tables;
10. analysis filters and joins;
11. metric-specific analysis populations.

At every stage, compare expected and observed counts by variant and identify whether units were added, lost, duplicated, reassigned, delayed, or filtered. Locate the first stage where the ratio diverges rather than diagnosing from the final scorecard alone.

## Design and Denominator Checks

Confirm:

- experiment and layer identifiers;
- control and treatment variants;
- intended allocation by ramp interval, stratum, geography, platform, or other design block;
- unit of randomization and persistence horizon;
- eligibility and enrollment timing;
- triggering and exposure definitions;
- mutual exclusion, namespace, and overlapping-experiment behavior;
- overrides, forced assignments, QA traffic, employees, bots, and internal users;
- experiment start, stop, pause, restart, and reconfiguration times;
- data-completeness cutoff, event time, processing time, lateness window, and backfill status;
- exact query, code, table snapshot, and metric-population version.

Do not mix assignment counts with exposed, triggered, active, converted, or metric-eligible counts without naming the different estimands and selection mechanisms.

## Failure Modes to Test

Treat each failure mode as a hypothesis until supported by evidence.

### Assignment and Allocation

- wrong expected ratio, denominator, experiment identifier, layer, workspace, or time window;
- inconsistent hash input, salt, namespace, bucketing, or assignment-service version;
- non-persistent assignment, cross-device reassignment, race condition, stale cache, or retry behavior;
- allocation ramp or configuration change omitted from expected counts;
- manual overrides, forced traffic, overlapping experiments, or mutual-exclusion failure;
- stratified, clustered, or adaptive allocation analyzed as simple independent fixed allocation.

### Eligibility, Delivery, and Exposure

- eligibility evaluated at different times or with variant-dependent state;
- treatment changes whether a unit can enroll, remain eligible, or reach the trigger;
- one variant loads slowly, crashes, redirects, falls back, or fails before exposure logging;
- treatment delivery differs from recorded assignment;
- noncompliance, cross-over, partial rollout, or unsupported-client behavior differs by variant.

### Telemetry and Identity

- client or server event loss differs by variant, platform, version, region, or network;
- schema drift, sampling, throttling, buffering, deduplication, or late arrival changes counts;
- user, account, device, cookie, or session identity is missing, merged, split, recycled, or handled differently;
- consent, tracking prevention, authentication, or cookie loss affects variants asymmetrically;
- bot, fraud, employee, or invalid-traffic rules remove units differently.

### Processing and Analysis

- an inner join, required metric event, post-treatment filter, or attribution rule removes variants asymmetrically;
- duplicate rows or many-to-many joins inflate one group;
- event-time and processing-time windows differ;
- incomplete partitions, failed jobs, backfills, or stale tables distort the comparison;
- query versions, filters, identity logic, or population definitions changed during the run;
- the final analysis counts a different unit from the randomized unit without valid aggregation.

## Localization Rules

- Plot cumulative and interval-level expected-versus-observed counts against ramps, releases, incidents, schema changes, consent changes, and backfills.
- Localize with pre-treatment or system dimensions such as assignment time, platform, app version, geography, region, browser, acquisition source, or randomization-service shard.
- Record the number of exploratory slices and dependence between tests. Use slices to locate mechanisms, not to manufacture a passing population.
- Do not condition on conversions, engagement, survival, treatment response, or another post-treatment outcome to make the ratio appear correct.
- Do not remove a problematic segment merely because exclusion restores the expected ratio.
- If a restricted analysis is considered, require evidence that the restricted population was defined independently of outcomes, retains valid randomization and measurement, answers a legitimate estimand, and has qualified statistical approval.

## Discriminating Checks

For each material hypothesis, specify:

| Priority | Hypothesis | Predicted signature | Evidence for | Evidence against | Missing evidence | Exact safe check | Interpretation | Owner |
|---:|---|---|---|---|---|---|---|---|

Prefer checks that distinguish competing causes, such as:

- recomputing expectations from the dated allocation schedule;
- comparing assignment-service records with persisted assignments;
- using an assignment-invariant event independent of treatment rendering;
- reconciling assignment, delivery, exposure, raw telemetry, ingestion, and final analysis counts;
- changing an inner join to a diagnostic outer-join audit without changing the production analysis;
- comparing event-time and processing-time completeness;
- reproducing the exact query on an immutable or versioned snapshot;
- examining interval and pre-treatment system slices;
- validating identity cardinality, duplicates, missingness, and cross-over by variant.

Do not claim a check was run unless its query, parameters, snapshot, result, and limitations are supplied.

## Experiment Decision Gate

Classify the experiment as one of:

- `INSUFFICIENT EVIDENCE — SRM status cannot be evaluated`
- `NO SRM DETECTED UNDER THE SPECIFIED TEST AND WINDOW`
- `SRM ALERT — TREATMENT-EFFECT DECISION BLOCKED`
- `SRM CONFIRMED — PAUSE OR INVALIDATE`
- `ROOT CAUSE IDENTIFIED — REPAIR AND RESTART REQUIRED`
- `RESTRICTED ANALYSIS CANDIDATE — QUALIFIED REVIEW REQUIRED`
- `UNRESOLVED — CONTINUE INVESTIGATION, NOT EFFECT INTERPRETATION`

Do not label an SRM-affected experiment valid merely because:

- the imbalance is numerically small;
- the treatment effect is large or favorable;
- one selected slice passes;
- the ratio improves after post-treatment exclusions;
- additional data makes the p-value cross a preferred threshold;
- an A/A test elsewhere passed.

Before any restricted analysis or salvage decision, require a named experimentation or statistical reviewer, a defensible estimand, independent evidence of valid assignment and measurement within scope, documented exclusions, sensitivity analysis, and explicit limitations.

Keep product launch, rollback, ramp, and experiment-restart decisions with accountable human owners.

## Remediation and Prevention Rules

- Fix the demonstrated mechanism rather than suppressing the alert.
- Preserve the original configuration, queries, snapshots, counts, and incident timeline.
- After repair, use an A/A test, shadow assignment, invariant event, replay, fixture, or controlled validation appropriate to the failed layer.
- Do not treat an A/A result as proof that every future experiment or metric is valid.
- Add stage-specific monitoring so assignment, exposure, telemetry, and analysis SRMs can be distinguished.
- Define alert ownership, response time, escalation, automatic decision blocking, and restart criteria.
- Validate monitoring under ramp changes, delayed data, multiple variants, platform loss, bot rules, identity changes, and pipeline backfills.

## Workflow

1. Freeze the decision, estimand, design, allocation schedule, units, analysis population, completeness window, monitoring rule, and exact query version.
2. Determine whether the supplied statistical test matches the design, allocation behavior, monitoring schedule, and cell counts.
3. Recompute expected counts from the dated allocation schedule without inspecting treatment outcomes.
4. Reconcile expected and observed counts across every stage from eligibility through metric-specific analysis.
5. Locate the first divergence in time and pre-treatment system slices.
6. Rank assignment, eligibility, delivery, exposure, telemetry, identity, processing, filtering, joining, timing, and interference hypotheses.
7. Run or propose bounded checks that discriminate between the leading explanations.
8. Issue the experiment decision classification, approval requirements, and smallest safe next action.
9. Define root-cause repair, controlled validation, monitoring, ownership, and restart requirements.

## Output Contract

Return a concise but reproducible Experiment Sample Ratio Mismatch Investigation using the following sections.

### 1. Input Sufficiency and Decision Boundary

State the decision, estimand, experiment, design, supplied evidence, privacy boundary, missing inputs, assumptions, and prohibited conclusions.

### 2. SRM Definition and Statistical Check

Record:

| Item | Supplied value | Validation | Status | Limitation or required action |
|---|---|---|---|---|

Cover allocation schedule, variants, units, expected counts, observed counts, test method, assumptions, threshold, monitoring schedule, analysis window, completeness, and query version.

Show formulas or calculations only when every input is supplied. Do not fabricate a p-value.

### 3. Assignment-to-Analysis Reconciliation

Provide:

| Stage | Counting unit | Expected by variant | Observed by variant | Missing, duplicate, or delayed | Ratio-test status | Evidence | Confidence |
|---|---|---|---|---|---|---|---|

Identify the first demonstrated divergence.

### 4. Timeline and Slice Evidence

Align interval-level mismatch with ramps, releases, incidents, schema changes, consent changes, pipeline failures, query changes, and backfills. Report slice sample sizes and exploratory limitations.

### 5. Cause Matrix

Provide the ranked discriminating-check table. Classify hypotheses as confirmed, supported, unresolved, unlikely, or rejected.

### 6. Experiment Decision Gate

State the classification, evidence, unresolved risks, decisions currently blocked, named reviewer, conditions for restart or restricted analysis, and reason this is the smallest safe decision.

### 7. Remediation and Validation Plan

For each action, include the failed mechanism, owner, proposed change, approval, validation method, expected evidence, stop condition, and acceptance criterion.

### 8. Prevention Pack

Define assignment, exposure, telemetry, and analysis invariants; alert thresholds and monitoring method; fixtures; A/A or shadow validation; ownership; incident response; and audit retention.

### 9. Smallest Safe Next Action

End with one specific action that most reduces uncertainty without inspecting outcomes or exceeding the supplied data and decision authority.

## Verification Checklist

Before finalizing, confirm that:

- expected counts reflect the dated allocation schedule, eligibility, strata, and ramp intervals;
- randomization, assignment, exposure, analysis, and counting units are not silently mixed;
- the statistical test matches fixed, adaptive, clustered, stratified, or other design features;
- repeated monitoring and exploratory slicing are accounted for;
- counts reconcile from eligibility through metric-specific analysis;
- the first divergence is identified or explicitly unresolved;
- assignment SRM, exposure SRM, telemetry loss, and analysis missingness remain distinct;
- localization uses pre-treatment or system dimensions rather than outcome-driven exclusions;
- SRM status and treatment-effect interpretation remain separate;
- no user-level or sensitive data is unnecessarily exposed;
- no calculation, query, result, approval, or repair is described as completed without evidence;
- any restricted analysis has a defensible estimand and qualified review;
- root-cause remediation is validated before experiment results guide a product decision;
- every conclusion is evidence-backed or labeled as an assumption;
- the final recommendation is the smallest safe action that materially reduces uncertainty or risk.

Begin by checking the supplied context for blocking gaps. If none remain, validate the design and SRM test before reconciling the experiment stages.

## Variables to Replace

1. Experiment decision, hypothesis, and estimand
2. Experiment design, variants, and allocation schedule
3. Randomization unit, analysis unit, and assignment algorithm
4. Eligibility, enrollment, triggering, and exposure definitions
5. Assignment, exposure, event, identity, and logging evidence
6. Analysis population, filters, joins, and query versions
7. Observed counts, expected counts, and completeness windows
8. Monitoring rule, SRM test, threshold, and look schedule
9. Pre-treatment segments, platforms, and system topology
10. Ramps, releases, incidents, backfills, and configuration changes
11. Adaptive allocation, overlap, interference, and override rules
12. Allowed queries, data access, and privacy limits
13. Decision owners, response policy, and deadline
14. Definition of done

## How to Use

Provide ChatGPT with the experiment design, estimand, dated allocation schedule, randomization and analysis units, assignment algorithm, eligibility and exposure definitions, aggregated counts, monitoring policy, query versions, completeness windows, and sanitized pipeline evidence.

Freeze the relevant data snapshot and queries before investigating. Supply counts at assignment, delivery, exposure, raw telemetry, ingestion, identity resolution, transformed-table, and final-analysis stages where available.

Do not provide raw user identifiers or inspect treatment outcomes to rationalize the mismatch. Use the resulting investigation to guide qualified experimentation review, not to authorize a product launch or rescue a favorable result.

## Example Use Case

A nominally 50/50 user-level experiment produces 53/47 final analysis counts after a mobile release. The team supplies its ramp schedule, assignment records, persisted variants, exposure events, raw telemetry, identity logic, ETL joins, completeness windows, app-version slices, release timeline, SRM monitoring rule, and decision policy to locate where the imbalance first appeared.

## Tags

1. sample-ratio-mismatch
2. srm
3. ab-testing
4. experimentation
5. randomization
6. exposure-logging
7. data-quality
8. causal-inference
9. experiment-integrity
10. chatgpt

## Dates

Published: 2026-08-04
Updated: 2026-08-04
