Browser events (POST /ct)
Browser events are sent automatically by the SDK or manually via scanova('track', ...). They represent actions that happen in the user’s browser.
Fields you can send
device object fields:
Example browser event payload
Server events (POST /server-events)
Server events are sent from your backend using an API key. They represent actions that happen on your server, such as completed purchases, confirmed sign-ups, or leads created in your CRM.
Fields you can send
user_identifiers object fields (all hashed):
Example server event payload
Event naming conventions
Use consistent, descriptive names insnake_case. A clear naming scheme makes reports easier to read.
Idempotency
Both browser and server events support anevent_id field for deduplication:
- If the same
event_idarrives more than once, the duplicate is stored but markedis_duplicate = 1 - Duplicates are excluded from analytics views automatically
- Always reuse the same
event_idwhen retrying a failed server event
Privacy and GDPR
- Never send raw email addresses in
metadataorproperties. Useuser_identifierswith hashed values. - The
consentfield controls PII handling in the pipeline:granted— all fields are stored normallydeniedorpending—page_url,referrer,city, andmetadataare stripped before storage- The
consentvalue itself is always stored as an audit trail
Sending consent from the browser
The Browser SDK does not have a built-in consent API. The recommended approach is to conditionally load the SDK based on your consent management platform’s decision:Sending consent from the server
For server events, pass theconsent value directly in every request payload alongside your other fields.