GA4 Foundation Readiness Review

A property is not ready just because it is connected

Most teams connect GA4 and assume the data is trustworthy. The stream fires. Events appear. Reports load. But a connected property is not the same as a configured one. GA4 replaced Universal Analytics with an event-based model where every interaction is recorded differently. The session logic changed. The user definitions changed. The default data retention dropped to two months, per Google's own settings.

The GA4 Foundation Readiness Review checks whether the property scope, reporting identity, event layer, and ownership are solid enough to support a growth recommendation. If the property is pulling data from the wrong stream, or the reporting identity is set to blended when the team expects device-only, every number downstream inherits that gap.

• Confirm the property ID, stream URL, and account structure match the site or app the team intends to measure
• Check data retention under Admin settings. The default is two months. Set it to fourteen if historical comparison matters

If two people count differently, the definition is broken

GA4 defines a session as a group of interactions within a thirty-minute window. An engaged session needs ten seconds, a key event, or two pageviews. An active user is someone with an engaged session. These definitions sound technical, but they change what every report shows. A team that expects sessions to match Universal Analytics numbers will conclude the data is wrong when it is simply defined differently.

The reviewer should document which definitions the recommendation depends on. If the recommendation uses active users, confirm the team understands the engaged-session threshold. If it uses sessions, confirm the timeout setting. If the reporting identity is blended, confirm the team knows it includes modeled data. A shared definition is the difference between confidence and confusion.

• Write the user definition, session definition, and reporting identity setting in the readiness memo before any recommendation
• If team members interpret a metric differently, hold the recommendation until the definition is agreed and documented

Not every event is a decision event

GA4 collects four types of events. Automatically collected events fire without configuration. Enhanced measurement events track scrolls, clicks, and video engagement with a toggle. Recommended events follow Google's naming conventions for specific industries. Custom events are defined by the team. Together they create a stream of data that looks complete but often mixes what matters with what is just noise.

The reviewer should separate events by role. Which events are diagnostic, showing that tracking is working. Which events are decision-driving, tied to a business outcome the team cares about. Which events are conversions, marked as key events. A recommendation based on page_view data carries different weight than one based on a purchase event with a validated transaction ID. The event category matters.

• Label every event referenced in the recommendation as diagnostic, decision-driving, or conversion
• Verify that conversion events are not double-counting. A purchase that fires twice inflates revenue by a hundred percent

Fresh data beats old data every time

GA4 reports can show real-time data, snapshot data from yesterday, or trend data from the last quarter. The freshness requirement depends on the decision. A recommendation about today's campaign performance needs real-time or same-day data. A recommendation about quarterly channel trends can use the standard reporting view. The mistake is using stale data for a fast decision or real-time data for a long-term trend.

The reviewer should check the freshness of every report surface the recommendation uses. If the real-time report shows a spike but the standard report does not yet reflect it, the data is not ready. If a dashboard is pulling from a Looker Studio connector that refreshes every twelve hours, the data may be hours behind the decision window. Freshness is a dimension of confidence, not a checkbox.

• Note the last refresh time on every report used in the recommendation
• If the decision window is shorter than the data refresh cycle, hold the recommendation until fresh data is available

A gap in the data is not a reason to guess

Every GA4 property has gaps. A consent banner blocks tracking for some users. An ad blocker strips the GA4 tag entirely. A cross-domain setup was never configured, so traffic between the main site and the checkout subdomain appears as two different users. A Measurement Protocol integration sends server-side events that do not join with client-side sessions, creating attribution holes. These gaps are normal. They become dangerous when the recommendation ignores them.

The reviewer should list the known gaps before interpreting the data. If consent-related data loss is estimated at twenty percent, the recommendation should acknowledge that the numbers are undercounted by roughly that margin. If cross-domain tracking is missing, session-based metrics are inflated and user counts are duplicated. The gap does not invalidate the recommendation. But hiding the gap makes the recommendation look more certain than it is.

• Document known tracking gaps in the readiness memo: consent loss, ad blockers, cross-domain issues, sampling
• If a gap could change the direction of the recommendation, hold until the gap is closed or the caveat is explicitly accepted

Sample Review Note

The reviewer confirms the GA4 property scope, stream configuration, and data retention settings match the decision needs. User and session definitions are documented and shared. Events are classified by role. The reporting identity is noted. Every report surface used in the recommendation has a freshness timestamp and a known gap list.

If the property configuration, event setup, or reporting identity changes after this review, the recommendation is gated for recheck. The owner is assigned. The re-evaluation date is set. The GA4 foundation is ready, and the discipline that keeps it ready is the team's.