Docs

Firebase Default Event Parameters Tracking

Firebase default event parameters add context to every Analytics event. Learn what to set, how to implement it and how to avoid common mistakes.

Analytics

Most analytics problems aren’t about missing events. They’re about missing context. You can see that 4,000 users hit “checkout started”, but not which experiment variant they were in, which subscription tier they’re on, or which build they were running. So every team ends up copy-pasting the same five parameters onto every event call, and sooner or later one of them gets forgotten.

Firebase Analytics has an API built for exactly this: default event parameters. You set a parameter once and the SDK attaches it to every event logged afterwards. It’s been available on Android and iOS for some time, and Firebase has kept refining it, including a fix so defaults are applied consistently to automatic events such as first_open and session_start. If you haven’t audited how you use it, you’re probably either repeating yourself or missing context on events that matter.

Without it, you get inconsistent dimensions, queries that can’t be segmented, and reports where half the events are “not set”.

Data Points to Track

  • App environment, such as production, staging or beta, so test traffic never pollutes real reports
  • Experiment or variant ID for any live A/B test or remote config rollout
  • Subscription or plan tier at the time of the event
  • Acquisition channel or campaign label held on the device
  • Locale or region if your reporting depends on it
  • Build type or release channel, for example store, internal or TestFlight
  • Parameter coverage rate: share of events in BigQuery or DebugView that carry each default parameter

Setup Steps

  1. Choose three to five parameters that apply to nearly every event. Keep the list short; every parameter counts toward Firebase’s limit of parameters per event.
  2. Call setDefaultEventParameters early in app start-up, before your first custom event is logged, and again whenever a value changes, such as when a user upgrades their plan.
  3. Remove duplicate parameters from individual event calls so there’s one source of truth for each value.
  4. Verify in DebugView. Trigger a few events, including automatic ones, and confirm the defaults appear on each.
  5. Register the parameters as custom dimensions in the Firebase and GA4 console so they’re available in reports.
  6. Check the BigQuery export after a day to measure coverage. Any event missing a default parameter points to a start-up ordering problem.

Actionable Insights

The first thing the data tells you is where your event pipeline is inconsistent. If coverage for a default parameter is below 100%, events are being logged before the defaults are set, usually during cold start. Fix the ordering and your first-session data becomes far more trustworthy, which matters because first-session behaviour drives activation analysis.

Once the context is reliable, segmentation gets cheap. Compare conversion by plan tier or variant without writing special queries. You’ll often spot that a headline metric is hiding a split: a feature that looks flat overall may be up for paying users and down for free ones.

Be careful with values that change mid-session. A default is applied when an event is logged, so an upgrade followed by an outdated parameter will mislabel later events. Update the default whenever the underlying state changes, and clear it when the user signs out. Also never put personal data in a default parameter; it travels with every event.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert