Guide 166 · Events · GA4 + Tag Manager
Event count versus event users: the ratio that tells you whether an event fires once or all the time
Two numbers sit side by side in the Events report — event count and total users — and the ratio between them is the reading that matters. A lead at 1.00 per user means one lead per person; a scroll at 4.00 per user means the same people scroll again and again. This guide reads the ratio on three events and shows the two mistakes it catches: a repeat that looks like volume, and a double-fire that looks like engagement.
After the read, each event has one ratio beside it — event count divided by total users — and the events that fire once per user are separated from the events that fire again and again.
Download the reference: the event-count-versus-users reference (JSON) (2436 bytes, MD5 f1371ecf18cdb49bb02cd22185b34dee). It lists the worked example — three events with their counts, users, and per-user ratios — the definitions of both columns, and the rule for reading the ratio. The report itself is not in the file: it lives in Analytics.
What you need
- The Events report open on last week. Reports, then Engagement, then Events, with the date range set to last week ending yesterday — the report needs up to 24 hours for data to appear.
- Both columns, not one. Event count alone is a total; total users alone is a headcount. The reading comes from the ratio, so both numbers are needed for every event.
- An expectation per event. A lead should sit near 1.00 per user; a scroll should sit well above it. The ratio is judged against what the event means, not against other events.
The worked example
The read below is the same week as the Events report guide, with the ratio written out for each event. The number that surprises first is the scroll: 4.00 per user.
| Event | Event count | Total users | Per user |
|---|---|---|---|
| scroll | 1,240 | 310 | 4.00 |
| page_view | 980 | 490 | 2.00 |
| generate_lead | 15 | 15 | 1.00 |
| Scroll users as a share of page-view users | 310 / 490 = 63.27% |
Those figures were recomputed here before publication: 1,240 divided by 310 is 4.00 scrolls per user; 980 divided by 490 is 2.00 page views per user; 15 divided by 15 is 1.00 lead per user; 310 divided by 490 is 0.6327, so 63.27% of the visitors who viewed a page also scrolled.
The trace
- Open the Events report on last week. Sign in to Google Analytics, select Reports, click Engagement, then Events, and set the date range to last week ending yesterday. This step needs a Google sign-in, so it was traced to Google's documentation, not run here.
- Compute the ratio for each event. For each row, divide event count by total users. The report shows the result as event count per active user, so the arithmetic is a check on the column, not a new number: scroll is 1,240 divided by 310, which is 4.00.
- Sort the events by what the ratio should be. Put the events that should fire once per user in one group — generate_lead at 1.00 — and the events that should fire many times in another — scroll at 4.00, page_view at 2.00. A group with a ratio in the wrong place is the finding.
- Read the once-per-user group first. A lead at 1.00 per user is healthy: fifteen leads from fifteen users. A lead at 2.00 per user would mean users submit twice — a form that lets people submit again, or a double-fire. The double-fire guide covers the second cause.
- Read the repeat group second. A scroll at 4.00 per user is healthy: scrolling is a repeat action. A scroll at 1.00 per user would be the anomaly — it would mean the scroll trigger fires once per user and never again, which usually means the trigger is misconfigured.
- Do not sum the users. Total users do not sum across rows, because one user can trigger several events. The 310 users who scrolled are inside the 490 who viewed a page; 310 divided by 490 is 63.27%, which is the share of visitors who scrolled at all.
Dead ends
DEAD END — READING EVENT COUNT AS USERS. An event count of 1,240 is not 1,240 people. It is 310 people scrolling four times each. A count read as a headcount overstates the audience by the ratio itself.
DEAD END — A RATIO OF 2.00 READ AS ENGAGEMENT. An event that should fire once per user and sits at 2.00 is not twice as engaging — it is firing twice. The double-fire guide covers the diagnosis, and the first check is whether two tags send the same event.
DEAD END — COMPARING RATIOS ACROSS DIFFERENT EVENTS. A scroll at 4.00 and a lead at 1.00 are not comparable numbers: one is a repeat action and the other is a once-per-person action. The ratio is judged against what the event means, and a cross-event ranking by ratio is meaningless.
End state
One ratio per event, each judged against its own expectation. Leads sit near 1.00 per user, repeat actions sit above it, and a once-per-user event sitting at 2.00 gets the double-fire diagnosis instead of a celebration. The double-fire guide is the next step when the ratio is wrong.
Sources
- Analytics Help — Events report — the Events report shows how many times each event is triggered and how many users trigger each event; event count is the number of times users triggered an event; total users is the number of unique users who triggered at least one event; event count per active user is the average number of events triggered per user
- Analytics Help — About events — the Event count by Event name card in the Realtime report shows each triggered event in the last 30 minutes
Checked 11 November 2026. The click paths above are the ones in Google's help and developer pages, opened 11 November 2026. No step in this guide was run inside a live Analytics property or a live Tag Manager container, because both need a Google sign-in and this site does not sign in as anyone. What was run: the reference file was validated structurally in Python 3.12.3 — it parses, three event rows are present with their counts, users, and ratios — and the ratios were recomputed: 1,240 / 310 = 4.00; 980 / 490 = 2.00; 15 / 15 = 1.00; 310 / 490 = 63.27% of page-view users also scrolled. Google moves menu items without warning; if a path on this page no longer matches, the linked help page is the current map.