If your game uses Firebase Analytics (or Google Analytics 4) with the BigQuery export linked, you already have everything Asemic needs. Asemic reads the export directly: no flattening pipeline to build, no scheduled views to maintain, and the connection stays read-only. For many studios this means the “connect your warehouse” step is already done before they arrive.

What the export looks like

Linking Firebase or GA4 to BigQuery creates a dataset named analytics_<propertyId> containing one table per day (events_20260718, events_20260719, …), plus an events_intraday_ table for the current, not-yet-finalized day. Days finalize roughly 24 to 72 hours after they close. Useful fields like level, score, or purchase value live inside a nested event_params structure rather than as flat columns.

Raw, that shape is awkward to query. Asemic handles both parts of the awkwardness for you: the daily shards behave as a single events source, and the nested parameters surface as ordinary typed columns.

Connect

Follow the standard warehouse connection with BigQuery. The connection needs read access to your analytics_<propertyId> dataset and write access to the dataset you choose as “Data model schema”. A service account with those two grants is enough; Asemic never needs to write to the export itself.

Once connected, the dataset listing shows the export as a single events_* entry instead of thousands of daily tables.

Set up events with the GA4 starter

Run event setup as usual and pick your analytics_<propertyId> dataset. When Asemic recognizes the Firebase shape, the wizard offers “Load GA4 starter”.

The starter pre-fills the event list with the standard GA4 automatic events and the events Google recommends for games, so you review a populated model instead of building one:

Events: first_open, session_start, in_app_purchase, level_start, level_end, and the rest of the standard set, split out of the one big export table by event_name.
Parameters as columns: the common event_params for each event (level, score, value, and so on) are extracted as typed columns, so they work as dimensions and in metrics like any physical column.
Identity: user_pseudo_id is used as the user id.
Time: the event day is derived from the export’s microsecond event_timestamp, so date handling is correct without any preparation on your side.
Roles: first_open maps to Registration (anchoring cohorts, retention, and LTV) and in_app_purchase to Payment (anchoring revenue).

Review the list like any other setup, adjust anything that does not match your game, then “Generate”, build out the model, publish, and backfill.

Why direct support matters: query cost

BigQuery only skips irrelevant daily shards when a query filters on the shard suffix itself. The common workaround for tools without native support, a view over events_*, silently loses that: every chart scans the entire history of the export on every load. With two years of events that is a real bill, on every query.

Asemic compiles shard pruning into the query: a chart over a date range reads only that range’s shards. This is what makes the export usable directly, with read-only credentials, at a predictable cost.

Today’s data (intraday)

By default Asemic reads finalized days only, which is what materialization works from; the current day lands after Google finalizes it. If you need today’s events in live charts, the source can also read the events_intraday_ table, deduplicated against finalized days so the boundary day is never double-counted. Backfills always use finalized days only.

Honest limitations of the export

These are properties of the Firebase/GA4 export itself, worth knowing regardless of tooling:

Identity resets. user_pseudo_id is a device-scoped id; it resets on reinstall. If your game has accounts, set user_id in the SDK and retention across reinstalls becomes measurable.
Attribution is first-touch. The export carries a user-level traffic_source (the first attributed source), not full MMP-grade attribution. Good enough to segment cohorts by acquisition source; not a replacement for your MMP.
Ad revenue needs linking. In-app purchase revenue is in the export by default; ad revenue appears only if you link AdMob (or import ad revenue events yourself).