Asemic is warehouse-native product analytics for free-to-play games. When retention or revenue moves, it decomposes the change into its real drivers: user acquisition, onboarding, core-game. Point-in-time correct, running inside your own BigQuery or Snowflake.
45 minutes, on your own data. Pick a time directly, no sales loop.
If you own the numbers at a studio (analyst, data lead, product), you know the three places that question goes to die:
Dashboards show the metric moved. Explaining it burns analyst-weeks of manual slicing across every change you shipped.
“What was this player’s level on their day-7?” means hand-writing as-of SQL; dimension tables only keep now.
Every dashboard defines DAU a little differently, so the team argues about whose number is right instead of what to do.
Two capabilities work together to produce a why you can act on:
A retention move between two periods or cohorts is decomposed into UA, onboarding, and core-game contributions, validated against known and A/B ground truth, and extending to revenue. You decide with attribution, not hunches. Deep dive & launch news →
A decomposition is only as good as its cohorts. Asemic resolves any dimension as of a calendar or relative day (“level on day-7,” “spent >$100 in January”) so you compare the world as it actually was. No hand-rolled as-of SQL.
So the whole system is built for verification: where it runs, and how every number is defined.
Everything compiles to SQL that runs in your BigQuery or Snowflake (pushdown). Nothing is copied out; every query is deterministic and inspectable.
Each metric is one legible line a CMO can sign off on; the engine compiles governed, dialect-correct SQL underneath. An auditable answer to “who agreed this is MAU?”
Increasingly, yes. And that’s exactly the point. When generating a definition is nearly free, the cost moves to trusting it. So every Asemic definition is a contract: legible enough for a human to verify the intent, governed enough for the engine to guarantee the semantics.
metric.avg_impressions = metric.impressions / metric.dau
label "Avg Impressions"Reads at the altitude of the business idea; a CMO can sign off at a glance.
SELECT SAFE_DIVIDE(
SUM(impressions),
COUNT(DISTINCT user_id)
) -- null-safe /0, tz & cohort-day correct, per-dialectBigQuery gets SAFE_DIVIDE; Postgres gets NULLIF. Same line, correct everywhere.
Producers and leads never open a BI tool, but they already live in AI chat. Connect Asemic as an MCP server and every metric the studio defined is available by asking.
Connect it from the docs → Works with Claude · ChatGPT · Gemini CLI
BigQuery or Snowflake. Read-only-friendly; your data never leaves it.
Map events → properties → metrics in a friendly, formula-driven editor. Game-standard metrics come scaffolded.
Point-in-time cohorts, funnels (event sequences), and dashboards, all speaking the same definitions.
Break any KPI move into UA / onboarding / core-game, and look forward with predictive LTV & retention.
Asemic compiles all of it to SQL that runs in your warehouse.
The metrics and cohorts you actually use, scaffolded and correct by construction. That curated library of F2P primitives is the hard part an AI can’t reliably improvise, and why a studio gets a working model fast.
Three levels, each built from the one below: raw event tables → reusable properties (“days since registration”, “total spend”) → metrics, defined formula-style. Everything compiles to dialect-correct SQL pushed down to your warehouse, safe defaults included (÷ becomes SAFE_DIVIDE on BigQuery, NULLIF-guarded division elsewhere). Event tags keep the model honest: system-triggered events (push delivery, server jobs) are excluded from activity, so infrastructure can never inflate DAU.
The data model →Dimension values resolve as of any calendar or cohort-relative day, and predicates can aggregate over windows (“average spend > $100 in January”). No snapshot tables to maintain, no as-of joins to hand-write: historically-correct state is a first-class query primitive.
Charts never scan raw events. They read a precomputed entity table: one row per user per day, carrying that user's properties as of that day, built in your warehouse in a dataset you choose. Lapsed users keep a frozen row for a configurable window (default 90 days) so churn and resurrection cohorts stay visible. Coverage is per-day and backfills are incremental: extending history computes only the days you add.
How materialization works →A sequence language powering funnels and behavioral cohorts: ordered events, time-shifted conditions (“purchase within 1 day of second login”), and sequence-derived properties you can reuse in any metric or cohort.
Decomposes a KPI delta between periods/cohorts into UA, onboarding, and core-game contributions. Validated against A/B data and datasets with deliberately injected effects where the algorithm recovers the known answer. Known edge cases are still being refined; we say “validated against ground truth,” not “perfect.”
Validation deep dive →Predictive LTV and retention built for F2P economics, covering both IAP and ad revenue, to complement the causal view with a forward-looking one.
The AI chat integration is a standard MCP server with per-user OAuth: the assistant holds a scoped token, sees only the projects that user can see, and gets typed, read-only tools (list metrics, run a query, plot a chart) over the same named definitions as your dashboards, never raw SQL. Invalid queries return precise errors the model corrects on its own, visible in the chat's tool log.
Connect an AI chat →Connect via a service account (recommended) or OAuth: read access on your raw event datasets, write access only on the dataset where the model is built. Queries run in your project, under your permissions, billing, and audit logs. Definitions are centrally owned and versioned: the working draft is separate from the immutable published model your charts read.
Connect your warehouse →