GA4 Is 87% Migrated. GA4 Implementation Is Not.

According to data from Digital Applied's 2026 GA4 adoption study, 87% of websites have now migrated from Universal Analytics to GA4. The same study found that the average GA4 implementation uses 12 of the 40+ available event types. For SaaS teams, those two numbers together tell a specific story: migration happened, measurement depth did not. The checkbox got checked, but the analytical infrastructure that makes GA4 useful for product and growth decisions was left mostly unbuilt.

Migration and implementation are not the same thing

Universal Analytics to GA4 migration is a technical task: install the new tag, verify that sessions and page views are flowing, configure a few goals in the new interface. Almost every technical team can complete that in a sprint. GA4 implementation — building a measurement plan that covers your actual product funnel, instructs custom events, and creates the signals your growth team needs to make decisions — is a product discipline that takes months to do well and requires ongoing maintenance as the product changes.

The gap between those two things is where most SaaS teams are stuck. They have a GA4 property with clean pageview data, possibly some basic e-commerce events if they sell online, and not much else. Meanwhile, the questions that actually drive product and growth decisions — what percentage of trial users reach the activation event, which onboarding step has the highest drop-off, which features correlate with retention — cannot be answered from pageview data alone. The tools are in place. The instrumentation is not.

What the 40+ event types actually cover

GA4's event model is split into four tiers. Automatically collected events fire without any configuration: page_view, session_start, first_visit, user_engagement, scroll, click on external links, file downloads, and a handful of video interaction events if you use embedded YouTube. These account for virtually all the events in a shallow GA4 implementation — they are what you get for free, and they are sufficient for a content publisher but almost useless for a SaaS product.

The second tier is recommended events: a set of named events Google publishes for specific verticals. For software and apps these include sign_up, login, search, tutorial_begin, tutorial_complete, and select_content. These need to be implemented deliberately but follow a standard schema that allows GA4 to interpret them correctly in reports. Most SaaS teams implement sign_up, stop there, and call it done. The third tier is enhanced measurement — automatic tracking of form interactions, outbound links, and site search — which adds noise without adding the signal SaaS products need. The fourth tier is custom events: anything you name and fire yourself. This is where all of the analytically valuable SaaS measurement lives, and it is the tier where the implementation gap is widest.

The 12 events the average implementation actually uses

Based on typical shallow GA4 implementations, the 12 events that most SaaS GA4 properties actually contain look roughly like this: page_view, session_start, first_visit, user_engagement, click (on external links), scroll (90% threshold), file_download, sign_up, login, search, tutorial_begin, and purchase or begin_checkout. That list is not random — it represents the automatically collected set plus the one or two recommended events teams add during migration. It is not a useful measurement plan for a SaaS product. It tells you that users are visiting pages, signing up, and sometimes buying. It does not tell you what they do in between those moments, which is where activation and retention live.

The events systematically absent from shallow implementations are the ones that require someone on the product or engineering team to sit down and instrument them: onboarding steps, activation events, feature usage events, in-app navigation events, upgrade-intent events, and any event that happens server-side rather than in the browser. These are the events that answer "why did this cohort retain better than the last one" or "where do trial users drop off." Without them, GA4 is a web traffic tool, not a product analytics tool. See the three-layer SaaS event taxonomy for a framework to structure these custom events before instrumentation.

The events SaaS teams are systematically missing

The custom events that matter most for SaaS analytics cluster around three moments: the activation funnel, the core usage loop, and the conversion path. In the activation funnel, you need events that fire at each step of onboarding — not just tutorial_begin at the start, but each distinct step, plus the moment that represents genuine first value (your activation event). The activation event is product-specific: for a project management tool it might be first_project_created; for an analytics tool it might be first_dashboard_viewed; for a document editor it might be first_document_shared. GA4 has no way to know what your activation event is — you have to define and instrument it.

In the core usage loop, you need events that fire when users interact with the features that predict retention. These are not necessarily your most-used features — they are the features whose usage correlates with users who stay. Identifying those requires querying event data you have not yet collected, which is why this work compounds: teams that started instrumenting product events two years ago now have the historical depth to identify retention signals; teams that are still at 12 events do not. On the conversion path, you need events that fire when users visit billing pages, view upgrade prompts, or click on paid plan CTAs — not just the final purchase event. The upgrade intent signals that precede conversion are as analytically valuable as the conversion itself. The event setup discipline for investor metrics covers how to design these events so they remain queryable under scrutiny.

How to audit your GA4 event coverage

A practical coverage audit has three steps. First, open GA4 and pull the full event list from Engagement > Events, sorted by event count over the last 30 days. If page_view and session_start together represent more than 75% of total events, your implementation is shallow — all you are measuring is traffic. Second, write down the five questions your product and growth teams ask most frequently in planning meetings. Common examples: "what percentage of trial users reach the activation event," "which onboarding step has the most drop-off," "which features do users who upgrade in their first 30 days use in their first week." For each question, determine whether a GA4 event exists that could answer it. In a shallow implementation, the answer is usually no for all five.

Third, map the gaps to your activation funnel: list every distinct step between signup and your activation event, and confirm that each step fires a GA4 event. For most SaaS products, the funnel has four to eight discrete steps — email verification, onboarding questionnaire, first setup action, first invite, first core action, activation event. If you have sign_up and tutorial_begin but nothing in between, you are blind to where users are dropping off in the steps that matter most. The GA4 traffic undercounting post covers related blind spots in acquisition measurement; the event coverage problem is its product-side equivalent.

A prioritization framework for deepening implementation

Teams that try to go from 12 events to 50 events in one sprint usually end up with poorly named, inconsistently fired events that create more confusion than insight. The right approach is sequential depth: add the five events that answer your highest-priority questions, query them consistently for 60 days, then add the next five. This approach builds measurement habits alongside the instrumentation and ensures that every event has a defined purpose before it goes into production.

Priority order for most SaaS products: activation event first (the single most important measurement for a SaaS product), then onboarding step events (to understand drop-off before activation), then core feature usage events (two or three that define active usage), then conversion-path events (upgrade intent and plan selection), then retention-signal events (anything correlated with users who stay past day 30). Each tier answers a specific class of questions and depends on the previous tier being clean before the next layer adds complexity. The analytics stack guide by ARR stage gives a complementary view of when each tier of investment is justified based on where your company is in its growth trajectory.

The compounding cost of shallow implementation

Every month of shallow GA4 implementation is a month of historical data you cannot query retroactively. GA4 does not backfill — events that were not fired cannot be reconstructed from pageview data, and user-level funnels cannot be built from traffic data. The SaaS team that instruments their activation event in July 2026 will have their first meaningful cohort retention analysis available in October 2026. The team that waits until October will be looking at their first cohort in January 2027. The cost of delay is not one quarter of insight — it is one quarter of insight plus the inability to answer any historical question that depends on the missing events.

The 87% migration statistic measures completion of a technical task. The 12-event average measures the depth of a measurement investment. Those two numbers are not moving at the same rate because migration is a one-time event and measurement depth is a continuous practice. Teams that close the gap between them now are building the analytical foundation that separates data-informed product decisions from decisions made in the dark. Migration happened. Implementation is the work that remains.