Which Events Should You Track in a Mobile App? A Firebase Analytics Event Plan

Many teams treat a Firebase Analytics setup as a package they install and forget. However, the data it collects on its own only tells you how many people opened the app. To see where users drop off, which screen earns money, or which release hurt retention, you need an event plan.

At Talha Aslan and team, we write the measurement plan before anyone writes tracking code. In this guide we walk through the same method step by step:

• You will learn which events arrive automatically.
• Next, you will see which events to add for sign up, first value, purchases, and subscriptions.
• You will find naming rules and limits in one table.
• Finally, you will learn how to measure without sending personal data and how to test the setup.

What is an event, and how is it different from a screen view?

An event is a record of one action at one moment in your app. For example, adding a product to the cart, starting a video, or opening the checkout screen are all events. Each event has a name and optional parameters. The parameters carry the details of that moment.

A screen view is a special kind of event. Firebase records screen transitions on its own under the name screen_view. In other words, you can see how often each screen opens without writing code. Still, a screen opening does not mean the user did anything on it.

Think of a simple case. A thousand people may open your checkout screen, yet screen data cannot tell you how many entered card details or finished paying. Therefore, treat screen views as a starting point and events as your real decision data. In short, screen counts describe traffic, while events describe behavior.

If you want to compare this with the web side, our article on missing GA4 conversions shows how the same event logic behaves on websites and where it usually breaks.

Which events does Firebase Analytics collect automatically?

Firebase Analytics records a set of events as soon as the SDK is in your app, with no extra code. Google's list of automatically collected events shows each one and the platform it works on. These are the ones you will use most often for apps:

• first_open: the user launches the app for the first time after installing or reinstalling it.
• session_start and user_engagement: a session begins, and the app stays in the foreground for at least one second.
• screen_view: a screen transition happens.
• app_update and os_update: the app or the operating system updates.
• in_app_purchase: an in-app purchase completes.
• app_remove: the app gets uninstalled; this event works on Android only.
• notification_open: the user opens a Firebase notification.

In addition, the app_exception event requires the Crashlytics integration. According to the same list, the subscription convert, renew, and cancel events work automatically on Google Play only. As a result, you need your own events or a server side solution to see the same data on iOS.

Why are automatic events not enough on their own?

Automatic events look the same in every app, because they know nothing about your business model. A booking app and a game produce the same first_open and session_start data. Yet one succeeds when people book appointments, and the other succeeds when players clear levels.

Here are a few typical questions that automatic data cannot answer:

• How many people who opened the sign up form actually finished it?
• In which session did users first experience real value?
• Which feature did paying users try before they upgraded?
• What did users do when a search returned nothing?

Screen counts solve none of these. Moreover, automatic events fill your reports with volume, so every chart you check without custom events only shows traffic. That is why we think of a Firebase Analytics setup in two layers. The bottom layer holds automatic events. The top layer holds recommended and custom events that answer your business questions.

For instance, if your MVP scope is still open, our guide on what a mobile app MVP should include helps you decide which features, and therefore which events, belong in the first release.

What is the difference between recommended and custom events?

Recommended events are events whose names and parameters Google has already defined. For example, sign_up, login, search, share, add_to_cart, begin_checkout, purchase, and refund belong to this group. When you send them with the recommended names, reports recognize them and fill the matching fields.

Firebase's guide to logging events suggests the same path. Log the recommended events that fit your app, together with their prescribed parameters. If no recommended event fits, you define a custom event. The example in the guide is a custom event called share_image.

In practice, the rule is simple. First, check whether the action already exists in the recommended list. If it does, use that name and those parameters exactly. If it does not, choose a short, clear custom name for the moment that matters to your business, such as creating a booking or showing a paywall.

On the other hand, reinventing a recommended event under your own name is a common mistake. If you log a purchase as order_completed, your revenue reports stay empty. So always check the recommended list before you invent a name.

Which question should your measurement plan start with?

A measurement plan starts with business questions, not with an event list. First, you write the sentence that defines success for your app. Then you pick the events that prove or disprove that sentence. This way, you avoid a setup full of events that never lead to a decision.

