GA4 Monitoring: What to Track and Why

Why GA4 Tags Break

GA4 is the most common analytics tag and the most common source of silent failures. The failure modes are specific: a developer changes the data layer schema without updating GTM, a consent management platform blocks the tag at page load, a GTM container publish introduces a trigger conflict, or Google's gtag.js library updates and breaks a custom event configuration.

GA4 does not tell you when events stop arriving. The Realtime report shows what is flowing in, but it does not compare against a baseline. If your purchase event drops from 200/day to 120/day, GA4 does not alert you. You find out when someone notices the revenue report looks wrong — days or weeks later.

The Five GA4 Events That Break Most Often

1. purchase

The highest-impact event. It depends on the data layer containing transaction_id, value, currency, and an items array. If any field is missing or malformed, the event fires but GA4 discards it server-side. Your GTM Preview shows the tag as fired. GA4 never records the transaction. Common cause: a checkout redesign changes the data layer push timing.

2. page_view

Fires on every page load. Seems simple. Breaks when: a single-page application (SPA) handles navigation via JavaScript and the page_view event only fires on the initial load, not on route changes. Also breaks when the gtag config fires before the consent management platform initializes, and gets blocked. Fire rate drops 30–60% and nobody notices because the GA4 session count is still “in the ballpark.”

3. add_to_cart

Depends on the product data layer push happening before the user navigates away from the product page. Race condition: the user clicks “Add to Cart” and the page navigates to the cart before the data layer push completes. The event fires with empty item data, or does not fire at all. Frequency: 5–15% of add-to-cart interactions, depending on site speed and implementation.

4. begin_checkout

Fires when the user starts the checkout flow. Breaks when the checkout is a separate domain or subdomain and cross-domain tracking fails. The client ID does not carry over, the session splits, and the begin_checkout event fires under a new session with no attribution history. The event technically works. The attribution data is garbage.

5. view_item

Fires on product detail pages. Breaks when the trigger is a DOM element that changes name or class during a site redesign. GTM trigger stops matching. The tag never fires. Nobody checks because view_item is a mid-funnel event that does not directly affect revenue reports.

What Success Rate Means

The TagDrishti dashboard shows a success rate percentage for each tag. For GA4 events, success means: the event fired in the browser, the outbound request to analytics.google.com was sent, and the endpoint returned a 2xx response. A 95% success rate means 5% of fires either failed to send the network request or received a non-success response.

What counts as a failure:

• Network block: Ad blocker or firewall dropped the request. The tag fired in GTM but the data never reached Google.
• Timeout: The request was sent but no response arrived within the timeout window (typically 5 seconds).
• Error response: The endpoint returned a 4xx or 5xx status. Rare for GA4 but happens during Google outages.
• Missing required fields: The event payload was incomplete. GA4 accepted the request but silently dropped the event during processing.

Reading the Tag Health Dashboard

Navigate to Tag Health in the TagDrishti dashboard. The GA4 section shows:

Events table: Each GA4 event name, its fire count (last 24 hours), success rate, and trend arrow. Click an event to see the per-page breakdown. If purchase fires 200 times on /checkout/confirmation but only 3 times on /checkout/complete, you have a page-specific issue.

Data completeness score: For each event, TagDrishti checks whether the required parameters are present and non-null. A purchase event with value: undefined gets flagged. The completeness score tells you what percentage of fires included all required fields.

Baseline comparison: After the 7-day calibration, the dashboard shows “expected vs. actual” for each event. If purchase events typically fire 180–220 times per day and today’s count is 90, the dashboard flags the deviation with an orange or red indicator.

Setting Anomaly Thresholds

Go to Settings → Alert Rules. For each GA4 event, you can set:

• Success rate floor: Alert when the success rate drops below this value. Recommended: 90% for page_view, 85% for purchase (some ad blocker loss is normal).
• Fire rate deviation: Alert when the fire count deviates from the rolling 7-day average by more than X%. Recommended: 25% for high-volume events, 40% for low-volume events.
• Data completeness floor: Alert when required parameters are missing in more than X% of fires. Recommended: 5% for purchase, 10% for other events.

Start with the defaults. Tighten thresholds after two weeks once the baseline stabilizes. Overly tight thresholds cause alert fatigue. Overly loose thresholds miss real incidents.

When an Alert Fires: First 5 Minutes

1. Open the alert: The Slack or email alert includes the tag name, event name, current success rate, expected rate, affected pages, and a direct link to the dashboard.
2. Check scope: Is this one page or all pages? One region or all regions? One browser or all browsers? The dashboard breakdown answers these questions in seconds.
3. Check timing: When did the drop start? Correlate with your last GTM publish, site deployment, or known vendor outage. The timeline chart shows the exact minute the failure began.
4. Check the error type: Network block, timeout, missing parameters, or error response. Each has a different fix path.
5. Act: If it is a GTM change, revert the container. If it is a vendor outage, check the vendor’s status page. If it is a data layer issue, involve the development team. See the Incident Response guide for the full triage playbook.

GA4 data loss is permanent. Google does not backfill missed events. Every hour a broken tag runs is an hour of data you will never recover.