Events
Why Your Success Event Is Higher Than Your Start Event
Updated 2026-09-144 min read
Short answer
Event counts are not people, and nothing links a start event to a success event unless you design it to. Success usually outnumbers start because it fires more than once per task, because start is missing for some users or app versions, or because the two are counted over different paths or date edges. A funnel that follows the same users in order can never show more completions than starts.
The dashboard says 1,180 exports finished and 940 started. Someone works out a completion rate of 126% and the meeting moves on. It should not: a rate above 100% is not a strong result, it is proof that the two events are not measuring the same journey.
What it looks like
Events Users export_start 940 610 export_complete 1,180 590 By events: 1,180 ÷ 940 = 126% ← impossible By users: 590 ÷ 610 = 97% ← not a completion rate either
The user-based figure looks plausible, which makes it more dangerous than the impossible one. Nothing says the 590 people who completed are among the 610 who started, or that they started first.
Why success outnumbers start
| Cause | How it happens |
|---|---|
| Success fires more than once per task | It is logged in a callback that runs on every retry, every time the result screen appears, or again when the user comes back to that screen |
| Start is missing for some people | It is logged before Analytics is initialised or before consent is given, or it was added in a newer app version while older versions only send success |
| Another path reaches success | A shortcut, widget, share extension or deep link completes the task without passing the screen that logs start |
| Date range edges | Tasks started before the range and finished inside it count as a success with no start |
| Background or restored results | A sync, a background upload or a restored purchase finishing later logs success again |
| Two platforms, one event name | iOS logs both events, Android logs only success, and the property adds them together |
How to check
Compare events per user for each event
Divide event count by users for both events. In the example, export_complete runs at 2.0 events per user and export_start at 1.5 — success is firing repeatedly.
Break both events down by app version and platform
A version or platform where start is zero and success is not points to missing instrumentation, not to user behaviour.
Watch a single task in DebugView
Put one device in debug mode and perform the task once. Then fail it, retry, and return to the result screen. Duplicate firing shows up within minutes.
Build a closed funnel
In a GA4 funnel exploration, add start and then success as ordered steps. The funnel counts only people who did both, in that order — the figure the ratio was pretending to be.
Tip: Give the start and success events a shared parameter, such as a task ID created when the task begins. Duplicates become visible, and each success can be tied to the start that produced it.
What goes wrong if you misread it
- A rate above 100% gets read as "almost everyone finishes", and a broken flow is never examined
- A fix that removes a duplicate success event looks like a collapse in completions
- Dividing the users of two unrelated events looks like a conversion rate and passes review
- Retention, revenue or alerts built on the inflated event carry the error forward
Designing the pair so it cannot happen
- Log start once, when the user commits to the task — not when the screen appears
- Log success once per task, where the result is confirmed, never on screen appearance
- Log failure and cancellation as their own events, so a task that ends without success still ends in the data
- Ship both events in the same release, on every platform, with identical names
How this looks in Appnaly
This is why Appnaly only shows a completion rate for a core feature when it can verify the sequence. When you mark a start event and a completion event, Appnaly asks GA4's funnel report for the people who did one and then the other. If that report cannot be run, it shows the users and event counts for each side and deliberately shows no rate, because dividing two event counts can produce a percentage out of people who never did the second step at all.