Cookieless tracking identifies visits without storing anything in the browser. SlimStat does it with three settings: Set Tracking Cookie off, plus Anonymize IP Addresses or Hash IP Addresses on. That combination stops the slimstat_tracking_code cookie, masks or hashes the address, and still records country, referrer and page.
This article describes what the software does. It is not legal advice, and no configuration described below is presented as compliant in any jurisdiction.
Which identification techniques set a cookie
Cookies are one identifier among several, and only one of them writes to the visitor’s browser. A SlimStat install can recognise a visit from a first-party cookie, from the IP address, from a browser fingerprint hash, or from a WordPress login. Each technique has a different switch, and the table below names the switch for each, including the two IP variants.
| Identification technique | Sets a browser cookie? | What SlimStat calls it |
|---|---|---|
| First-party session cookie | Yes | Set Tracking Cookie, named slimstat_tracking_code |
| Full IP address in the database | No | The default, with both IP toggles off |
| Masked IP address | No | Anonymize IP Addresses |
| Daily hash of IP plus user agent | No | Hash IP Addresses |
| Browser fingerprint hash | No | Sent by the JavaScript tracker as fh |
| WordPress account name | No, WordPress sets its own cookie | Stored in the username column |
Only the first row writes to the browser. The rest are recorded on your server, which is a different legal question from the cookie question, not an exemption from it.
The settings that make a SlimStat install cookieless
Three toggles under Settings produce a cookieless SlimStat configuration: Set Tracking Cookie off, and Anonymize IP Addresses or Hash IP Addresses on. SlimStat’s own consent logic treats a configuration as collecting personal data only when a tracking cookie is set or a full IP address is stored, so switching all three flips that internal classification.
| SlimStat setting | Settings tab and section | What the setting changes |
|---|---|---|
| Set Tracking Cookie | Tracker, Data Protection | Off means no slimstat_tracking_code cookie is written |
| Anonymize IP Addresses | Tracker, Data Protection | Zeroes the last IPv4 octet, drops the last 64 IPv6 bits |
| Hash IP Addresses | Tracker, Data Protection | Replaces the address with an HMAC-SHA256 hash |
| Respect Do Not Track (DNT) | Tracker, Data Protection | Blocks all tracking when the browser sends DNT: 1 |
| Retention Period | Maintenance, Data Retention | Purges rows older than the day count you enter |
Order matters when both IP settings are on. Hashing runs first and uses the original address, so the ip column holds a hexadecimal hash and masking only acts as a fallback if hashing fails. The hash itself is built from a daily salt plus the address plus the user agent, and that salt is minted fresh for each UTC day, so the same visitor produces a different hash tomorrow.
What SlimStat still records without a cookie
Dropping the cookie removes an identifier, not the pageview. SlimStat still writes the requested resource, the referrer, the browser and platform, the language header, the screen and viewport size, outbound link clicks and file downloads. Country resolution also survives, because the geolocation lookup runs on the address held in memory before any masking or hashing is applied.
At the default country precision only the country code reaches the database from that lookup. Set Geolocation Precision to city and the provider also returns the city, the subdivision that is appended to it, and latitude and longitude, which SlimStat writes to the location column. The address the lookup consumed is never written in its original form once Anonymize IP Addresses or Hash IP Addresses is on. Setup for the provider you pick is covered in Geolocation setup.
What you give up is cross-day visitor identity. A cookie survives until it expires; a daily-rotating hash does not, so a person visiting on Monday and again on Wednesday counts as two visitors rather than one returning visitor.
Where the browser fingerprint fits
SlimStat’s JavaScript tracker computes a fingerprint hash from the browser’s own characteristics and sends it to the server as the fh parameter. That hash is not a cookie, nothing is written to the visitor’s device, and the Set Tracking Cookie toggle does not govern it. Two separate conditions decide whether the value is ever stored.
On a pageview, SlimStat writes the fingerprint into the fingerprint column only when Anonymize IP Addresses is off and either the configuration is allowed to hold personal data or Anonymous Tracking Mode is on, which uses the fingerprint to group a session without a cookie. Turning Anonymize IP Addresses on therefore stops the fingerprint from landing on a pageview record, in the same toggle that masks the address.
To remove the value everywhere rather than on pageviews alone, unset it in the slimstat_filter_pageview_data_js filter, which runs on the raw tracker payload before SlimStat parses any of it. Fingerprinting is treated as an identifier by several regulators, so this is worth an explicit decision rather than a default.
Do Not Track, consent banners and what they actually gate
Two independent mechanisms sit in front of the tracker. Respect Do Not Track (DNT) blocks the pageview outright when the browser sends DNT: 1, ahead of every other check. GDPR Compliance Mode, with Consent Plugin Integration, holds tracking until a consent platform reports a decision, and offers either SlimStat’s own banner or the WordPress Consent API.
The WP Consent API route works with any consent plugin that implements it, Complianz and CookieYes among them, and the wiring is documented in integrating with GDPR banner plugins.
One behaviour deserves stating plainly, because it surprises people: SlimStat consults the consent platform only when the configuration would set a cookie or store a full IP address, so a fully cookieless install with hashed IPs keeps recording pageviews after a visitor declines. Whether that is acceptable for your site is a question for your own legal review, not for this page.
How long the data stays
Retention is a setting, not a policy you write down somewhere and forget. Retention Period, on the Maintenance tab, takes a number of days and purges older rows through WordPress cron twice a day; entering 0 disables purging entirely. Archive Mode decides whether those rows move to archive tables or are deleted outright.
Archived rows still exist, which means archiving is a database housekeeping choice rather than a deletion. The details, including the archive table names, are in data retention and auto-purge. The wider set of decisions around a first-party stack is covered in the privacy-first analytics stack for small businesses, and the case against sending the same data to a third party is in what makes an analytics tool GDPR compliant.
Frequently asked questions
Four questions recur whenever a cookieless configuration is proposed. The first belongs to your own legal review, and the answer says so rather than hedging; the other three are settled by SlimStat’s settings and source.
Does a cookieless setup remove the need for a consent banner?
SlimStat cannot answer that for your site, and neither can this page. Removing the cookie removes the browser storage that cookie rules attach to, but IP addresses and fingerprint hashes are still capable of singling out a person, which is the test that matters under GDPR. Treat the configuration as an input to your legal review rather than its conclusion.
Do returning-visitor counts survive without a cookie?
Not across days. Hash IP Addresses derives the identifier from a salt that is minted fresh each UTC day, so the same person produces a different hash tomorrow and is counted as a new visitor. Within a single day and session window, repeat pageviews from the same visitor still group together.
Does Server tracking mode make an install cookieless?
No. Tracking Mode, on the General tab, chooses whether the pageview is recorded by PHP on your server or by the JavaScript tracker in the browser, and the cookie is governed separately by Set Tracking Cookie. Server mode is described in server-side tracking setup, and it remains useful for other reasons, including sites where ad blockers suppress client-side requests.
Where does this leave Google Analytics?
Google Analytics places its own identifiers in the visitor’s browser and sends the resulting data to Google’s infrastructure, which is the transfer that most privacy reviews focus on. A WordPress analytics plugin that replaces Google Analytics keeps collection and storage on your own host; the trade-offs are laid out in self-hosted vs cloud analytics.