# Sessions and bounce rate look wrong

A bounce rate that seems far too high, sessions that outnumber users, or an average duration that matches nothing you believe. It is almost always one of three things: a definition that differs from the one in your head, a comparison against a number taken before the data fix, or a page view being counted twice.

## The symptom that brought you here

This page has six checks, ordered by how often each one turns out to be the answer. The table says where to start.

| What you are seeing | Start at |
| --- | --- |
| Two "engagement" numbers on two screens disagree | Check 1 |
| Bounce rate does not match an old report or last year's screenshot | Check 2 |
| Numbers are a few percent off another tool, or off your daily expectation | Check 3 |
| Bounce rate suddenly hit zero or near zero | Check 4 |
| Average session duration is zero or a few seconds | Check 5 |
| Sessions are lower than you expected | Check 6 |

## Check 1 — are you mixing up two definitions?

Most "wrong numbers" are not wrong at all; they are a metric whose definition differs from the one you assumed. Read these five once:

| Metric | The exact definition in AdPix |
| --- | --- |
| Session | A visitor's events up to 30 minutes of inactivity. The window rolls: every new event restarts the 30 minutes. |
| Bounce | A session with one page view or fewer. |
| Engagement (the Home card) | 100 minus the bounce rate — the share of sessions with more than one page view. |
| Engaged session (Traffic acquisition) | A session with a duration of at least 10 seconds **or** at least 2 page views **or** at least one key event. |
| Average session duration | The average of each session's total `engagement_time_msec` — the time the tracker actually saw the visitor active on the page. |

> **The two engagement numbers differ on purpose**
>
> The **Engagement** card on Home is only the complement of bounce rate and looks at page views alone. The **Engagement rate** column in Traffic acquisition uses the full engaged-session definition and also accepts duration and key events. So a session with one page view where the visitor stayed thirty seconds counts as a bounce on Home and as engaged in Traffic acquisition. The Traffic acquisition figure is always greater than or equal to the Home one.
>
> The Traffic acquisition report prints the definition under its own chart: "Engaged session = duration ≥ 10s OR ≥ 2 views OR a key event." When you report a number upward, say which screen it came from.

A second point: **key events feed the engaged-session definition.** Mark an event as a key event today under **Admin → Key events** and past engagement rate rises immediately, because the key-event list is applied when the report is read, not when the data is collected.

## Check 2 — are you comparing against a pre-fix number?

If your reference is an old screenshot, an archived CSV or a slide from a past meeting, there is a good chance that number was wrong to begin with.

Session records used to be written every time the tag shipped a batch of events. A session whose events arrived over several batches — which is nearly every real session — was split into several fragments, and none of them ever collapsed onto the others. Measured on a live installation: **464,039 session rows for 25,099 real sessions**, roughly 18.5x.

Everything that read from those records was computed over the fragments:

| What | Direction of the error | Why |
| --- | --- | --- |
| Bounce rate | far too high | a fragment holding a single page view looked like a bounced session |
| The Engagement card on Home | too low | it is the complement of that bounce rate |
| Session filters in heatmaps | invalid | "first session" and "returning session" were counted per fragment, not per session |
| Marketing Mix and Lift study inputs | inflated | both read session counts from the same records |

The **Sessions** count in the reports does not come from that path and was correct — its disagreement with bounce rate is exactly what made the defect visible.

The defect is fixed: sessions are now keyed only by their own identity, so a session's events merge into one row no matter when they arrive. Existing session records were rebuilt from the events themselves, so what you see in the console today is the correct figure.

> **Do not treat an old export as the baseline**
>
> If today's console disagrees with a report you archived earlier, and the gap runs in the direction of the table above — lower bounce rate, fewer sessions — that is the fix, not a new fault. Take today's number as the baseline and add a note to your own historical reporting stating the date from which the series was recomputed.
>
> There is nothing for you to run. Rebuilding the records is a platform-side operation and it has been done. If a property still shows signs of fragmentation — a bounce rate near 100% while page views per session are plainly above one — contact support with the property ID and the date range.

## Check 3 — date range, time zone and session boundaries

Three things that account for a few percent of difference:

- **Every range is evaluated in the property's time zone**, not your browser's. If the property is still on `UTC` and you read reports from Tehran, your "yesterday" and the report's "yesterday" are three and a half hours apart, which shows up far more sharply in an hourly chart. The setting is at **Admin → Property details → Time zone**. Changing it also changes the past, because bucketing happens at read time.
- **Boundary sessions are not counted identically by every metric.** The session count includes any session with an event in the range; bounce rate, sessions per user and average duration are computed over sessions whose **start** falls in the range. A session that began at 11:30 pm and ran past midnight is in one and not the other. On short ranges — a day, an hour — this is visible; over 28 days it is effectively invisible.
- **Comparison builds a second range, it does not filter.** If the previous-period figure looks odd, first look at the range the date picker actually built.

