WordPress analytics

How analytics gets onto a WordPress site

Three routes put a tracking tag on a WordPress site: a plugin published by the analytics vendor, a snippet added to the theme’s head, or a tag manager container placed by one of the first two. The plugin route survives ordinary maintenance, because the code is not sitting in a file that the next theme update replaces.

A vendor plugin installs from the plugins screen, asks for the site name or a key, and adds the tag to every page. The settings are the reason to prefer it over a pasted line. Plausible’s plugin connects with a plugin token, and its settings screen turns on tracking for missing pages, file downloads, outbound links, form completions and internal searches, each appearing as a goal once the first event arrives; it can also show the dashboard inside the WordPress admin for roles you choose.

The theme route puts the tag in the head of the page template. In a classic theme that file is header.php. WordPress documentation notes that templates are .html files in block themes and .php in classic ones, so on a block theme there is no header.php to paste into, and the tag has to come from a plugin or the site editor instead. The hook underneath all of this is wp_head, which the documentation describes as triggered inside the head section by the wp_head function and calls one of the most essential theme hooks, widely supported though theme-dependent.

The tag manager route is the same problem one level up: a container has to be placed by one of the first two routes, and it records nothing by itself. It delivers the analytics tag you configure inside it, so the thing to verify afterwards is that the tag fires rather than that the container loaded.

Which vendors publish a plugin of their own is a question the directory answers: 20 of the 44 tools in the table do, and 5 more can be added with a plugin somebody else wrote. The page of tools with a WordPress plugin lists them with the date each value was checked, and the table of tools holds the other columns. The steps that follow installation, from confirming the first visits to reading the first week, are in the guide on how to track website traffic.

Which service ends up with your data

A search for a WordPress analytics plugin returns two different products. A connector places a Google Analytics tag on your pages and links the site to a property: the data goes to Google, the reports live there, and your questions about cookies, storage location, retention and price become questions about Google Analytics 4. A vendor plugin sends data to that vendor’s service instead, and many of them draw the main figures inside the admin.

The choice is therefore about the service rather than about the plugin, and it is worth making before you compare settings screens. The WordPress page sets out the distinction and what counts as a vendor plugin here; the methodology explains how each column is checked.

What a theme change and a page cache do to it

A snippet in header.php belongs to that theme. Install a new theme and the site starts without it; update a parent theme and the file you edited is replaced, which is the reason the child theme documentation warns that code added to a theme’s own files disappears at the next update. A plugin adds the tag through the hook instead, so it keeps working across a theme switch.

Caching is the second recurring cause. A page cache serves stored HTML, so a tag added today appears only once the cache is rebuilt, which is why Plausible’s documentation tells you to clear the cache of a caching plugin after enabling its proxy and names caching first among the reasons a plugin stops reporting, alongside an excluded administrator, an invalid token and a proxy that was reset. How a tool counts decides how much caching matters: Koko Analytics states that its collection endpoint bypasses WordPress entirely and that it works with pages served from many types of cache.

Three more failures repeat on WordPress sites. Performance plugins are the first: Plausible’s troubleshooting page states that caching and performance plugins can minify, combine or delay its script in ways that break tracking, and tells you to add the script address to the exclusion list in that plugin’s settings. Moving the site is the second. The Plausible proxy runs through the WordPress API with a randomly generated endpoint and writes a randomly named file into the uploads folder, and after a migration or a clone that path may no longer match what the plugin expects, so the documented repair is to disable the proxy, clear every cache, enable it again and clear the caches once more. A consent plugin that loads the script only after acceptance is the third, and it removes everyone who declines from the data.

One more thing to check after a migration: a staging or development copy carries the same tag as the original, so its visits land in the same reports unless you change the setting there.

Keeping your own visits out of the numbers

Your own activity is the first thing that distorts a small site’s numbers, and every route deals with it differently.

Plausible’s plugin excludes logged-in administrator visits by default and offers Track analytics for user roles, where editors, authors and contributors can be excluded as well, or a role switched back on when you do want to count it. It also takes a comma-separated list of paths to leave out, each starting with a slash and accepting an asterisk as a wildcard.

Koko Analytics excludes visits by WordPress user role or by IP address, which covers the case of an editor who is rarely logged in.

Google Analytics 4 works from addresses rather than roles. You define internal traffic in the data stream, which adds a traffic_type parameter to incoming events, then create a data filter; a property allows up to 10 data filters, and the documentation carries a warning worth reading twice, since once an exclude filter is active the excluded data is never processed and will never be available in Analytics or BigQuery. Report filters hide data without deleting it, and internal traffic from app users cannot be filtered this way at all.

The practical difference is stability. A role-based exclusion follows the person, while an address-based one stops matching the moment your connection hands out a new address, which home connections do regularly. Whichever you use, check the result from a logged-out browser on another network, because a test made as an excluded user proves nothing.

Where the numbers live, and what that asks of your server

A hosted service adds a file to your pages and nothing else: the records leave your site, and your hosting does no extra work.

Analytics that runs inside WordPress changes that. Matomo publishes a plugin that runs Matomo itself on your server, and its plugin page states plainly that this can use significant resources, since each visit produces a request for the page and another for tracking. It names a minimum PHP memory limit of 128 MB with 256 MB recommended and PHP 7.2 as the floor, and from Matomo 6 onwards PHP 8.1 with MySQL 8.0 or MariaDB 10.6; the plugin checks those versions before updating and stops the update with a message rather than breaking the site. Koko Analytics takes the light version of the same idea, keeping statistics inside the site and needing no account anywhere.

Neither arrangement is free of cost. One puts your data with a vendor and leaves your server alone; the other keeps the data on your hosting and adds analytics to the list of things your hosting has to survive.

Questions and answers

Which analytics plugin should I install on WordPress?

The question to settle first is which service, since the plugin is only the installer. 20 of the 44 tools in the table publish a WordPress plugin of their own, and 5 more have one written by somebody else, which can lag behind the vendor’s script. After that the usual columns decide: where data is stored, what is written to the visitor’s browser, what a plan costs at your traffic. The WordPress page holds the list.

Where exactly does the tracking code go?

In the head of every page. A plugin puts it there through the wp_head hook without you opening a file. By hand, that means header.php in a classic theme, and in a block theme there is no such file, since WordPress documentation states that block theme templates are .html files, so the tag comes from a plugin or from the site editor. Editing the parent theme directly is the version that gets overwritten at the next theme update.

Why did my statistics stop after I changed the theme?

Because the tag was in the old theme. A snippet pasted into header.php lives in that theme’s files, and both a theme switch and a parent theme update remove it, which is what child themes exist to prevent. Check the page source of a logged-out visit for the tag, and if it is missing, add it again through a plugin so the next theme change does not repeat the afternoon.

Does a caching plugin break analytics?

Not by itself, though it delays changes and hides mistakes. Pages are served from the cache until it is rebuilt, so a new or corrected tag appears late, and vendors tell you to clear the cache after changing settings. A tool that counts while the page is being built sees nothing when the cache answers instead, which is why Koko Analytics points out that its collection endpoint bypasses WordPress and works with cached pages.

How do I keep my own visits out of the reports?

Use whatever the tool offers on the role rather than the address where you can. Plausible’s plugin leaves out logged-in administrators by default and can exclude other roles, Koko Analytics excludes by role or by address, and Google Analytics 4 filters by address with the warning that excluded data is never processed. Then confirm it: open the site logged out from another network and look for that visit in the report.