Events are the raw material of the whole model: properties and metrics are built from them. This step points Asemic at your raw event tables and tells it, once, how they’re shaped. Asemic detects as much as it can; you review and correct.

With a warehouse connected and no events defined, the Data Model page shows one card: “Set up your events”. It opens the “Set up events” wizard. You can rerun it any time later from the page’s ⋮ menu → “Generate from tables…”.

Step 1 of 2 — Source

“Events dataset / schema”: the dataset holding your raw event tables, for example game_raw. Pick from the dropdown of visible datasets or type a name directly.
“Load tables”: optional; Continue loads them automatically.
“How are the events stored?”: the first real decision. Two layouts exist in the wild:
- “One table per event”: each event type has its own table: login, purchase, registration, battle_started. Common when a data pipeline writes one stream per event.
- “One big events table”: every event lands in a single table, and a column such as event_name says which one each row is. Common with SDK exports and event buses.
Pick whichever matches your dataset; the next screen adapts to the choice.
“Data model schema”: the dataset where Asemic writes the model it derives. It must be writable by the connection; “Test destination” checks that it exists and is readable.
“Active days”: how long a user stays in the daily entity table after their last activity. Leave the default of 90 unless you have a reason; the tradeoff is explained in Materialization.

Step 2 of 2 — Events

If you chose “One table per event”

You get a prepopulated table: one row per discovered event table, with columns Source table, Event id, Role, User id, Timestamp, Date, every value auto-detected and overridable via dropdowns.

Date is optional. Leave it empty and Asemic derives the day as DATE(timestamp). If your table has a physical date column, prefer it: on partitioned tables it makes daily queries meaningfully cheaper.

If you chose “One big events table”

Pick the “Events table” and the “Event type column”, then select “Scan events”. Asemic inspects the last 7 days of data and:

lists the event types it found, and
per event type, leaves out columns that are always empty for that type.

If scanning isn’t available in your setup, enter the event types manually; everything else works the same.

Roles

The Role column is the most consequential choice on this screen. A role is shorthand for the event’s tags, which decide which starter metrics the event generates. Tags stay editable per event afterwards; see Event roles and tags.

Role	Meaning	What it unlocks
User	A user action	Counts toward activity (DAU/MAU); the default
Registration	The user’s first appearance	Cohorts, retention, LTV
Payment	Carries the transaction amount	Revenue metrics
System	System-triggered (push sent, server job)	Nothing; deliberately excluded from activity so it can’t inflate DAU

Two assignments matter most: your registration event should carry Registration (it anchors cohorts and retention), and your purchase event should carry Payment (it anchors revenue).

Generate

Select “Generate”. Asemic scaffolds the events plus starter properties and metrics into your draft. Nothing is live yet; the next cards offer metric packs to build out the model, and it all ships when you publish.