It’s common to open Events, filter to a goal (for example a signup or purchase event), and compare that list to the conversion numbers on an experiment report. The totals often look close but not identical.
That usually isn’t a tracking bug. Events and experiment reports use different date rules on purpose. This article explains how each view works and how to cross-check them confidently.
Two views, two questions
| Events (event log) | Experiment report |
Question it answers | “How many times did this event fire in this period?” | “How many experiment visitors in this reporting period converted?” |
Date used | When the event happened (event timestamp) | When the visitor first entered the experiment (first exposure), for who counts toward the report |
Who is included | Anyone on your site who triggered the event | Visitors assigned to a variant in that test |
Typical unit | One row per event (same visitor can appear multiple times) | One visitor counted once per variant in the report totals |
Same underlying data but different filters. That’s why numbers diverge even when Mida is working correctly.
How experiment reporting attributes conversions
For event-based goals, Mida generally does two things:
Assign the visitor to a variant when they enter the experiment (first exposure).
Count a conversion if the goal event happens after they were exposed to that variant (with a small timing buffer).
When you change the reporting date range on an experiment, the report does not re-filter by the day the conversion event fired. It filters by first exposure:
Visitors whose first exposure falls inside the reporting range are included in that period’s visitor and conversion totals.
If someone entered the test before your selected range but converted during it, the conversion event can still appear in Events for those dates—but it is attributed to the reporting period when they first entered the test, not the period when the event occurred.
This keeps experiment results stable: a visitor stays tied to the period they entered the test, instead of “moving” between date ranges when they convert later.
Why your numbers might not match (common cases)
1. Conversion attributed to an earlier reporting period
A visitor entered the experiment in May; the goal fired in June.
Events (June): shows the event.
Experiment report (June only): may not include that conversion in June totals—it belongs to the period when they first entered the test.
What to do: On the experiment report, use the date range that includes their first exposure, or expand the visitor in the event log and check experiment details (see below).
2. Event in range, visitor never in the test
Traffic from pages or journeys outside the experiment can still trigger the same event name.
Events: includes them.
Experiment report: does not.
3. Same visitor, multiple event rows
Events lists each occurrence. The experiment report counts unique visitors per variant for conversions in that reporting logic—not every event row.
4. Different date pickers
The dashboard date range on Events filters by event date. The experiment reporting range filters by first exposure. Always compare using the same intent: “events that fired in June” vs “visitors who entered the test in June.”
5. Conversion before or without valid exposure
Events may show a goal for a visitor who wasn’t in the experiment yet, or who wasn’t assigned to a variant you’re analyzing. The experiment report only credits conversions that meet exposure + goal rules for that test.
How to cross-check step by step
Step 1 — Align what you’re comparing
Events: “All
goal_nameevents between [dates].”Experiment report: “Visitors who first entered this test between [reporting dates] and converted on this goal.”
Write down both questions before comparing totals.
Step 2 — Use the same goal
Confirm the experiment’s conversion goal uses the same event name (or purchase/revenue rule) you’re filtering in Events.
Step 3 — Spot-check visitors in Events
On the event log, open a visitor row (where experiments are shown):
Converted / Not converted — whether they met the goal for that test after exposure.
First seen — when they entered the experiment.
Earlier report period (when shown) — first exposure is before your current Events date range; the conversion is still counted in experiment reporting, but under the period when they entered the test—not necessarily the dates you have selected on Events.
Use the Conversion column tooltip for a short explanation of attribution.
Step 4 — Reconcile a single visitor
Pick one “Converted” row in Events that’s missing from your experiment total:
Note event date (Events).
Note first seen (experiment row).
If first seen is outside your experiment reporting range, open the experiment report for the range that includes first seen—you should see them there.
Step 5 — Expect a band, not a pixel-perfect match
Events totals are often higher than experiment conversions for the same calendar window because Events includes non-participants and multiple fires per visitor. Experiment totals can be lower for the same window when conversions belong to visitors who entered the test earlier.
Quick reference
You see this… | Likely explanation |
More rows in Events than conversions on the report | Non-test traffic, duplicate events per visitor, or conversions attributed to another reporting period |
Event in June, not in June experiment total | First exposure was before June; check experiment report for the period when they entered the test |
Report shows conversions, fewer Events in range | Some visitors entered in-range but converted outside the Events date filter (or event name mismatch) |
Visitor shows “Converted” in Events expand but not in totals | Check First seen vs your reporting range—not event date |
When to contact support
Contact us if:
A visitor was clearly in the experiment (first seen in range), the goal fired after exposure, and they still don’t appear in the experiment report for that same reporting period.
Events show no traffic at all for an event that’s configured as the experiment goal.
Numbers are wildly off with no pattern above (possible installation, goal name, or workspace mismatch).
Include: experiment name/ID, goal name, reporting date range, Events date range, and one example visitor ID from the event log.