This is the order we follow on our projects:

1. Write a one sentence definition of success, such as a user who books at least once a week.
2. List the path to that definition step by step: install, sign up, first search, first booking, repeat booking.
3. Assign one event to each step and check whether a recommended event already covers it.
4. Note in one line which question each event will answer.
5. Limit the parameters on each event to a handful.
6. Share the plan with developers and marketers in one table.

That table also becomes a shared language across releases. When a new feature arrives, you add a row first and write code second. In other words, measurement stops being an afterthought and becomes part of the product design from day one.

Which events track the sign up and login flow?

The recommended events for this flow are sign_up and login. Both accept a parameter called method, which describes whether the user came in through email, phone, or a social login. As a result, you can compare which method people complete most often.

However, measuring only completed sign ups does not show where people drop off. That is why we suggest adding a small custom event at the start of the flow. For example, sign_up_start for opening the form and otp_request for requesting a verification code are enough.

Example scenario: a large share of users who open the sign up screen disappear at the verification code step. In that case, the problem is probably not the design. It is more likely a slow code delivery or a confusing phone number format. With an event plan, the team looks in the right place.

One warning belongs here. Never write the user's email address or phone number into a sign up parameter. The method alone is enough, because you measure behavior, not people. We cover this in more detail in the personal data section below.

How do you measure the first moment of value?

The first moment of value is when a user first experiences the benefit your app promises. Saving a first note in a notes app, creating a first booking in a booking app, or adding a first product to favorites in a shopping app are good examples. Usually, one custom event captures this moment.

Because the recommended list has no direct match, you name this event to fit your business. For example, first_booking_created or first_note_saved. Some teams also use the recommended tutorial_begin and tutorial_complete events for intro screens. That way you can separate users who finish the intro from those who skip it.

Why does this event matter so much? Because reaching this moment in the first sessions shapes retention more than almost anything else. Once you track it, you can compare how users who reached it behave in the following days against users who never did.

If you want to redesign your intro screens around this moment, our article on how to design an app onboarding flow covers the design side of shortening the path to first value.

How should you set up purchase and cart events?

For an app that sells, you set up the recommended ecommerce events in order: view_item_list, view_item, add_to_cart, view_cart, begin_checkout, add_payment_info, and purchase. For returns, you use refund. This sequence lets you see each step of the purchase funnel on its own.

Three parameters on the purchase event matter most:

• transaction_id: stops the same order from counting twice.
• value: the order amount, which feeds revenue reports.
• currency: the currency code; without it, reports cannot read the amount correctly.

In addition, you send an items array with product name, category, and quantity. This shows which products or categories sell best. If you are still choosing between in-app purchases and web payments, our comparison of in-app purchase vs web payment also explains how that choice affects measurement.

Finally, send the purchase event only after the payment is actually confirmed. If you send it when the user taps the pay button, failed payments will look like sales.

Which events matter most in a subscription app?

Subscription measurement splits into two parts: the decision moments before someone subscribes and the lifecycle after. For decision moments, you define custom events such as paywall_view, plan_select, and trial_start. For the lifecycle, you track trial conversion, renewal, and cancellation.

According to Google's list of automatic events, app_store_subscription_convert, app_store_subscription_renew, and app_store_subscription_cancel work automatically on Google Play only. Therefore, to see the same lifecycle on iOS, you need to receive store notifications on your server and map them to your own events.

Example scenario: many users see the paywall, but few start a trial. Before touching the price, you check where and when the paywall appears. Adding the paywall source as a parameter, such as settings, a locked feature, or first launch, answers this question in a single report.

Also, keep subscription events consistent across platforms. If Android sends trial_start and iOS sends start_trial, your funnel splits into two halves that never add up. One shared naming table prevents this.

Which naming rules actually work for events?

Event names are case sensitive. So Purchase and purchase become two separate events, and your reports split. According to Google's event naming rules, names must start with a letter and cannot contain spaces. You may use numbers and underscores. Some names are also reserved for the system.

The table below combines the values from Google's event collection limits page with the naming habits we use in practice. Limits can change, so check the current values on the official page.