## Check 4 — bounce rate suddenly hit zero

If your bounce rate went to zero or near zero from one specific day, and Engagement went to 100%, look at another number: page views. If that roughly doubled on the same day, you have your answer.

When every page view is counted twice, no session is left below two views, so by definition nothing qualifies as a bounce. The usual causes:

- an extra `ap('page')` call next to `init` — `init` already sends the first page view and installs the single-page-app history hook;
- two copies of the tag on one page, for example one in the site template and one from a plugin.

Both are unpacked in [Page views are counted twice](analytics/troubleshooting/page-views-counted-twice). For single-page-app behaviour, see [Page views and single-page apps](analytics/collect/spa-and-page-view).

The mirror image also exists: if bounce rate climbed for no reason, check whether page views fell the same day — a tag that stopped firing on part of your site produces exactly that shape.

## Check 5 — average session duration is zero or a few seconds

AdPix does not build duration from the gap between event timestamps. Event time is the moment the event was **received by the server**, and the tag sends events in batches; if duration were built from those timestamps, most sessions would come out at zero seconds. Instead the tracker measures the visitor's real active time itself and sends it as the `engagement_time_msec` parameter on a `user_engagement` event; the reports sum that.

The signal is emitted when the tab is hidden or the page is left, and each emission is capped at 30 minutes so a tab forgotten in the background cannot report hours.

If the figure is zero or unrealistically short, work through this order:

1. In the Events report, check whether the `user_engagement` event exists at all. If it does not, the problem is in collection, not in reporting.
2. Check the installed tag version. The install snippet is generated at **Admin → Data streams** and carries its version; very old versions do not send this signal.
3. If the consent banner is on, check whether statistics consent is being granted. Without it no event is sent at all, including this one. The path is [Consent is blocking data](analytics/troubleshooting/consent-is-blocking-data).
4. Rule out real behaviour: traffic that arrives on one click and leaves genuinely has a duration close to zero. If only one channel shows zero duration and the rest are healthy, this is not a data problem.

One question that comes up often: mobile browsers do not always give the page a chance to send that last signal. So average duration on mobile is usually a little lower than on desktop. A few percent is normal; a multiple is not.

## Check 6 — sessions are lower than expected

Three things are deliberately absent from session metrics:

- **Server-side events have no session.** An order posted from your backend or a CRM module did not happen in a browser, and AdPix deliberately does not invent a session for it — otherwise every order would become a new "session" and distort conversion rate. These events are fully present in event counts, key events, revenue and user attribution; they are missing only from metrics whose unit is the session. See [Server-side tracking](analytics/collect/server-side-tracking).
- **Excluded IP ranges are not counted.** The list is at **Admin → Property details → Excluded CIDRs**. If you put your own office there, internal traffic should not appear. The drop happens at the collector, so those visits create no session at all.
- **Under opt-in, a visitor who has not yet answered the banner sends no events at all** and therefore creates no session.

## If none of that explains it

Before opening a ticket, gather these four things — they cut the investigation roughly in half:

- the property ID and the exact date range, plus which time zone you read it in;
- the name of the screen you took the number from and the exact metric name;
- the number you expected, and where it came from;
- the date the discrepancy started. If it has a clear start date, the change is usually on your site, not in the report.

## Frequently asked questions

### Why doesn't Engagement on Home match Engagement rate in Traffic acquisition?

Because they are two different definitions, both deliberate. Home's Engagement is exactly the complement of bounce rate — every session with more than one page view. Engagement rate in Traffic acquisition uses the full engaged-session definition: duration of at least 10 seconds, or at least 2 views, or a key event. The second number is always greater than or equal to the first.

### My bounce rate suddenly dropped to zero. What happened?

Almost always this means every page view is being counted twice, so no session is left with fewer than two views and nothing qualifies as a bounce. The usual cause is an extra `ap('page')` next to `init`, or two copies of the tag on one page.

### Why is my average session duration zero?

Because AdPix builds duration from the `engagement_time_msec` parameter, not from the gap between the first and last event. If that parameter never arrives — a very old tag version, or statistics consent not granted — the figure stays at zero even when you have page views.

### This year's numbers don't reconcile with an export I saved last year. Which one is right?

The console's current number. Before the data fix, each session was written as several fragments and bounce rate was computed over those fragments. Session records have been rebuilt from the events themselves, so today's console is correct and your old export is no longer the baseline.

## Related

- [The Home page](https://docs.adpix.io/en/analytics/reports/home/)
- [Traffic acquisition](https://docs.adpix.io/en/analytics/reports/traffic-acquisition/)
- [Server-side tracking](https://docs.adpix.io/en/analytics/collect/server-side-tracking/)
- [Page views are counted twice](https://docs.adpix.io/en/analytics/troubleshooting/page-views-counted-twice/)

---

[Docs](https://docs.adpix.io/en/analytics/troubleshooting/sessions-and-bounce-look-wrong/) · AdPix