Skip to main content
Every event you send to Scanova Conversion Tracking — whether from the browser or your server — follows a common structure. This page documents every field you can include and explains what the tracking pipeline does with it.

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 in snake_case. A clear naming scheme makes reports easier to read.

Idempotency

Both browser and server events support an event_id field for deduplication:
  • If the same event_id arrives more than once, the duplicate is stored but marked is_duplicate = 1
  • Duplicates are excluded from analytics views automatically
  • Always reuse the same event_id when retrying a failed server event

Privacy and GDPR

  • Never send raw email addresses in metadata or properties. Use user_identifiers with hashed values.
  • The consent field controls PII handling in the pipeline:
    • granted — all fields are stored normally
    • denied or pendingpage_url, referrer, city, and metadata are stripped before storage
    • The consent value itself is always stored as an audit trail
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:
For server events, pass the consent value directly in every request payload alongside your other fields.