Infoplaza is the weather company behind Buienalarm and Weeronline, apps and websites a large part of the Netherlands opens every day. When it rains, traffic multiplies. On a peak day the Buienalarm apps and sites alone send around 125 million events.
At that volume, standard tooling runs out. A standard GA4 property exports at most one million events a day to BigQuery, and the GA4 interface starts sampling and thresholding data. For a company that earns its money with advertising and subscriptions, that is more than a reporting problem: audiences, A/B tests and product decisions all depend on knowing how people use each app and site.
The question was how to measure web and app the same way at this scale, keep visitors recognisable in Safari, and get every event into BigQuery where those teams can use it.
We worked as one team with Infoplaza and our partner Insight First. Infoplaza's developers built the dataLayer and the routing on their own domains, Insight First owns the reporting and dashboards, and we designed the measurement and built the server side.
We started by talking to every team that uses the data. We turned their goals into KPIs, the KPIs into events and parameters, and wrote it all down in one measurement plan for web and app. Every team reviewed the plan before anything was built.
For the web developers we wrote an implementation guide with dataLayer snippets per event, and for the app developers the same for Firebase on iOS and Android. We tested the events on both before they went live.
Server-side tracking runs in Infoplaza's own Google Cloud project: GTM server containers on Cloud Run behind a Google load balancer. We chose a same-origin setup, so tracking runs through a folder on the site itself (buienalarm.nl/data) instead of a tracking subdomain. The site's own server sets the cookies, so Safari keeps them for 400 days instead of seven, and ad blockers have a much harder time telling tracking apart from the site. The apps send their data to the same server.
Along the way we cleaned up the GTM containers: triggers that caught far too much, internal events that ended up in GA4, and tags firing where they shouldn't.
Last, we built a custom server-side GTM tag that writes every event straight into BigQuery, following the schema of GA4's own export. It works in real time, has no daily limit, and queries written for the GA4 export carry over with little change. Every Monday an automated check reports event volumes per site and app, so a release that breaks tracking is noticed within days, not at the end of the month.
Infoplaza now has one dataset for its websites and apps that every team works from. Events land in Infoplaza's own BigQuery in real time and unsampled, and Insight First builds the dashboards on that data rather than on the GA4 interface.
That data is the basis for Infoplaza's next step: a customer data platform where audiences for advertising, A/B tests and the timing of in-app messages are built. Because Buienalarm recognises returning Safari visitors for 400 days instead of seven, those audiences are built on real users rather than on a new ID every week.
The setup has already paid for its attention to detail: the data showed that a large part of the traffic on one of the radar sites came from bots, which would otherwise have inflated user counts. We continue to work with Infoplaza and Insight First on the setup.
Running into the same thing?
We love the work others find too technical. A trigger from 2019 that skews your revenue? We'll find it. And we'll explain it to you without the jargon.
