GA4's model — events, parameters, and the hits you can see

Universal Analytics had pageviews, events (category/action/label), transactions, and timing hits — different shapes for different things. GA4 threw all that out. In GA4 there is exactly one shape:

An event with a name, and parameters attached to it.

A page load is an event called page_view. A purchase is an event called purchase with parameters transaction_id, value, currency, items. A scroll is scroll. Your custom "video played 50%" is whatever you name it, with whatever parameters you attach. Sessions, users, and conversions are all derived from the stream of events — there is no "session hit."

This is why the dataLayer contract in the last lesson matters so much: the parameter names you push are, with the ecommerce checkbox, the parameter names GA4 receives.

Automatic, enhanced, recommended, custom

GA4 events come in four tiers, and knowing which tier you're in tells you what you need to build:

• Automatically collected — page_view, first_visit, session_start, user_engagement. The Google tag sends these with no work from you.
• Enhanced measurement — scroll, click (outbound), file_download, video_start, view_search_results, form_start/form_submit. Toggles in the GA4 data stream settings, not in GTM. Convenient, but their triggers are Google's, not yours — you can't see or tune them.
• Recommended — the ecommerce set (view_item, add_to_cart, purchase…), login, sign_up, generate_lead. You send them; GA4 reserves the names and builds reports around them. Use the exact names and parameters.
• Custom — anything else. Fine, but parameters on custom events don't show in standard reports until you register them as custom dimensions.

The single most common mistake here: sending Purchase (capital P) or add-to-cart (hyphen). GA4 will accept it as a custom event and none of the ecommerce reports will populate. Names are case-sensitive and snake_case.

Reading a hit

Here is a GA4 request as it appears in the network tab, filtered for collect:

POST https://www.google-analytics.com/g/collect?v=2&tid=G-ABC123XYZ&cid=1717.239&en=add_to_cart&ep.currency=USD&epn.value=24&gcs=G111&dl=https%3A%2F%2Fshop.example.com%2Ftote

Learn to read six parameters and you can debug 90% of GA4 problems without opening a report:

Ecommerce items don't appear as query parameters; on a modern Google tag they travel in the POST body as pr1, pr2… entries. Click the request, open Payload, and you'll see them.

The two GA4 debugging views

• DebugView (Admin → DebugView) shows events arriving in near-real time for devices in debug mode — GTM Preview turns debug mode on automatically. It's the receiving-end confirmation that the request in your network tab was accepted and parsed.
• Realtime shows the last 30 minutes for everyone. Good for "is anything arriving at all," bad for finding your own test hit among real traffic.

The tell

When two of these views disagree, the gap is where the bug is:

• Preview says the tag fired; no collect request in the network tab → something blocked it (consent state, ad blocker, a JS error earlier on the page).
• Request in the network tab; nothing in DebugView → wrong tid, or the property has a data filter / internal-traffic rule excluding you.
• Request present, DebugView shows it, but the report is wrong → the parameter values were wrong at collection. Go read the dataLayer push.

That's the whole diagnostic flow. Module 2 makes you do it by hand until it's reflex.