Asemic’s model is a semantic layer: a single place where your analytics vocabulary is defined once and reused everywhere. It has three levels, each built from the one below.

Events → properties → metrics

Events are your raw materials, the rows in your warehouse: login, purchase, registration, battle_started. During event setup you tell Asemic where they live and what shape they have; roles and tags mark what each event means (see Event roles and tags).

Properties are reusable facts about a user, derived from events: days since registration, total spend, battles played yesterday. A property is defined once and becomes available to every metric, cohort, and filter, instead of being re-derived (slightly differently) in every query that needs it.

Metrics are the numbers you chart: DAU, D7 retention, ARPDAU, LTV. A metric is a formula over properties and events, legible enough to read in one glance, so agreeing on a definition is a review, not an archaeology project.

The payoff is consistency: when every dashboard speaks the same definitions, “whose DAU is right?” stops being a meeting. This is also what makes the model a reliable grounding for AI-assisted analysis: a question answered through the semantic layer uses the definitions your team agreed on, not an improvised query.

Draft and published model

Your draft is the working copy: event setup, metric packs, and manual edits all land there. Publishing creates an immutable version that charts actually use; the draft stays yours to keep iterating. The full mechanics are on the Publish page.

Where it lives

The model is derived and computed in your warehouse, in the dataset you chose as “Data model schema” during event setup. Asemic pushes queries down to it; your raw events never leave. Charts read a precomputed daily entity table, which is why backfilling exists; see Materialization for how that table works.