The fourth row matters most. Opening a new event for every variation burns through the limit fast. Instead, use one event with a descriptive parameter.

How do you choose parameters and user properties?

A parameter adds context to a single event, while a user property describes the user over time. For example, the source parameter on paywall_view tells you where the paywall opened. The plan_type user property, on the other hand, says whether that person is on a free or premium plan.

According to the Firebase documentation, you must register custom parameters as custom definitions in the console before they show up in reports. Text values become dimensions, and numeric values become metrics. If you skip this step, the data arrives but never appears in your reports.

Ask these questions before you add one:

• Do I want to filter or compare a report by this value?
• Does the value change with each event, or does it belong to the user?
• Could the value identify a person?
• Does the value come from a short fixed list, or is it free text?

Avoid free text. For example, sending raw search terms strains the value limit, and users may type personal details by accident. Instead, use bounded values such as result count or category.

How should you order events for funnel analysis?

Funnel analysis shows what share of users completes each step toward a goal. For instance, opening the app, viewing a product, adding to cart, and purchasing form a purchase funnel. Each step maps to one event, so the events need to be complete before you build the funnel.

A good funnel needs events that meet three conditions. First, there should be no gaps between steps; without begin_checkout, you cannot see the loss between cart and purchase. Second, each step needs the same name on every platform. Third, events should reflect the real moment, because a screen opening and a button working are not the same thing.

Example scenario: Android sends add_to_cart when the user taps the button, while iOS sends it when the cart screen opens. In that case, you cannot compare the two funnels. The fix is to write the trigger moment of each event into the measurement plan.

We explain the marketing side of funnels and how to define stages in what a conversion funnel is. An app funnel works the same way; the only difference is that steps are events instead of pages.

Which events do you need for cohort and retention analysis?

A cohort is a group of users who first opened the app in the same period. Retention shows how many of them come back in the following days. Firebase uses first_open and session events for this calculation, so you see the basic retention curve without any code.

That said, the basic curve only measures return visits. The real question is usually different: did returning users repeat the action that creates value? To answer it, you pick the first value event and the main repeat event, such as booking_created or purchase, as criteria in your cohort report.

Keep these points in mind when you read cohorts:

• Split cohorts by release date, so you can see the effect of each new version.
• Evaluate campaign periods separately, because paid users behave differently.
• Compare Android and iOS cohorts side by side.
• Look at a trend across several weeks instead of judging a single cohort.

If you want to know how ad traffic gets measured on iOS, our article on App Tracking Transparency (ATT) explains how the permission prompt affects measurement.

Which personal data should you never send to Firebase Analytics?

Google's personal data policy asks you not to send Analytics any data that Google could use to identify a person. Examples include email addresses, personal mobile numbers, and national ID numbers. The list gives examples only, so it is not complete.

In apps, teams break this rule most often in these places:

• Adding the email address as a parameter on the sign up event.
• Sending search box text exactly as the user typed it.
• Putting a phone number into the user ID field.
• Sending precise location as a parameter.

The policy also forbids precise location data. Instead, you use general values such as city or region. If you need to tell users apart, use an identifier your own system creates that does not directly identify the person.

For the wider privacy picture, including notices and consent, our guide on building a GDPR compliant website covers principles that also apply to apps. This article is not legal advice, so please consult a lawyer about your specific case.

How does your event plan affect store privacy disclosures?

Once you add an analytics SDK, you must disclose the data it collects to both stores. According to Google Play Help, the Data safety form also covers data that third party libraries and SDKs collect. The App activity category and the Analytics purpose are typical parts of that disclosure.

Apple takes a similar approach. Its App Privacy Details page says you must include data that third party code in your app collects, and analytics tools count as such code. The Product Interaction data type and the Analytics purpose appear here too.

So your measurement plan doubles as your disclosure list. Whenever you add a new event or parameter, check whether your disclosures are still accurate. If the store rejects a build, our overview of the most common app rejection reasons helps you find the cause faster.

What does linking Firebase with GA4 mean?

Analytics data in Firebase runs on the Google Analytics platform. In practice, this means you can also view your app data in a Google Analytics property. If your website sits in the same property, you can study app and web data side by side.

