PlayGenusDocs

Migrate from Firebase Analytics

Export your Firebase Analytics event history from BigQuery and import it into PlayGenus, so churn and LTV models train on your real players from day one.

Moving from Firebase Analytics to PlayGenus takes three steps: export your event history from BigQuery as JSON, upload it to PlayGenus, and review the event mapping we propose. Once the mapping is confirmed, your history is ingested and the churn, LTV, and forecast models train on your real players — so predictions arrive with context instead of starting from an empty dataset.

This is the migration path we've run end-to-end with real studio data, and this page is the full walkthrough. For the general import mechanics — file limits, the mapping review UI, multi-file imports — see Import your historical data.

Where your Firebase data actually lives

Firebase Analytics doesn't let you export raw events from its console — the raw data lives in BigQuery, via the BigQuery export integration. Two situations:

  • BigQuery export is already enabled: your events are sitting in tables named analytics_<property_id>.events_YYYYMMDD. You're ready to export.
  • It isn't enabled: turn it on now (Firebase console → Project settings → Integrations → BigQuery). The catch: export only starts collecting from the day you enable it — it doesn't backfill. If you're planning a migration, flipping this switch early is the single best thing you can do, even if the move is months away.

Step 1 — Export as JSON, not CSV

The Firebase fields that matter — event_params and user_properties — are nested and repeated, and BigQuery can't export nested columns to CSV. Export as JSON instead:

EXPORT DATA OPTIONS(
  uri='gs://your-bucket/firebase-*.json',
  format='JSON'
) AS
SELECT * FROM `<project>.analytics_<property_id>.events_*`
WHERE _TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYYMMDD'

Set the _TABLE_SUFFIX range to the dates you want. This produces newline-delimited JSON (NDJSON) in your GCS bucket — download it from there.

A few practical notes:

  • Bring as much history as you have. Model quality is gated by total span — 90 days is a sensible minimum, six months or more is meaningfully better. The import guide has the full breakdown of what each span unlocks.
  • Files over 1 GB: split the export by date range (narrower _TABLE_SUFFIX windows) and upload the parts. After your first file's mapping is approved, the rest can go up together in one batch.
  • Already have a pre-flattened CSV from an old pipeline? That works too — the importer takes CSV, JSON, NDJSON, and TSV.

Step 2 — Upload to PlayGenus

In the dashboard: Historical Imports → New import, pick Firebase as the source format, and drop the file in. Uploads go straight from your browser to storage, so a multi-hundred-megabyte export doesn't stall on an intermediate hop.

You need an onboarded game with an approved tracking plan first — import maps your old events onto that plan, so the plan has to exist. Not there yet? Start with How onboarding works.

Step 3 — Review the mapping

After 5–30 seconds of parsing, you get a mapping table: every Firebase event type in your file, matched to a target event in your PlayGenus tracking plan. Firebase's automatic events (session_start, first_open, app_remove) map naturally onto session and lifecycle events; your custom events map onto whatever you and we agreed they should be during onboarding. Your Firebase user_pseudo_id becomes the player identifier, and event_params become event properties.

Include what's worth keeping, exclude what isn't, correct anything we got wrong, and submit. A PlayGenus engineer confirms the mapping with you before a single row is ingested — a bad mapping quietly corrupts every model downstream, so this check is deliberate. The full tour of the review UI is in the import guide.

What happens after

Once confirmed, your history is translated through the mapping and loaded, and the models that depend on it retrain — churn, LTV, survival, and the DAU, revenue, and session forecasts. Dashboards populate as soon as the import lands; predictions follow when retraining completes.

From that point on, your live events come from the PlayGenus SDK while your past lives in the same dataset — one continuous history, no gap where the migration happened.

Common questions

Do I have to stop using Firebase? No. Plenty of studios run both during a transition — Firebase keeps feeding its export while PlayGenus ingests live events, and you switch off the old one whenever you're comfortable.

What about GA4 properties? Firebase Analytics data for apps is GA4 under the hood, and it exports through the same BigQuery integration — the same walkthrough applies.

My export has events I never want in PlayGenus. Exclude them in the mapping review — exclusions are remembered in your saved mapping, so you won't re-exclude them on the next import.

On this page