App analytics from day one: the events to track and how to set them up with Firebase

Five business questions come before any event name

An analytics setup fails quietly. The app ships, the dashboard fills with numbers, and three months later nobody can answer the question the founder actually had.

So I start from questions, not events. For a booking or ordering app there are usually five: how many people install and open the app, how many create an account, how many start a booking or an order, how many finish and pay, and how many cancel or ask for a refund. Every event in the plan should answer one of those. An event that answers nothing is noise you will have to scroll past for years.

I would not ship version one without the completed booking or purchase event, sent with a value and a currency. It is the one number every later decision leans on. Adding it after launch means your first weeks, often the most interesting ones, are missing from the report.

What Firebase records without any code

Google's list of automatically collected events is long, and most of it costs you nothing. Once the SDK is in the app, these arrive on their own:

• first_open: the first launch after an install or reinstall.
• session_start and user_engagement: a session begins, and the app sits in the foreground for at least one second.
• screen_view: a screen transition with a new screen name, class or ID.
• app_update and os_update: the app or the phone's operating system moves to a new version.
• app_remove: an uninstall, on Android only.
• notification_open and notification_foreground: when you send push through Firebase Cloud Messaging.
• app_exception: a crash, once Firebase Crashlytics is integrated.
• in_app_purchase: only for purchases processed by the App Store or Google Play, not your own card payments.

An event plan for a typical booking or ordering app

Recommended events are the ones Google has already named, and its help page is clear that they are not sent automatically. Use them where they fit, because their parameters line up with Google's own reports. Use custom events for the steps that are specific to your business, such as picking a time slot.

This is the plan I would start from for a salon booking app or a restaurant ordering app. Swap the item for a service, a table or a dish.

The limits and naming rules that cause trouble later

Firebase is generous, but the rules are fixed and some of them only show up once the data is wrong. These are the ones I check against the plan before anyone writes code.

• Up to 500 distinctly named events per app user. Automatically collected events do not count towards it.
• Event names and parameter names: 40 characters each. Parameter names start with a letter and use only letters, numbers and underscores.
• Up to 25 parameters per event. String values up to 100 characters.
• Parameter values in Flutter must be a String or a number.
• Event names are case-sensitive. booking_cancelled and Booking_Cancelled become two separate events, and your report splits in half.
• The prefixes firebase, google and ga_ are reserved for parameter names.
• If you send a value, send a currency. Google's event reference says currency is required for revenue metrics to be computed accurately. For a UAE app that means AED on every purchase.
• User properties: up to 25 per project, names up to 24 characters, values up to 36. Create the custom definition in the Firebase console first. Age, Gender and Interest are reserved.
• No personal data. Google's policy prohibits sending anything it could recognise as personally identifiable, such as email addresses or phone numbers, and that includes event parameters and search terms people type in.

Setting it up in Flutter and checking it in DebugView

Firebase's Flutter setup runs through two command line tools. Install the Firebase CLI and sign in, activate the FlutterFire CLI with dart pub global activate flutterfire_cli, then run flutterfire configure in the project. It generates a firebase_options.dart file. Add firebase_core, call Firebase.initializeApp with DefaultFirebaseOptions.currentPlatform before runApp, then run flutter pub add firebase_analytics. Run flutterfire configure again whenever you add a Firebase plugin or a platform.

I put every event behind one small Dart class with a method per event, such as bookingCancelled(bookingId, hoursBefore). Screens never call logEvent with a raw string. That one rule keeps names consistent and makes the event plan readable in the code. For screen views in Flutter, Firebase's screen tracking page shows logging screen_view yourself with firebase_screen and firebase_screen_class parameters, which I do on each route change so the names match the screens your team talks about.

Then verify. DebugView shows events from a test device within seconds, with their parameters and user properties. On Android, turn it on with adb shell setprop debug.firebase.analytics.app followed by your package name. On iOS, add -FIRDebugEnabled to the launch arguments in the Xcode scheme. Walk through a full booking and a cancellation and tick each row of the plan.

One catch. Firebase's DebugView page says debug events are not filtered out by default. Set up a developer traffic filter in the Analytics property, or your own testing inflates the launch numbers.

Where the event plan sits in my packages

Analytics setup fits inside any of the three packages: Launch at $999 for up to 10 screens, Growth at $1,699 with your own Node.js backend and PostgreSQL database, and Scale at $2,500 with an admin dashboard. The exact scope is agreed in writing before work starts, and I recommend the event plan goes into that document as a table like the one above, so we both know which events ship in version one.

Adding analytics also changes what you declare to the stores, so your App Store privacy labels and Google Play Data safety answers need to match it. I covered that in a separate post, linked below. Third-party fees and ongoing maintenance are not included in the package prices.