This link has three practical results. First, you can mark important events as key events; Google defines a key event as an action that matters most to the success of your business. Second, you can build audiences and use them for ads and notification targeting. Third, you can export raw data to BigQuery for deeper analysis.

According to the automatic events list, the Google Play subscription convert and renew events count as key events by default. You mark your other important events yourself, such as the first booking or the purchase.

When key events show lower numbers than you expect, the usual causes are a wrong trigger moment, a renamed event, or missing parameters. Fixing the plan usually fixes the report.

How do you test Firebase Analytics events before release?

You test Firebase Analytics events before release with DebugView. DebugView shows events from a debug enabled device in near real time. This lets you check whether each event name, parameter, and trigger moment matches the plan.

According to the DebugView documentation, you enable debug mode with a command line setting on Android and a launch argument in Xcode on iOS. During testing, we recommend these steps:

1. Trigger every event in the measurement plan one by one.
2. Check the spelling and letter case of each event name.
3. Confirm that parameters carry the right values and never arrive empty.
4. Complete a purchase in a test environment and check the transaction_id field.
5. Repeat the same flow on both an Android and an iOS device.

The same documentation notes that debug events go into the daily BigQuery export by default. To keep test traffic out of reports, we recommend that you set up a developer traffic filter in your property.

What are the most common event setup mistakes?

Most mistakes we see come from planning, not from code. The setup works, yet the data never leads to a decision. These are the mistakes we run into most often:

• Using a custom name where a recommended event already exists.
• Giving the same event different names on Android and iOS.
• Opening a separate event for every screen or button and burning through the limit.
• Forgetting to register custom parameters in the console.
• Sending purchase before the payment is confirmed.
• Writing personal data into parameters or the user ID field.
• Letting test traffic mix with live reports.

The shared fix is a written measurement plan. Without one, every developer names events by personal habit. After a few releases, the same action appears under three names, and merging historical data gets hard.

Another frequent problem is losing the campaign source. For links that take users to the right screen inside your app, our deep link guide helps you keep that source intact.

Example scenario: an event plan for a booking app

Picture a booking app for a beauty salon. The success definition: a user who books within the first week and books again the following month. Based on that, the event plan looks like this. Only the structure is an example here, not any numbers or results.

1. first_open and screen_view: these arrive automatically.
2. sign_up: a recommended event with the method parameter.
3. search: carries the service category as a parameter, never free text.
4. slot_view: a custom event for the list of open time slots.
5. booking_created: the first value and main event, marked as a key event.
6. booking_cancel: the reason comes from a short fixed list.
7. notification_open: an automatic event that shows how reminders perform.

With this plan, the team can answer three questions. How many new users reached a booking? How often did those users come back? Did reminder notifications reduce cancellations? In short, seven events feed most product decisions.

Pre-release measurement checklist

Before you submit the app to the stores, we suggest you tick off these items one by one. This list prevents data loss that you cannot recover after release:

• The measurement plan exists in writing and the whole team has it.
• Recommended events use their recommended names.
• Custom event names are short, lowercase, and identical on both platforms.
• Custom parameters are registered as custom definitions in the console.
• The purchase event carries transaction_id, value, and currency.
• No event contains an email address, phone number, or precise location.
• Important events are marked as key events.
• DebugView testing is complete on both platforms.
• A developer traffic filter is in place.
• Store privacy disclosures match the measurement plan.

Review this list again with every major release. New features usually bring new events and new disclosure needs.

Who should build the measurement plan alongside the app?

The healthiest approach is to build the measurement plan together with the team that develops the app. The decision about when an event fires ties directly to the flow in the code. Measurement that comes later often ends up with missing steps and inconsistencies between platforms.

At Talha Aslan and team, our mobile app development projects cover the full path: we build your app and we take it to the stores. The measurement plan belongs to that process from the start. We turn your business questions into events, set up Firebase Analytics, test with DebugView, and prepare store privacy disclosures that match the plan.

If you already have an app, we follow the same method. First, we review your current events and naming. Then we fill the gaps release by release. To scope the work, simply request a quote through our mobile app development service page.