The four calls
evx.consent({ analytics: true, ads: false }); // from the cookie banner, on every page load
evx.page(); // a page view
evx.page("Tickets", { section: "weekend" }); // a named page, with properties
evx.track("Video Played", { video: "aftermovie" }); // kept raw until a rule maps it
evx.track("subscribed_newsletter", { email, list }); // a name the server knows needs no rule
evx.identify(userId, { email }); // after a login: a claim, not proof
evx.identify({ email }); // from a form
evx.track("added_to_basket", { order_id, event_id, ticket_type_id, quantity: 1 }); // the shop
evx.track("entered_details", { order_id, email }); // the checkout form; sent before consent
evx.track("placed_basket", { order_id }); // just before the payment redirect
| Call | On the wire | Becomes on the server |
|---|---|---|
page(name?, properties?) | a page message with context.page (url, path, title, referrer) | viewed_page; the first call of a session also started_session |
track(event, properties?) | a track message | the owner's rule for the name; else the catalogue activity of that name if a browser key may send it (subscribed_newsletter, the basket activities started_basket, added_to_basket, removed_from_basket, entered_details and placed_basket, submitted_form, a custom.…); else nothing, and the call is kept raw |
identify(userId?, traits?) | an identify message | identified: the email and phone from the traits become identifiers, claimed |
consent(state) | nothing by itself; the state rides on every later call under context.evx.consent | decides what may be sent at all; see consent |
Every message carries a messageId (UUID v7, made at call time), the anonymousId, a timestamp and context.page. Message ids are made when the call is made, so the activities of a retried message are deduplicated by the server.
Properties
Properties go as sent. For a catalogue activity they are its features and are checked against its schema (subscribed_newsletter needs its email); for an unmapped track they are kept with the raw call and can be mapped by a rule later. Values that look like an email address or a phone number in undeclared properties are dropped on the server, because an identifier in a free field would escape normalisation and erasure: put them in the fields the activity declares.
What a browser may not do
A browser key cannot send revenue, cannot create verified identity evidence (an identify gives a claim), and cannot place a person with a geo block. See write keys.