Fields

Event fields are the attributes defined in the event type that form the data contract accepted by POST /events.

In practical terms, these fields determine what will be validated on submission, what will be ignored, and what can be used to generate metrics and monitors.

What can be configured in a field

When registering a field in the admin panel, you define:

  • field ID: identifier used in the API payload;
  • name and description: labels displayed in the panel;
  • data type: expected format for the value;
  • property type: how the field will be treated in modeling;
  • required: whether the field must be present in every event;
  • status: whether the field is active or inactive.

Available data types

The platform supports the following field types:

  • text;
  • list (predefined values);
  • integer;
  • decimal;
  • float;
  • boolean.

Important notes

  • Text fields accept up to 128 characters.
  • List type fields allow registering permitted items for validation.
  • For decimal fields, precision and scale are defined at creation.

Property type: dimension or measurement

Each field also receives a property type:

  • dimension: represents a characteristic of the event used for segmentation;
  • measurement: represents a variable value used in consolidations.

This choice impacts how metrics and monitors can be configured later.

Validation rules on event submission

When receiving events via POST /events, the field contract is applied with the following rules:

  • missing required fields cause rejection;
  • values outside the expected type cause rejection;
  • inactive fields can remain in the payload, but their values are ignored;
  • unknown fields can be ignored or rejected, depending on the event type configuration.

Best practices for modeling fields

  • Define stable and semantic IDs from the start.
  • Start with a lean set of essential fields.
  • Use list fields when there is a controlled set of values.
  • Avoid creating redundant fields for the same concept.
  • Periodically review unused fields.

Restrictions and lifecycle

Some configurations are structural and must be planned at creation time:

  • the field ID cannot be changed after registration;
  • the property type cannot be changed after registration;
  • for decimal fields, precision and scale are fixed after creation;
  • list field items are managed after the field is created;
  • the event type has a limit of up to 100 fields.

When removing a field, the operation may fail if it is in use by metrics (for example, in dimensions or aggregations).