Consent & Privacy
How Hardal handles anonymous collection, consent signals, identity fields, and first-party cookies.
How Hardal uses consent
Hardal accepts anonymous events without a known user identity. When a request has neither granted consent nor a valid identity cache for the same tenant and source, the collection service removes userId and visitorId before processing the event.
When consent is granted, Hardal can keep the supplied identity fields and set a secure first-party cookie for visitor recognition. A later request may reuse that cache for the same tenant and source even when it omits an explicit consent signal. Your implementation is still responsible for deciding when consent is required and which fields it may send.
What changes with consent
| Behavior | Without granted consent | With granted consent |
|---|---|---|
| Event collection | Yes | Yes |
| Session grouping | Yes, when the sender reuses a session ID. The web tracker does this automatically. | Yes |
userId and visitorId processing | Removed | Kept when supplied |
| First-party visitor cookie | Not written, or cleared by an explicit denial | Written by the collection service |
| Recognized visitor and consent-rate metrics | Not increased | Can increase when a visitor ID is present |
Consent signals
The tracker accepts two explicit consent values:
| Signal | What it means |
|---|---|
granted | Identity fields may be processed and the first-party visitor cookie may be set. |
denied | Events remain anonymous, identity fields are removed, and an existing identity cookie is cleared. |
Without a signal, Hardal reuses a valid identity cache for the same tenant and source. If no matching cache exists, identity processing is denied.
Implementation responsibility
Use virgo.consent("granted") or virgo.consent("denied") when the visitor makes or changes a choice. Do not send personal or identifying fields until your own consent policy and applicable requirements allow it.
Consent Signals
Add the current consent signal to your web implementation.