WordPress user activity tracking splits into two jobs that different plugins do. An audit log records content and setting changes for forensics; visitor analytics records which pages your logged-in members and authors actually read. SlimStat Analytics does the second, storing a username on every pageview a signed-in visitor makes, in your own database.
Audit logs and analytics answer different questions
Two plugin categories share the phrase “user activity”. Audit-log plugins such as WP Activity Log record what changed on your site: post edits, plugin activations, role changes, failed logins. Analytics plugins record what was read: which URLs a signed-in member opened, in what order, for how long.
If your requirement is forensic or compliance-driven — proving who deleted a page, or reconstructing an incident for an auditor — install a dedicated audit-log or security plugin, because SlimStat is the wrong tool for that job and will not become the right one with configuration. The free SlimStat plugin registers no hook on post saves, plugin activations, role changes or failed login attempts, so those events never reach the database at all.
| Event recorded | Sense of “activity” | Plugin class that records it |
|---|---|---|
| Post, page and media edits | Security audit | Audit-log plugin such as WP Activity Log |
| Plugin, theme and settings changes | Security audit | Audit-log plugin |
| Successful and failed logins | Security audit | Security plugin with login monitoring |
| Pages a signed-in user viewed | Visitor analytics | Analytics plugin such as SlimStat |
| Time on site per username | Visitor analytics | Analytics plugin such as SlimStat |
| Admin screens a user opened | Either, depending on the plugin | SlimStat with Track Backend on, or an audit log |
Nothing stops the two running side by side, and on a membership site or a multi-author blog both are usually warranted. The rest of this article covers the analytics half only: what SlimStat Analytics, listed on wordpress.org since 2010 and running on 70,000+ sites, records about the people who are signed in to yours.
What SlimStat stores against a logged-in visitor
Every pageview SlimStat writes carries a username and an email column, filled from the WordPress user object when someone signed in loads a page. A notes field also records user:<ID>, which is how the reports tell a registered WordPress user apart from a commenter identified only by the WordPress comment cookie.
The same row holds everything SlimStat records about any visit, now with a name attached to it:
- The URL requested, plus its post ID, content type, category and author.
- The referrer, so a member arriving from a newsletter is distinguishable from one arriving from a bookmark.
- Country, city and coordinates, when geolocation is set up — see geolocation setup.
- Browser, platform, screen resolution and user agent.
- A visit ID grouping consecutive pageviews, with entry and exit timestamps that make time on site calculable.
- Server latency and page performance in milliseconds, per hit.
Those rows live in a table inside your own WordPress database rather than on a vendor’s servers, which is what makes a username in an analytics table defensible at all. The database tables reference documents the columns, and SlimStat as a Google Analytics alternative covers why ownership matters for identifiable data.
Where logged-in activity shows up in the reports
Six free reports and two Pro reports carry a username. The Access Log lists individual hits, the Audience screen ranks users against each other, and Site Analysis maps users onto URLs. Nothing here requires configuration beyond having tracking on and logged-in users not excluded.
| Report | Question the report answers | Admin screen | Free or Pro |
|---|---|---|---|
| Access Log | Every pageview, with the username attached | Real-time | Free |
| Users Currently Online | Which users were active in the last five minutes | Overview | Free |
| Top Users | Registered users ranked by pageviews | Audience | Free |
| Recent Users | Registered users seen most recently | Audience | Free |
| Users by Page | Which usernames viewed each URL | Site Analysis | Free |
| Top Known Visitors | Usernames and commenters ranked by pageviews | Overview | Free |
| User Overview | One row per WordPress account, eight columns | Audience | Pro |
| Pages by User | Pages grouped under each username | Real-time | Pro |
The Access Log is the report most people picture when they say activity tracking, and it colour-codes every row by who the visitor is: a logged-in WordPress user, someone identified by a comment cookie, an arrival from a search engine, another human, or a bot. Real-time analytics in WordPress covers how quickly those rows appear.
What the User Overview report adds in Pro
User Overview is a Pro-only report that puts one row per WordPress account on the Audience screen, with eight columns: Username, Full Name, Email, Registered, Last Login, Pageviews, Login Count and Time on Site. Six of the eight sort — Full Name and Email are display-only. The free plugin has no equivalent table and records no login events.
Two of those columns exist only because Pro adds them at the source: Pro hooks the WordPress login and logout actions and marks the pageview row belonging to that session, so Last Login and Login Count cannot be populated retroactively on a site that ran free until yesterday. Accounts that never generated a pageview still appear, sorted to the bottom with a count of zero — useful for spotting members who signed up and never came back.
A second Pro report, Pages by User, inverts the same data on the Real-time screen: pages grouped under each username rather than users grouped by activity. Pro also lets the scheduled email report include the User Overview table, and exports it to Excel or CSV. Full tier detail is on the pricing page.
Excluding the people you do not want counted
Three exclusion settings on the Exclusions tab decide which logged-in users are recorded: a WP Users toggle that drops every signed-in visitor, a Capabilities field matching role slugs or capability keys, and a Usernames field matching account names. Each rule runs inside the tracker, before any row is written.
The trade-off belongs in one breath: turning the WP Users toggle on is the standard way to keep your own browsing out of the numbers, and it also empties every report in this article, because a pageview that was never written cannot carry a username. Sites that want member analytics exclude by capability instead — dropping anyone with manage_options keeps administrators out while leaving subscribers in. Exclude your own visits is the field-by-field reference.
Tracking activity inside wp-admin
Track Backend is a free toggle, off by default, that extends tracking to WordPress admin screens. With the toggle on, an editor opening the post editor produces a pageview row like any front-end visit, which tells you which screen was opened and never what was saved there.
One setting compresses the whole distinction. A backend pageview proves an editor loaded the plugins screen at a given minute; only an audit log proves whether a plugin was activated there. SlimStat’s own report screens are excluded from tracking unconditionally, so reading your statistics never inflates them.
Privacy, consent and retention when the visitor has a name
A username in an analytics table is personal data under GDPR, so SlimStat writes one only when consent allows personal identifiers to be stored. Four free settings soften what is kept — Anonymize IP Addresses, Hash IP Addresses, Set Tracking Cookie and Respect Do Not Track — and a retention period purges old rows automatically.
Retention Period, on the Maintenance tab, deletes rows older than a set number of days on a twice-daily cron run, and an Archive Mode toggle chooses between permanent deletion and a move to archive tables — which the settings screen warns still counts as retained data under GDPR. See data retention and auto-purge.
SlimStat also registers itself with the WordPress personal-data exporter and eraser, so a subject access or erasure request handled through Tools reaches the SlimStat rows: the exporter returns them, and the eraser deletes the matching pageviews and their events outright, in the live tables and in the archive. For the wider question, is your analytics tool GDPR compliant and tracking users without cookies go further.
What this data will not tell you
SlimStat registers no hooks on post saves, plugin activations, role changes or failed logins, so no report in the plugin can reconstruct what a contributor changed. The gaps below are the ones people most often expect a user-activity plugin to fill, listed with the honest answer for each.
- An audit trail of content changes. Not available at any tier. Use an audit-log plugin.
- Failed login attempts. Not recorded. Use a security plugin.
- Where a user clicked on the page. Heatmaps are a Pro add-on — see enabling the heatmap.
- More than one conversion goal, or any funnel. The free plugin allows one active goal; additional goals and funnels are Pro.
- Anything about logged-out visitors by name. A username is attached only while someone is signed in, so anonymous sessions stay anonymous, which is the correct outcome rather than a limitation.
Frequently asked questions
These are the questions that separate the two readings of user activity tracking, answered against what the SlimStat plugin actually does rather than what the category is assumed to do. Where the honest answer is a security plugin rather than an analytics one, the answer below says exactly that.
Does SlimStat log who edited a post?
No. SlimStat records pageviews, not content changes, and no tier adds an edit history. For a record of who changed what and when, install an audit-log plugin; the two plugin types coexist without conflict.
Can I see which pages a specific member viewed?
Yes, in the free plugin. Users by Page on the Site Analysis screen groups usernames under each URL, and the Access Log can be filtered to a single username. SlimStat Pro adds Pages by User, which inverts the same grouping.
Does the free version track logged-in users at all?
Yes. The username and email of a signed-in visitor are stored on the pageview row by the free plugin, and six free reports read that column. What Pro adds is the per-user summary table, plus login counts and last-login timestamps.
Will tracking logged-in users slow my site down?
Each tracked pageview is a single insert into a local table, which is why the retention period matters more than the write. Set a purge window so the table stays a working set rather than an archive, and index growth stays bounded.
How do I list every username who visited one page?
A shortcode or a direct API call will do it without opening a report, which is useful for members-only pages. The usernames who visited a page guide covers both methods.
Is tracking logged-in users GDPR compliant?
Storing a username is processing personal data, so it needs a lawful basis, a privacy policy entry and a retention limit — not merely a plugin setting. SlimStat supplies the technical half: consent-gated identifiers, IP anonymisation, automatic purging and subject-request handling.