Cookie consent for statistics counted on your own site

Matomo for WordPress can store these in a visitor's browser: matomo_has_js (cookie, statistics: Tells Matomo that the visitor's browser runs JavaScript, for visit statistics). Cookie Rocks recognises them from 2.9.8, with this category and purpose, and lists them in the cookie policy when it sees them.

Burst Statistics can store these in a visitor's browser: _tmjs_l (sessionStorage, statistics: Burst Statistics: counts the visit without cookies, within the session); burst_error_reported (sessionStorage, statistics: Burst Statistics: counts the visit without cookies, within the session). Cookie Rocks recognises them from 2.9.8, with this category and purpose, and lists them in the cookie policy when it sees them.

On a fresh WordPress home page with default settings (no account, key or content set up), TranslatePress, Weglot, Smash Balloon Instagram Feed, WP Go Maps, MailPoet and Matomo for WordPress set no cookie, keep nothing in the browser's storage and load no known third-party tool, after Accept all.

Matomo's tracker writes the cookie mtm_consent_removed (30 years) on the site's domain whenever forgetConsentGiven is called, even before any choice, with cookies disabled and with no hit sent. Cookie Rocks Pro pushes requireConsent at start, setConsentGiven on acceptance, and forgetConsentGiven only when a consent given on the page is withdrawn: no cookie is written before the choice. Before 2.5.0 it pushed forgetConsentGiven before any choice.

Matomo for WordPress adds no tracking code after activation (track_mode disabled by default). Once a mode is chosen, the tracker and hits are served by the site itself (app/matomo.js, app/matomo.php or /wp-json/matomo/v1/hit/), inline in the footer. Its Cookie consent setting defaults to None; the options push requireCookieConsent or requireConsent, and a consent plugin must then give consent through the _paq API. There is no WP Consent API code.

With Track ecommerce on (default), Matomo for WordPress sends WooCommerce carts and orders from PHP during AJAX or REST requests, in Tag Manager mode, or with MATOMO_TRACK_ECOMMERCE_SERVER_SIDE, with no consent check in that code; the PHP tracker sets no cookie but reads _pk_id. A browser-side consent signal does not hold these hits. Use server generated Visitor ID (off by default) starts the WooCommerce session for visitors without _pk_id.

Koko Analytics defaults to the cookie tracking method. Its inline footer script sends the page view at once by sendBeacon (or fetch) to the site itself, and the server response sets _koko_analytics_pages_viewed (HttpOnly, path /, expires at the next midnight in the site's time zone). The JavaScript writes no cookie or storage, and no third-party host is contacted.

Koko Analytics' cookieless method keeps a server-side session file named by a hash of a daily seed, the user agent and the IP address, deleted after midnight. Since 2.x the tracking script is printed inline in wp_footer, so address patterns on assets/dist/js/script.js no longer match anything. It has no WP Consent API code.

Independent Analytics sets no cookie and uses no browser storage for visitors. Its tracking code is an inline script (id independent-analytics-script) printed in the footer, which sends each page view with fetch to the site's own /wp-json/iawp/search endpoint at DOMContentLoaded; no third-party host is contacted from visitor pages. Being inline, it cannot be matched by a script address, only by its content (iawp/search).

Independent Analytics has no WP Consent API code. Its only consent integration targets a single consent plugin and is off by default; when on, it turns the inline tracker into type=text/plain with a statistics category. The page view can be fired again later through the iawpSearch JavaScript event.

Independent Analytics recognises returning visitors with md5(salt + full IP address + user agent). The salt refresh interval defaults to never (options: daily, weekly, monthly), so the same visitor stays recognisable from one month to the next unless the site picks a daily refresh.

Burst Statistics' cookieless fingerprint mode bundles ThumbmarkJS 1.2.0, which about once in 10,000 fingerprint computations, at most once per session (sessionStorage _tmjs_l), sends a POST to api.thumbmarkjs.com/log with the fingerprint, its components and the page path. Burst does not turn this logging off. The daily-hash mode does not include it.

Burst Statistics recognises visitors with a cookie by default: burst_uid, 32 random hex characters, 30 days (filter burst_cookie_retention_days), SameSite=Strict, set by JavaScript once tracking is allowed. Its daily-hash mode uses sha256 of IP, user agent and a salt renewed each day, with no cookie. Its script is a combined file at /wp-content/uploads/burst/js/burst.min.js by default; ghost mode gives it a random 8-character name.

When WP Consent API is present, Burst Statistics waits for wp_has_consent('statistics') before any tracking, page views included, in every mode, cookieless ones too. It reads only 'statistics', not 'statistics-anonymous', listens to wp_consent_type_defined and wp_listen_for_consent_change, and registers with the API. Without WP Consent API it tracks at once.

SlimStat Analytics follows WP Consent API only after GDPR Compliance Mode is on and Via WP Consent API is chosen (statistics category), reading it in PHP and in the browser. Its own banner (off by default) stores slimstat_gdpr_consent for 1 year. Its script can be served from cdn.jsdelivr.net (option off by default) or from an obfuscated /<md5>.js/ address that hides its name; in server-side mode the visit is recorded while the page is built.

With default settings, SlimStat Analytics checks no consent (GDPR Compliance Mode off), stores full IP addresses (anonymize and hash off) and sets slimstat_tracking_code from the first page: a PHP cookie in the tracking response, HttpOnly, SameSite=Lax, 30 minutes. While personal data is allowed (the default), it records the logged-in user's name and e-mail, or the name and e-mail read from WordPress comment cookies, with the visit.

SlimStat Analytics bundles FingerprintJS 4.6.2 and, unless anonymous mode is on, sends a browser fingerprint (parameter fh) with each visit. FingerprintJS is loaded without monitoring:false, so on about one page load in a thousand it sends a GET to m1.openfpcdn.io. Its script keeps slimstat_transport_memory, slimstat_stale_id_guard and two consent-upgrade keys in sessionStorage, and a queue of unsent hits (slimstat_offline_queue, up to 200) in localStorage.