Activities and the catalogue
An activity is a named thing that happened to a person at a time, with typed fields: its features. The catalogue is the list of names the service accepts, each with its schema, mode, allowed key classes, revenue rules and identity evidence rules. The activity pages are generated from it.
Two tiers
- Core activities (
completed_order,viewed_page, …) are defined by Eventix and shared by every organiser. They are the activities the CRM's own features are built on. - Custom activities (
custom.joined_waitlist) belong to one organiser, who registers them with a name and, if wanted, a schema. They are open by default, strict on request. Registration is through the dashboard (to come) or support.
Open and strict
The name of an activity is always guarded; whether its features are depends on its mode:
| Open | Strict | |
|---|---|---|
| For | Web tracking: viewed_page, submitted_form, custom activities by default | Everything that carries money or identity evidence, and anything an organiser locks down |
features | Any keys. Declared keys are checked when present; the rest pass through. | Exactly the declared keys. An undeclared key, a wrong type or a missing required key quarantines the event. |
| Same keys per row | No | Yes |
Open still has limits: money-like key names are refused everywhere (see revenue), values in undeclared keys that look like an email address or a phone number are dropped and counted, and an open activity's features are capped in size.
Field classes
Every declared field is one of:
| Class | What the processor does |
|---|---|
| plain | Stays in features. |
| identifier | Becomes an identifier of the activity (an email, a phone, …) and leaves features. See identifiers. |
| attribute | Becomes an attribute observation (first_name, city, …) on one of the identifiers and leaves features. See attributes. |
| sensitive | Dropped at the processor. |
The activity pages show the class of every field under "what happens to it".
Versions and states
Every schema change is a new version; a published version never changes, and each stored row records the version it was checked against (_schema_version). Changes are additive: a new optional field is a new version of the same name; removing, renaming or retyping a field means a new activity name, so old rows never change meaning. The activity pages list the versions with what each added.
An activity is draft (events go to quarantine, so a schema can be tested on real traffic), active, deprecated (still accepted) or retired (new events are quarantined; the stored rows stay; the name is never reused).
What a name means to a browser
The browser SDK knows no names. A track("Newsletter Signup") call becomes an activity only through the owner's rules or because the name is a catalogue activity the key class may send; otherwise the call is kept raw, without becoming anything. See tracking calls.