Article

From Click to Insights – How to Build Analytics for Web Applications

Indigo fingerprint turning into layers of paper and a small bar chart
November 6, 2026
|
by Pawel Paplinski
Web Analytics
Google Tag Manager
Google Analytics 4
BigQuery
Data Studio
Indigo fingerprint turning into layers of paper and a small bar chart

Imagine Maya, a marketing manager planning a product launch with her team. She signs up for a work-planning app. It asks her to create a project, a shared space where the team can add tasks and see who’s doing what. She clicks ‘Create project’, gets an error and tries again. Two clicks later, she still has nowhere to put the work.

The product team wants to know how many new users create their first project within seven days of starting onboarding, the initial setup after sign-up. A count of button clicks would include both of Maya’s attempts. To answer the team’s question, the app needs to record when it actually creates a project.

Good analytics gives that information a clear route from the app to the people who need it. In Maya’s example, Google Tag Manager sends events from the app to Google Analytics 4 (GA4).

Analytics pipeline with separate GA4 and app database feeds into BigQuery
Analytics pipeline with separate GA4 and app database feeds into BigQuery

Once the connections and schedules are set up, the pipeline runs in the background. GA4 exports events to BigQuery automatically each day. A separate feed brings in the app’s user and project records. Data Studio reads the reporting table when it refreshes.

What counts as a first project?

The team needs two events. An event is a small record of something that happened. The app records onboarding_started when Maya first opens setup, which starts her seven-day window. It records project_created when it confirms that a new project exists. The team can also track attempts if it wants to see how often people need to try again.

This is what a tracking spec is for. In plain language, it says what happened, when the app should report it and what details are worth keeping. A designer can read the same definition as a developer. An analyst can look at it six months later and see why reopening onboarding didn’t restart the clock.

The app leaves each event in the data layer, a place on the page where Tag Manager can pick it up. When the app confirms a new project, the message might look like this.

1 2 3 4 5 6 window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'project_created', creation_source: 'onboarding', project_type: 'blank' });

There’s enough here to tell the team that someone created a blank project during onboarding. Personal details stay out. If a retry returns the same project, the app sends the event once. Its own records remain the source for how many projects actually exist.

What Tag Manager sends

Google Tag Manager handles delivery. Its rules tell it when to send an event, which details to include and where they should go. In this example, a rule called a trigger listens for project_created. The tag is what sends the event to GA4, along with the two details from the app’s message.

Tag Manager example mapping two data layer variables to project_created
Tag Manager example mapping two data layer variables to project_created

Figure 1. A sample Tag Manager tag maps creation_source and project_type from the data layer to project_created. The measurement ID is fictional.

What Google Analytics collects

Google Analytics is where the team can see how often events happen and which steps people reach. If the team wants to compare projects created during onboarding with those created elsewhere, it needs GA4 to show the ‘Creation source’ detail in reports. GA4 calls this an event-scoped custom dimension. That means the detail belongs to each individual project creation.

GA4 form for the event-scoped Creation source custom dimension
GA4 form for the event-scoped Creation source custom dimension

Figure 2. The Creation source custom dimension lets GA4 reports break down events by the creation_source parameter.

Maya’s retry gives the team a simple test. A failed save should send no project_created event, and a successful save should send one. Tag Manager’s preview mode turns on debugging for the test browser. Tag Assistant shows what Tag Manager did, and GA4’s DebugView shows which test events arrived.

Why bring in BigQuery?

GA4 may be enough if the team wants to see which steps people reach. The first-project question needs another source. The app’s own records can tell the team whether Maya has ever created a project before.

BigQuery is a data warehouse, a place to store and work with data from different sources. It brings together the GA4 events and the app’s user and project records. The team sets up GA4’s User-ID feature to receive an internal code for each account. That code lets it match starters to accounts, including people who never create a project. If Maya starts on Friday and creates her first project on Monday, she counts once, with Friday’s starters.

With daily export turned on, GA4 sends its events to BigQuery automatically. A separate feed brings in the app’s user and project records. A scheduled query uses SQL, a language for working with data, to update the table the dashboard reads. Other reports can use the same table and count a first project the same way.

Some events arrive late. The team gives each group a full seven days to finish and time for the data to arrive before comparing it with earlier groups.

What Data Studio shows

Data Studio, formerly Looker Studio, is the dashboard tool. When the report refreshes, it reads the reporting table in BigQuery and turns the results into charts people can share. For each week, the report shows how many people started, how many couldn’t be matched to a user account and how many of the matched users created a first project within seven days.

In the example below, 41% of matched users in the first group created a project within seven days, compared with 54% in the fourth group. Week 5 says ‘Pending’ because some people in that group still have time to finish.

Sample seven-day onboarding completion rates by start week
Sample seven-day onboarding completion rates by start week

Figure 3. An example onboarding dashboard adapted from a Data Studio report layout. All figures are fictional.

The team can follow a test like Maya’s from the app to the report. After launch, the last refresh time helps people see how recent the figures are.

When the app changes, the numbers can too

A month later, the team adds templates to the setup. Are more people creating a first project? The dashboard gives the team a way to compare the weeks before and after the change. A note about when the new screen went live helps everyone read the numbers in context.

What the team can now answer

Maya’s two clicks showed that she tried. The team can now tell whether she created a first project within seven days and count her with the people who started that same week. The app records the action, Tag Manager and GA4 carry and collect the event, BigQuery adds the app’s records, and Data Studio shows the result. If the team changes onboarding, it has a clear measure to come back to.

Sources

Marketing Team
September 8, 2026
AI Does More of the Work. Marketing Expertise Matters More Than Ever

AI can run complete marketing workflows, from approved source material to published content. Experts define the rules, check exceptions and improve the process. Newsletters, videos and case studies show what can run automatically and where human judg...

by Pawel Paplinski

From legacy AngularJS to modern React
July 26, 2026
From AngularJS to React: How We Rewrote the Squads App with AI

Squads rewrote its core web app from AngularJS to React using AI-assisted development. By freezing the API, writing a clear architecture rulebook and migrating feature by feature, one developer completed about one month of focused work while also ref...

by Dmytro Yevsieiev

Mechanism
March 15, 2026
What to Test (and What Not) for High Test Automation ROI

Most class-level, mock-heavy unit tests are fast but brittle and punish refactoring. A higher-ROI approach is boundary testing: verify behavior at module/API boundaries, mock only external systems, and track scenario coverage over line coverage - bui...

by Shrikant Vashishtha