Browse the documentation

Visitor Analytics

Applies to: Publishers · Ad manager and ad network setups only, when the network has the module switched on

Visitor Analytics gives you a pageview and unique-visitor counter for each of your sites, on top of the ad controller you've already installed — no second script tag, no separate setup.

What this is#

This counts people who visited your site, not ad performance. It's a different number from your ad stats: a page with no ad zone still counts as a visit here, and a page with four ad zones counts as one visit, not four impressions.

It is not a Google Analytics replacement — there are no funnels, no goals, no session paths. It's a lightweight "is anyone actually visiting this site" number, with breakdowns by country, device, OS, browser, ISP and screen resolution, plus your top pages and referrers — and a way to log your own custom events if you want more.

When you'll use this#

  • To check whether a site is getting traffic at all, independently of whether the ads filled.
  • To see where your audience is, on what devices, and which pages carry them.
  • To sanity-check a sudden change in ad impressions — did traffic move, or did fill move?
  • To spot automated traffic hammering one URL.

Step by step#

Turn it on#

  1. Open Publisher → Websites and open the site.
  2. Flip the Visitor analytics toggle in its settings and save.
  3. That's the whole setup. If the ad controller script is already on your pages, pageviews start counting from your visitors' next page load — whether or not that page happens to show an ad.

The only pages this can't see are ones the controller script was never added to. See Getting Your Ad Code for installing it.

Read the report#

  1. Open Visitor Analytics from the publisher menu.
  2. Pick the Website and the Event (Pageview, or one of your own custom events).
  3. Choose a date range.
  4. The summary gives Pageviews, Unique visitors, Today, Avg / day, Avg / hour and the busiest hour.
  5. Below it, the breakdowns: By country, By device, By OS, By browser, By ISP, By screen resolution, plus Top pages and Top referrers.

Log a custom event#

Beyond automatic pageviews you can record your own events — a signup, a video start, a scroll depth — with the controller's Event() call. See Ad Controller (Advanced). Custom events then appear in the Event selector alongside Pageview.

Options reference#

Control What it does
Website Which of your sites to report on. Only sites with the toggle on appear.
Event Pageview, or one of your custom events.
Date range The period all figures cover.
Figure What it means
Pageviews Every page load (and every client-side navigation — see below).
Unique visitors Distinct visitors in the period.
Today Pageviews so far today.
Avg / day, Avg / hour Averages across the selected range.
Busiest hour The hour of day with the most traffic.
Breakdown What it splits by
By country Visitor location.
By device Desktop, mobile, tablet, …
By OS / By browser Visitor software.
By ISP Network provider.
By screen resolution Viewport size — useful when choosing zone sizes.
Top pages The URLs carrying your traffic.
Top referrers Where visitors came from. (direct — no referrer) means they arrived with no referrer.

Single-page apps#

Most sites today don't do a full page reload on every navigation. The controller accounts for this itself — once enabled, it also tracks client-side route changes (history.pushState, back/forward navigation, hash changes), so a visitor moving through your app without a real page load still gets counted correctly, page by page.

What's tracked#

Per pageview or custom event: which site, roughly when, country and device type, and — for pageviews — the page URL (query string stripped after a short window; full URLs are kept only briefly for debugging).

Visitor identity is a hash derived from the visitor's IP and browser, not a cookie — nothing is stored on your visitors' device for this feature, and it's recomputed per request rather than persisted, so it can't track someone across days as precisely as a cookie-based system would. That's a deliberate tradeoff: no cookie means no consent-banner burden for you specifically for this feature.

Bots and crawlers#

Search-engine crawlers, scrapers and other automated clients are not counted. Every visit is classified the same way it is for your ad stats, and only real visitors reach these numbers — so the counter here and your ad reports agree about what a visit is.

Automated traffic that gets past that classification looks like a very high pageview count next to a very small visitor count: one client requesting the same URL over and over for hours is one visitor and thousands of pageviews. If your pageviews-per-visitor number looks extreme, open the Top pages breakdown — that shape is nearly always one or two URLs being hammered, not a counting error.

Limits#

Ad-blocked visitors aren't counted — the same limitation the ad controller has. If a visitor's browser or an extension blocks the controller script entirely, nothing about their visit reaches us. Expect this number to run somewhat lower than a general-purpose analytics tool that uses different blocking-evasion techniques.

Privacy#

Because this uses IP-derived data, it's worth a line in your own privacy policy if you don't already cover the ad controller there. We don't store raw IP addresses for this feature — only the derived hash — and there's no cookie set. If your audience is in a jurisdiction with strict analytics-consent rules, check with your own counsel; this doc isn't legal advice.

Example#

Diagnosing a drop in earnings. Ben's revenue halved overnight and he wants to know whether he lost traffic or lost fill.

  1. He opens Visitor Analytics for the site and sets the range to the last 14 days.
  2. Pageviews are flat — the traffic never went anywhere.
  3. So it's a fill problem, not an audience problem. He goes to Publisher Statistics and finds impressions down on one zone.
  4. On that zone's Prices tab he'd raised the floor the week before. He lowers it, and fill recovers.

Had pageviews dropped instead, the answer would have been on his own site — a broken template, a search ranking change, a redirect — and no amount of ad-side tuning would have fixed it.

Tips#

  • Compare this against your ad stats, not instead of them. Pageviews flat + impressions down means a fill problem; both down means a traffic problem. That one comparison answers most "why did my earnings drop" questions.
  • Watch pageviews per visitor. A number in the hundreds is automated traffic, not a hit.
  • Use screen resolution when picking zone sizes — there's no point placing a 970px unit for an audience that's mostly on phones.
  • Turn it on per site, not everywhere at once, if you want a clean before/after read on a change.
  • Expect lower numbers than a general analytics tool. Ad-blocked visitors are invisible here by design.

Troubleshooting#

Symptom Likely cause Fix
The site isn't in the Website selector The Visitor analytics toggle is off for it Open the site under Websites and switch it on
"No visits recorded for this range yet" Just enabled, or the controller isn't on those pages Give it a few hours; confirm the ad code is present with Getting Your Ad Code
Numbers are much lower than my other analytics Ad-blocked visitors aren't counted Expected — compare trends rather than absolute totals
Pageviews far exceed unique visitors One client requesting the same URL repeatedly Check Top pages — it's nearly always one or two URLs
A single-page app under-counts The controller tracks route changes automatically once enabled Confirm the controller loads at all; see Ad Controller (Advanced)
My custom event doesn't appear The Event() call isn't firing Check the browser console on that page; see Ad Controller (Advanced)