Data & analytics
Analytics work starts with deciding what a meaningful action is, not with pasting a tag. We design the event model, implement it in GA4 and Firebase Analytics, verify every event against the product that emits it, and land the raw data in BigQuery where it can be modelled and questioned.
- GA4 · Firebase Analytics
- BigQuery export
- Event modelling
- Consent & minimisation
GROW
Data, measurement & growth
The layer that keeps the other two honest. Event models, conversion tracking and attribution that make performance legible, and continuous optimisation of the product and the spend together rather than one at a time.
Also in this band
Analytics is a design problem before it is an implementation problem. The question is not which tag manager to use; it is what a meaningful action in your product is called, when it fires, what it carries with it, and who will read it afterwards. Get that wrong and every number downstream inherits the mistake, including the conversion signals your ad platforms bid against. We start at the definition and work outwards from there.
The work spans three layers that are usually owned by different people and therefore usually disagree. Collection is what the app or site sends: GA4, Firebase Analytics, server-side events, purchase and subscription state. Storage is where that lands untouched, which for most clients means BigQuery. Reporting is the modelled layer on top, where events become funnels, cohorts and revenue. We build all three so a number on a dashboard can be traced back to the row that produced it.
We are also frank about the limits. Some questions cannot be answered with the data you have, some need a change in the product rather than in the pipeline, and some are answerable only once enough time has passed. Consent choices, platform privacy changes and cross-device behaviour all remove information permanently. We would rather tell you a report is not yet reliable than hand you a confident chart built on too little data.
Why this comes up
Analytics work rarely begins with enthusiasm for analytics. It begins when a decision has to be made and nobody in the room can agree on which number is real.
- Two dashboards, two different numbers
- The ad platform reports one conversion count, GA4 reports another and the finance export reports a third. Usually all three are technically correct and measuring different things: different attribution windows, different definitions of a purchase, different treatment of refunds. Without a written definition of each one, the meeting becomes an argument about tooling instead of a decision about spend.
- Nobody trusts the conversion count
- Events were added over time by different hands, some through a tag manager, some in code, some duplicated across both. Names drifted, parameters were renamed, and a release changed a screen while the event kept firing on the old flow. The count still moves, so nothing looks broken, but nobody can say what it actually counts any more.
- Reporting stops at the install
- You know acquisition cost and you know install volume. What happens afterwards is invisible: which cohorts activated, which came back the following week, which ever paid, and which source brought the users who did. Optimisation then runs on the cheapest available event rather than the valuable one, and budget quietly concentrates on traffic that never becomes revenue.
- A consent change broke the data
- A banner went live, a platform changed its identifiers, or an app update shipped with tracking permission handled differently. Volumes dropped overnight and nobody can separate a real decline from a collection failure. Because there was no baseline of what should be arriving, the honest answer is that the period is unreadable. Monitoring the pipeline itself is what keeps that difference readable while the decision still depends on it.
What we build
Scope varies. Some engagements are a single audit and a rebuilt event model; others run for the life of the product, with the pipeline and the reporting maintained alongside it.
Event model and measurement plan
Before anything is implemented we write the model down: every event, its name, its parameters, the value it carries and the question it exists to answer. Events that answer no question do not get built. The document is plain enough for a marketer to read and precise enough for a developer to implement.
- A naming convention applied consistently across web and app
- Parameter and value definitions, including currency handling
- Conversion and key-event selection, with the reasoning recorded
- User and session property design, including consent state
- One named owner per event, so drift gets noticed
- An explicit list of what we deliberately do not collect
GA4 and Firebase Analytics implementation
Events are implemented in the product rather than bolted on through a tag manager wherever they depend on application state. Web goes through Google Tag Manager, or direct gtag where that is cleaner; apps use the Firebase Analytics SDK. Purchases and refunds are sent server-side when the client cannot be trusted to report them.
- GA4 property and data stream configuration, built fresh or repaired
- Firebase Analytics on Android and iOS, wired to the same model
- Google Tag Manager containers with versioning and documented triggers
- Measurement Protocol events for purchases, refunds and back-office state
- Consent Mode configured to match the banner you actually run
- Cross-domain and app-to-web linkage where a journey spans both
Verification before anyone reports on it
An implemented event is not a working event. Each one is watched in DebugView and the realtime stream, on a real device and a real browser, in the states the product will genuinely be in. We check that it fires once, carries the right parameters, and stays silent on the flows it should ignore.
- DebugView and realtime verification per event, per platform
- Duplicate and double-fire checks across tag manager and code paths
- Value, currency and refund handling checked against real orders
- Internal traffic and test devices excluded, and the exclusion documented
- A verification sheet signed off and handed over with the work
BigQuery export and modelling
The GA4 and Firebase exports land raw in BigQuery, which is where the interesting questions get answered. From there we build modelled tables: sessions, funnels, cohorts, retention and revenue, defined once in SQL so every report reads the same definition instead of each dashboard inventing its own.
- GA4 and Firebase BigQuery exports configured, backfilled where allowed
- Staging and modelled layers driven by scheduled queries
- Cohort, funnel and retention tables defined once and reused
- Revenue joined in from your own database or billing system
- Cost control through partitioning, clustering and query review
Reporting and dashboard architecture
Dashboards are designed around the decisions they support. A weekly spend review needs different surfaces from a product retention review, and both are better than one dashboard trying to serve everyone. We prefer few charts that get read to many that get ignored, and we write what each number means beside it.
- Looker Studio or an in-house dashboard built on modelled tables
- Metric definitions written next to the metric, not in a separate file
- Segments for platform, geography, source and cohort
- Alerting on collection gaps, not only on performance dips
- Scheduled exports for the people who will only ever read email
Consent, minimisation and data handling
We collect what the reporting needs and nothing beyond it. Personal data stays out of analytics parameters, identifiers are handled deliberately, and retention settings are chosen rather than left at whatever the default was. Where a consent banner exists, analytics behaviour is matched to it and tested in both states.
- Consent Mode and banner behaviour tested granted and denied
- No personally identifying values inside event parameters
- Retention windows and deletion requests handled explicitly
- Access separated between the raw warehouse and the reporting layer
How the work runs
The sequence matters more than the tooling. Each stage exists to stop a specific kind of error reaching the stage after it.
- 01
Read what is already there
We start with the existing property, container, app build and ad accounts. That means listing every event currently firing, finding the duplicates, identifying which conversions the platforms are actually bidding on, and separating what is broken from what is merely undocumented. The audit is written down, including the parts that turn out to be fine.
- 02
Agree the model in writing
The event model is drafted, reviewed with whoever will use the numbers, and only then handed to implementation. This is where disagreements surface cheaply: what counts as an activation, whether a trial is a conversion, how refunds are treated. Settling those in a document is a conversation. Settling them after implementation is a rebuild.
- 03
Implement, then verify each event
Events are implemented alongside the feature or release they belong to, and verified individually before any reporting is built on them. Nothing enters a dashboard until it has been seen firing correctly on a real device or browser, with its parameters intact and its duplicates removed.
- 04
Land the raw data and model it
Exports are enabled, history is backfilled where the platform allows it, and modelled tables are built in SQL. Definitions live in the warehouse under version control, so a change to what a cohort means changes everywhere at once rather than in one dashboard somebody forgot about.
- 05
Report, review and retire
Reporting goes live with a review cadence attached. Each cycle we check collection health as well as performance, retire charts nobody opens, and record which questions the data still cannot answer. Measurement that is not maintained decays quietly, usually at the next product release.
From a tap in the product to a decision about budget
The distance between an interaction and a budget decision is longer than it looks. Every stage below is a place where the number can quietly become wrong.
- 01
Event definition
Someone decides this tap matters, gives it a name, and states what it carries: item, value, currency, screen, user state. The decision is recorded before code is written, so a developer implements a specification rather than a guess.
- 02
Client implementation
The event is added in the app or on the site, next to the code that owns the state it describes. Where the client cannot be trusted with a purchase or a refund, the server sends it instead through the Measurement Protocol.
- 03
Verification
The event is watched firing on a real device and a real browser, in both the granted and denied consent states. Parameters, duplicates and the flows it should ignore are all checked, and the result is written down against the model.
- 04
Warehouse
GA4 and Firebase export raw event rows into BigQuery on the schedule those platforms provide, alongside revenue drawn from your own database. Nothing is aggregated yet. The raw layer is what lets you re-answer a question later without having to re-collect the data.
- 05
Modelling
SQL turns event rows into the things people actually ask about: funnels, cohorts, retention curves, revenue by acquisition source. Each definition exists once and is reused, so two reports cannot disagree about what a converted user is.
- 06
Decision
A reviewer looks at cohort quality rather than raw volume, compares platform reporting against warehouse numbers, and moves budget or changes an onboarding step based on what the evidence supports. What remains unknown is stated too.
Two ways to end up with analytics
Bolted on afterwards
- Tags added under deadline pressure, by whoever happened to be free
- Event names describe the button, not the business meaning
- Purchases fire from the client and inflate on retries
- Definitions live in people's heads and shift with the reader
- Each product release silently breaks something nobody notices
Designed with the feature
- Measurement is part of the scope, agreed before the build starts
- Names come from the business model and survive a redesign
- Revenue events are confirmed server-side against real orders
- Definitions live in SQL, version controlled and reused everywhere
- Collection health is monitored, so breakage arrives as an alert
What attribution can and cannot tell you
Attribution is an estimate presented as a number. Platform reports include modelled conversions, count inside their own windows and credit themselves generously. Consent choices and privacy changes remove data permanently, so some journeys are never observed. A user who sees an ad on a phone and buys on a laptop can look like two unrelated people. Your warehouse and the ad platform will disagree, and both can be right. We use platform numbers to steer bidding and our own numbers to decide what is true.
Tools we work with
These are product and platform names used descriptively, to state what we work with. They imply no partnership, certification, endorsement or affiliation of any kind, and no relationship with the organisations that own them.
- Collection
- Google Analytics 4
- Firebase Analytics
- Google Tag Manager
- gtag.js
- Measurement Protocol
- Consent Mode
- Google Play Billing
- App Store Server Notifications
- Warehouse and pipeline
- BigQuery
- GA4 BigQuery export
- Firebase BigQuery export
- Scheduled queries
- Cloud Functions
- Cloud Scheduler
- PostgreSQL
- dbt
- Reporting
- Looker Studio
- SQL
- Next.js dashboards
- Metabase
- Google Sheets
- Verification and governance
- GA4 DebugView
- Firebase DebugView
- Tag Assistant
- Charles Proxy
- Android Studio Logcat
- Git for query version control
What you end up with
- A written event model that developers and marketers both read
- Events verified on real devices before anything reports on them
- Raw event data in your own BigQuery project, under your billing
- Funnels, cohorts and revenue defined once and reused by every report
- A plain account of which questions your data still cannot answer
What people ask before starting
01We already have GA4 installed. Do we need this?
Often what exists is a default installation plus a few tags, which reports pageviews and sessions accurately and very little else. The useful test is whether you can answer, from your own data, which acquisition source produced the users who paid. If not, the install is present but the measurement is not. We usually begin with an audit and tell you plainly how much is salvageable.
02Who owns the data and the accounts?
You do. Properties, tag manager containers, the BigQuery project and its billing sit under your organisation, and we work inside them with access you grant and can revoke. SQL for the modelled tables is delivered into your repository. If the engagement ends, the property, the warehouse and the queries stay exactly where they are; there is nothing to migrate away from us.
03What actually drives the cost?
Three things. The number of distinct events and platforms, because each one is implemented and verified separately. The state of what already exists, since repairing a drifted implementation can take longer than starting clean. And whether revenue lives somewhere that needs joining, such as a billing system or your own database. BigQuery storage and query costs are billed to you directly by the platform, and we shape the model with those costs in view rather than discovering them later.
04Why do your numbers disagree with Google Ads?
They always will, and anyone who tells you otherwise is not measuring carefully. The platform counts inside its own attribution window, includes modelled conversions, and credits itself for journeys it only partly observed. Your warehouse counts what happened in the product. We keep both, reconcile the gap in writing, and use each for the job it is honestly good at.
05What if the data shows the product is the problem, not the campaign?
Then we say so. It is a common finding and an uncomfortable one, because it usually means engineering work rather than a bid adjustment. A funnel that loses people at a slow API call or a failed payment will not be rescued by better targeting. We would rather report the constraint accurately than keep the reporting flattering.
06What will you not do?
We will not push personal data into analytics parameters to make a report easier to build. We will not fire conversion events that do not correspond to something real in the product, however much better the ad account would look. We will not present modelled or thin data as certainty. And we will not build a dashboard nobody has agreed to read.
What this work usually connects to
Start with a measurement audit
Send us the property, the app and whatever reporting you currently distrust. We will tell you what is genuinely being collected, what is broken, and what it would take to answer the questions you care about.
Directcontact@mnfinfotech.com