Traffic acquisition

What sets this report apart#

Traffic acquisition lives at /traffic and its unit of counting is the session. Each session is attributed to the touch that brought that session in — the source, medium and campaign of the session's own first event.

That sounds obvious, but it is precisely the point that used to be wrong, and fixing it moved the numbers visibly. Before, the report grouped sessions by the user's lifetime first touch. A returning customer who clicked a Facebook ad today was reported under the Google ad that had found them six months earlier. Every returning visitor — the best part of your audience — was misattributed, systematically, and newer campaigns always looked weaker than they were.

The division of labour is now clean:

Primary and secondary dimensions#

The primary dimension is the table's first column and is changed from the control above the table. There are six options, all session-scoped:

• Session primary channel group
• Session source / medium
• Session source
• Session medium
• Session campaign
• Session source platform — the type of click ID the session arrived with, or Manual when there is none

+ Secondary dimension adds a second grouping column, organised into four groups: Traffic source (source, medium, source / medium, campaign), Page / screen (hostname, page path, landing page), Geography (country, region, city), and Platform / device (device category, browser, operating system).

The secondary dimension is read from the session's first event too. So "landing page" really is the page that session entered on, and "country" is where the session started.

Your dimension, secondary dimension, time grain, sort column and rows-per-page are remembered and restored the next time you open the report.

The columns#

The table is ordered by sessions and returns up to 500 rows.

Engaged sessions#

A session is engaged when at least one of these holds:

1. engagement time of at least 10 seconds;
2. at least two page views;
3. at least one key event.

Bounce rate is nothing but the inverse: bounce rate is 100 minus the engagement rate. If engagement rate is 62%, then 38% of sessions bounced. That is why there is no separate bounce column here — it is the same number, viewed from the other side.

Where engagement time comes from#

Avg. engagement time is built from the user_engagement event. The tracker emits it when the page is hidden and on every route change in a single-page app, carrying the real time spent on that page in the engagement_time_msec parameter. Any span longer than thirty minutes is discarded, so a forgotten background tab cannot report a fake multi-hour dwell.

What is not used for it is the server's event receipt time. Events are sent in batches, so the spread between a session's first and last receipt time says nothing about how long the person was actually there.

The chart and the time grain#

The chart above the table plots sessions over time, split by the same primary dimension, with Day / Week / Month on the card's control. Day and month buckets are cut in the property's timezone; the week bucket starts on Monday.

Chart and table are built at one grain: both count one row per session. Search the table's rows and the chart narrows to the same surviving values.

With period comparison on, the headline metrics show the change and the previous period is drawn on the chart.

Working the table#

• Sort on any column by selecting its header.
• Row search filters the rows, and while it is active the Total row reports the filtered set's share of the whole.
• Share of total appears under each summed column; for rate and time columns you get the distance from the average instead.
• The per-column event picker narrows two things: Event count to any single event, and the key-event columns (with their revenue) to one specific key event. This is the same move as picking an event in a GA4 column header.
• Below the table, the events counted as key events are listed alongside the engaged-session definition.

Getting attribution right when checkout goes through a payment gateway#

This deserves its own section because it lands directly on this table. When a customer pays, the gateway redirects them back to your site, and the browser reports that return as a referral from the gateway's domain. Left alone, the session that converts files under the bank's referral and the sale is credited to the payment processor; the ad channel looks unprofitable and budget moves on a wrong number.

AdPix demotes known payment gateways at collection time — exactly the way it treats a referral from your own domain — and then restores that visitor's durable last touch, so the converting session is not left with no campaign at all. The base list covers the Shaparak switch, the local gateways and the global processors, and each property can add its own hosts.

Small print you will end up needing#

• Server-side events carry no session and do not appear in session counts; they are fully present in event counts, key events and revenue.
• Users here is counted from the visitor ID, so one person on two browsers is two users. To join them into one person, see how AdPix identifies visitors.
• Test-mode events are not counted in any row.
• Total revenue sums the value parameter without separating currencies; for a per-currency split, use the e-commerce report.

Frequently asked questions#

Related#