This walkthrough takes you from an empty project to a dashboard with real data in about ten minutes. You need a BigQuery project (or Snowflake account) that holds your raw event tables, and credentials that can read them.

Asemic guides the same path in-product: the Data Model page shows suggestion cards that appear as you complete each step. This page explains what each step means so the cards never surprise you.

Your raw data stays in your warehouse throughout. Asemic connects and pushes queries down; it does not copy your events out.

1. Connect your warehouse

On the Data Model page, the card “Connect your database” is the only one showing on a new project. Select “Connect warehouse…”.

In the “Connect your warehouse” dialog, pick your provider:

BigQuery: enter the “GCP Project ID”. For a quick evaluation, choose “Google account (OAuth)” and sign in with Google. For anything durable, choose “Service account key” and paste the key JSON. A service account is a workload identity, not tied to a person. See Connect your warehouse for how to create one.
Snowflake: enter “Username”, “Password”, and the “JDBC URL”.

Select “Test connection”, and once it passes, “Save connection”.

2. Set up events

With a connection saved, the card changes to “Set up your events”. It opens the “Set up events” wizard.

Step 1 of 2 — Source. Point Asemic at your raw data:

“Events dataset / schema”: the dataset that holds your raw event tables, for example game_raw.
“How are the events stored?”: the one real decision on this screen:
- “One table per event”: each event type is its own table (login, purchase, registration, …).
- “One big events table”: all events share one table, and a column such as event_name tells them apart.
“Data model schema”: where Asemic writes the model it derives. It must be writable; “Test destination” verifies that.
“Active days”: leave the default of 90 for now. It is explained in Materialization.

Step 2 of 2 — Events. What you see depends on the layout you picked:

One table per event: a prepopulated table with one row per discovered event table (Source table, Event id, Role, User id, Timestamp, Date), every value detected automatically and overridable from dropdowns.
One big events table: pick the “Events table” and the “Event type column”, then select “Scan events”. Asemic inspects the last 7 days, lists the event types it finds, and drops columns that are always empty.

The one column worth checking now is Role: it decides which starter metrics each event unlocks:

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; excluded from activity so it can’t inflate DAU

Make sure your registration event has the Registration role and your purchase event has Payment, then select “Generate”. Asemic scaffolds the events plus starter properties and metrics.

3. Build out the model

New suggestion cards now offer metric packs: daily activity, retention, revenue, and more. Each card lists what it adds; “Add to draft” applies it. Nothing is live yet: everything lands in your draft.

Packs appear only when their prerequisites exist, so the order is self-pacing; add the ones you want. For the quickstart, daily activity and retention are enough; the full list is on Build your model.

4. Publish

Select “Publish” in the header. The “Review changes before publishing” dialog summarizes what your draft adds, changes, and removes against the published model. Removals are called out prominently, because publishing replaces the whole model.

Confirm to publish. This creates an immutable model version; your draft keeps being your working copy.

5. Backfill

One step left, and it is the one people miss: charts read a precomputed table that Asemic builds in your warehouse. Publishing defines the model; backfilling computes it for a date range. Until days are backfilled, charts show gaps.

A card, “Backfill N recent days”, appears when recent days aren’t materialized. Select “Review & backfill…”, or open the ⋮ menu → “Materialization coverage…” for the full per-day view, and start a backfill for the range you care about. Progress survives closing the dialog; the header shows “backfilling X/Y” with an estimate.

Done: open a dashboard

When the backfill completes, open a dashboard: DAU, retention, and whatever packs you added are charting real data from your own warehouse. From here, explore the data model concepts or refine events on the Set up events page.