Overview

Data collection is vital to make informed decisions about development and marketing of apps. In Settle Up, there are 3 places where we can view data that the apps send to cloud:

• Firebase Analytics (FBA)
• Google Analytics (GA)
• Google BigQuery (BQ)

How they work together in practice: The Firebase SDK collects user interactions inside the apps and feeds the data into GA backend. At the same time, GA streams those raw event records into BigQuery. This approach is called event-driven: everything that happens while the user is using the app is collected as an event. Events might be triggered by the user or by the app itself. Some events are default (collected automatically thanks to the SDK), others are custom – created by us.

Comparison

Firebase Analytics, Google Analytics, and BigQuery are not three mutually exclusive competitors; rather, they represent different layers of Google's data stack: collection, reporting, and storage & custom analysis. FBA and GA are quite similar in terms of what they look like: both show dashboards that are easy to explore, providing graphs and charts. We could say that FBA are a lightweight version of GA. For example, FBA Events look the same as GA Engagement>Events and both are clickable, but only GA allows reports and dashboards to be customized. On the other hand, BigQuery is simply a database without any straightforward UI and its contents need to be processed via an SQL query to reach some analytical results, which in turn need to be visualised in another tool (e.g., manually in spreadsheets or automatically in a connected tool such as Looker etc.).

One thing that is extra in FBA is Observability, a report on how the apps are doing in regard to app crashes and release version adoption. Here is a quick comparison of the services:

Feature / Tool	Firebase Analytics (GA for Firebase)	Google Analytics 4 (GA4)	Google BigQuery
Primary role	App tracking SDK & developer-focused console	Cross-platform marketing & behavioral reporting suite	Enterprise cloud data warehouse & SQL analytics engine
Primary audience	App developers, technical product managers	Growth marketers, business analysts, UI/UX researchers	Data engineers, data scientists, advanced BI analysts
Scope	Mobile and web apps	Unified web + Mobile	Any data (GA4/Firebase logs, CRM, backend databases, ads, ...)
Data nature	Pre-aggregated summaries, app crash correlations, simple event views	Modeled/sampled standard reports, attribution models, exploration funnels	Raw, unsampled, event-level tables
Query flexibility	Fixed dashboards, basic audience definitions	Drag-and-drop report builder, standard dimensions & metrics	Full SQL interface, ML queries, joins across third-party sources
Data retention	Tied to GA4 retention policies	2 to 14 months (for exploratory reporting)	Indefinite (controlled by user storage settings)

Data types in BigQuery

BigQuery is not a typical relational database. It's an OLAP database (Online Analytical Processing database). Data in it is stored in columns, so it can process millions of rows much faster than older-type OLTP databases (Online Transaction Processing databases). Nevertheless, it recognizes standard SQL schemas and syntax. One thing that is special in BigQuery are nested fields which are basically arrays. They need to be unnested when querying.

So the data types used are: string (a text), integer (whole number), boolean (true/false), float (and double – both are decimal numbers, just of different precision) and a special type called record, which is virtually an array of other fields. Usually, records consist of other string fields, but some that we are interested in most often contain key:value pairs:

• event_params (record)

  • key (string)
  • value (record)
    • string_value (string)
    • int_value (integer)
    • float_value (float)
    • double_value (float)

• user_properties (record)

  • key (string)
  • value (record)
    • string_value (string)
    • int_value (integer)
    • float_value (float)
    • double_value (float)
    • set_timestamp_micros (integer)

Note: in our BQ, we use double in one place only: in event save_transaction.amount values. This is the amount that the user entered in a transaction. ⚠️ Prices of products purchased by our users are reported in event in_app_purchase which is an automatically collected GA event. Its parameters price and value (value = price × quantity) are stored in micros, which is a millionth of a currency unit. This is done to prevent rounding errors, as an API standard of the Stores. To analyse that, you need to divide the raw value by 1,000,000. For example, is the value of the event is 3990000, the price was 3.99.

Naming convention for events

In the past, there was no naming convention for analytical events, so the current set is a mix of good and bad event names. Moreover, some events only come from one of the platforms, and their names were created by the respective developer, which adds to the confusion.

However, going forward, we should try to adapt the current set one step at a time. Some events need to be consolidated into one, with added parameters. Other need to be deleted and even more created, and implemented on all platforms where applicable.

The general rules for names of events, parameters and their values is as follows:

• they should be self-explanatory, i.e., they should be so easy to understand that one look is all you need
• the event name should describe a general activity, while the characteristics of such event should be tracked via parameters with string or numeric values. ⚠️ The parameters use snake case, while their string values use hyphens.
• generally speaking, the name should describe the app area + activity + target, however, in some cases it would feel forcible. For example, it makes no sense to name an event group_create when it sounds more natural to name it create_group.
• event names either
  • start with verbs in the infinitive (clone_group),
  • attach the verb in an infinitive or past participle form at the end (who_paid_clicked, premium_before_ad_open), or
  • suffix the activity with a word that describes the graphical or verbal target (premium_before_ad_pause – click on the pause icon; premium_before_ad_continue – click on the Continue button)
• "smaller" events (those that will not have many parameters and serve to catch some very specific user behaviour) do not need to be named strictly according to these rules, but it is a good idea to think about how the name fits in with the rest of the events
• events related to viewing and purchasing Premium start with premium_ (or premium_group_ if it's related to Group Premium only)
  • e.g., event name is premium_screen_open, and one of its parameters is screen_type which can be filled with single-plan value
• similar events should have similar names with a different suffix, e.g. gwallet_notification_receive and gwallet_notification_open

You will come across past and present mistakes (let's call them variations) where these rules are broken. It is what it is.

GA naming specifications

• event names are case sensitive (therefore, it is best to use only lowercase letters)
• do not use reserved prefixes and event names (consult this GA article)
• event names must start with a letter; numbers and underscores are allowed
• event and parameter names must be up to 40 characters long
• parameter values can be up to 100 characters long
• an event can have up to 25 parameters
• user property name can be up to 24 characters long and its values up to 36 (consult this GA article)
• generally, we should keep the total number of distinct events under 500, as that is the limit for one user per day (read more in this article)

The list of event names is held and updated in Event analytics spreadsheet, tabs event analysis, Premium events and new events.