Cookie-free is not a legal force field

OwlEye’s public SDK writes no cookies, localStorage, or sessionStorage. That is a useful technical property. It is not a universal answer to “do we need consent?”

The distinction matters because a neat marketing sentence can quietly become someone’s compliance decision. We want the sentence to survive a look at the actual data path.

What the defaults do

Arbitrary query parameters and fragments are excluded unless an integrator enables them; SDK 1.0.3 automatically captures bounded campaign tags. Requests omit browser credentials. Event requests suppress the HTTP referrer header, while the optional rules fetch can send the origin. The payload can still contain a sanitized page URL and referrer, browser context, a timestamp, and deliberate custom fields.

The server sees a network address while handling the request. It reduces the IP prefix before deriving keyed, site-scoped identifiers, and does not write raw IPs to analytics facts. A separate daily identifier and session bucket support aggregate reporting. These identifiers are pseudonymous; they are not proof that data is legally anonymous.

Infrastructure logs and backups are separate systems with separate configuration and retention decisions. A promise about an analytics table cannot certify every proxy log or backup copy.

Why the cookie question is only one question

The EDPB’s final guidance on Article 5(3) addresses technologies beyond cookies, including tracking techniques that access information on a device. The exact operation and context matter. Removing cookie storage alone does not settle that assessment. EDPB technical-scope guidance.

Separately, personal-data processing needs a documented purpose and applicable lawful basis. Who controls the data, what an event means, which recipients receive it, how long it is kept, and how rights requests are handled still need answers. Those answers vary by deployment and jurisdiction, so this post does not prescribe one consent configuration for every site.

Keep the event taxonomy boring

report_exported with { format: "csv" } tells a useful product story. A support message, an email address, or a full URL containing a reset token tells a very different story. A ten-property limit cannot make those values appropriate.

Review new event names and rule properties like any other data collection change. Inspect real requests, document the allowed properties, and treat free text as a reason to stop and reconsider. Respect browser privacy signals rather than treating them as lost conversions.

OwlEye supports delaying page analytics with autoStart: false, then calling start() once your decision allows it. Initialize optional rules only after that decision too. On withdrawal, stop both controllers. See the quickstart and privacy documentation for the concrete boundaries.

Smaller collection is a good start. Clear explanations and deliberate operation are the rest of the job. The force field is still fictional.

When your collection decision allows it, use dashboard-managed events and a funnel to investigate where visitors leave before signup. Name the attempted interaction and confirmed outcome separately so the report answers the right question.