A cookieless analytics audit should inspect what the tracker does, not only whether it sets a cookie. Use these seven checks to review storage, identifiers, collection choices, and operating controls before launch.
This is an implementation checklist. The cookieless tracking GDPR explainer addresses the broader legal question; the cookieless overview explains the measurement model.
1. Inspect all browser storage
In a fresh synthetic test session, check cookies, localStorage, sessionStorage, and other device access used by the application and tracker. Record the purpose and lifetime of each relevant value.
Databuddy avoids analytics cookies but uses browser storage. Review the collection reference rather than assuming its behavior from the word “cookieless”. Keep application session cookies distinct from analytics identifiers.
2. Examine requests and event properties
Inspect the actual payloads for a pageview, custom event, and any enabled diagnostic event. Check URLs and query strings for email addresses, tokens, search terms, or other unexpected values.
Use a property allowlist for custom events. Collect the minimum information needed for a stated question and verify that your application does not send entire form or request objects by mistake.
3. Review identifiers and account linking
Write down how the tracker distinguishes activity and what happens when you identify an account. Determine which values persist across visits and which are transformed or rotated.
An opaque or hashed identifier is not automatically anonymous. If your reporting needs account-linked behavior, document why and test login, logout, and a second user on the same browser. See the tracker helpers for Databuddy's identity APIs.
4. Test the collection decision
Where your configuration requires consent, verify acceptance, refusal, and withdrawal. Where an exemption or opt-out is being used, document its basis and test the relevant controls. Do not change a visitor's refusal merely to improve a report.
CNIL's guidance describes conditional audience-measurement exemptions. Review the requirements relevant to your deployment rather than assuming that removing cookies resolves them.
5. Check optional features independently
Review replay, diagnostics, identification, advertising integrations, and connected AI services separately. Enabling a feature can change payloads, destinations, and the purpose of collection.
Record who may enable these features and what verification is required first. The SDK configuration reference gives the available controls; a configuration option is not evidence that it is set correctly on your live site.
6. Verify access and data lifecycle controls
Test report permissions and scoped keys with synthetic team members. Document retention, supported exports, deletion, and backup handling. Review actual processing regions, subprocessors, and contractual arrangements.
Use the ownership checklist when you need a repeatable acceptance test for portability and access. Keep exported analytics and credentials out of public repositories.
7. Keep evidence and repeat the relevant checks
Save the tested version, configuration, expected events, observed requests, and review owner. Revisit the audit when you change storage, profile identity, custom properties, optional features, destinations, or hosting.
An audit record should explain what was verified and what still needs review. It does not need to claim that a tool or an entire website is compliant “by default”. For a broader vendor evaluation, use the analytics privacy review worksheet.