Event tracking reference: events, properties, and taxonomy

page_view is the event fired when a page loads. It is the base of almost every web-analytics model: sessions, pageviews, and most reports build on it. In classic sites the tracker fires it automatically on load; in single-page apps you fire it on each route change. Its properties (path, title, referrer) drive most downstream reports.

Custom events capture meaningful actions a pageview cannot — a CTA click, a signup, a video play, a form submit. The value is in a consistent naming taxonomy and well-chosen properties. The risk is putting personal data into event names or properties, which turns analytics into surveillance. This page covers both.

A click event records that a visitor activated a link or element. The most common analytics use is the outbound click — a click on a link leaving your domain — which a normal page_view can never capture because the destination is another site. This page covers what to record on a click, how outbound detection works, and which properties stay privacy-safe.

A form_submit event records that a visitor submitted a form — a signup, contact, or checkout form. It is one of the highest-value events because it usually maps to an intent or conversion. The hard rule is that the submitted field values (name, email, message) must never enter analytics: you record that a form was sent and which one, not what was typed.

The purchase event records a completed transaction and anchors all e-commerce reporting: revenue, items, and conversion value. It carries a transaction id, a value and currency, and an items array describing what was bought. The discipline is to record the order, not the customer — product and revenue data belong in the event, personal identity does not.

The session_start event marks the beginning of a visit. In GA4 it is fired automatically the first time a user is active in a new session, and it underpins every session-scoped metric. Understanding when a session begins — and the timeout that ends it — explains why session counts behave the way they do across midnight, campaigns, and idle periods.

Enhanced measurement is a GA4 setting that automatically collects a set of interaction events — scrolls, outbound clicks, site search, video engagement, file downloads, and form interactions — without extra code. It is convenient but not magic: it only covers standard patterns, can over- or under-count, and each option can be toggled. This page explains what it does and its limits.

Server-side event tracking sends events from your own server (or a server-side tag container) to the analytics backend, instead of firing them directly from the visitor's browser. It can improve data control, resilience to ad-blockers, and where data is processed — but it does not remove consent obligations and can hide client context. This page covers the model and the trade-offs.

A scroll event records that a visitor scrolled to a depth on the page. In GA4 enhanced measurement, a single scroll event fires once per page when the visitor reaches 90% of the page height. It is a coarse engagement signal — useful for spotting content people do not reach, but limited because the default is one threshold, not a continuous read-depth curve.

E-commerce events are a recommended set that model the shopping funnel before and around purchase: view_item, add_to_cart, begin_checkout, add_payment_info, and purchase. Each shares a common items array, so the same product schema flows through the journey. Implemented consistently, they let you see where buyers drop off — and they carry product data, never buyer identity.

The first_visit event is fired the first time a user opens your site in a browser. It is how GA4 distinguishes new users from returning ones: the presence of a first_visit defines a new user. Because it depends on a stored marker, clearing cookies or using a fresh browser makes the same person look new — a limitation worth understanding before trusting new-user counts.

Video engagement events record interaction with embedded video: video_start, video_progress (at 10/25/50/75% milestones), and video_complete. GA4's enhanced measurement captures these for supported embeds automatically. They turn an opaque 'a video exists' into a watch-depth signal — and because progress is milestone-based, you can see where viewers drop off rather than only that they pressed play.

A file_download event records that a visitor clicked a link to a downloadable file — a PDF, document, archive, or media file. Like outbound clicks, downloads escape ordinary page analytics because no new page loads. GA4 enhanced measurement fires file_download automatically for a defined list of file extensions, capturing the link and file type without code.

The site_search event (view_search_results in GA4) records that a visitor searched within your site. It is a direct window into intent — the words people type tell you what they expect to find. But search terms can contain personal data, so this is also one of the most sensitive events: you record that a search happened and, carefully, the term, with the privacy caveats front of mind.

Engagement time measures how long a page was actually in the foreground and active, recorded through GA4's user_engagement event. It replaces the old, unreliable time-on-page that could not measure the last page of a visit. By only counting time when the tab is visible and focused, engagement time is a more honest attention signal — though still not a guarantee that anyone read anything.

The Measurement Protocol is an HTTP interface for sending analytics events directly to the backend, without a browser tag. It is what makes server-side, offline, and backend events possible: a server, a kiosk, or a CRM can post events as JSON. With that power comes responsibility — events must be well-formed and de-duplicated, and identity and consent rules still apply on the server.

Event parameters are the key-value details attached to an event: which button, which product, which step. They are what turns a bare event name into something analysable. The craft is choosing a small, stable set of parameters with consistent names and values — and the discipline is keeping every one of them free of personal data, because parameters are stored and widely visible in tooling.

User properties are attributes that describe a user across all their events — a plan tier, a preferred language, a logged-in state — rather than a single action. They differ from event parameters, which describe one event. Used well, user properties let you segment behaviour by audience. Used badly, they become a place where people stash personal data, which is exactly what they must not hold.

An event naming convention is the agreed rule for what events are called: the case, the separators, and the vocabulary. It sounds trivial but it is the difference between clean analytics and a fragmented mess where signup, sign_up, and SignUp count as three things. This page covers the conventions that work, reserved names to avoid, and why a documented taxonomy matters more than any single rule.

A conversion event is an ordinary event you have marked as important — a purchase, a signup, a qualified lead. GA4 now calls these 'key events'. Nothing about the event changes; marking it tells the platform to count it as a conversion and build conversion reports around it. The decisions that matter are which events to mark, and whether to count once per session or every time.

The data layer is a JavaScript object (commonly the dataLayer array used by Google Tag Manager) that holds structured information about the page and user actions in one place. Tags read from it instead of scraping the DOM. It decouples what the site knows from how tags consume it — a cleaner, more maintainable model — provided you never push personal data into it.

An exception event records that a client-side error occurred — a JavaScript error or a failed operation. GA4 supports an exception event for this. Tracking errors in analytics ties reliability to behaviour: you can see which pages throw and whether errors correlate with drop-off. The catch is that error messages and stack traces can leak personal data, so what you capture needs care.

An outbound click event fires when a visitor clicks a link that leads to a different domain than the current site. GA4 records it as a click event with an outbound parameter when enhanced measurement is on. It tells you where your pages send people — partners, references, social profiles — which is useful for understanding exit paths but says nothing about what happens on the destination.

view_item is a GA4 recommended e-commerce event that fires when a visitor views a product's detail page. It carries an items array describing the product (id, name, price) plus currency and value. It sits early in the purchase funnel — between browsing a list and adding to cart — and is the foundation for product-level engagement and conversion analysis.

view_item_list is a GA4 recommended e-commerce event that fires when a visitor sees a list of products — a category page, search results, or a recommendation row. It carries an items array plus item_list_id and item_list_name so you can attribute impressions to a specific list. It measures product exposure: which lists put which items in front of people.

select_item is a GA4 recommended e-commerce event that fires when a visitor clicks a product inside a list — selecting an item from a category grid, search results, or carousel. It carries the item plus the item_list_id and item_list_name it was chosen from. Paired with view_item_list, it turns impressions into click-through, showing which merchandising surfaces actually drive product views.

add_to_cart is a GA4 recommended e-commerce event that fires when a visitor adds a product to the cart. It carries the items added plus currency and value. It is a strong mid-funnel intent signal — stronger than a product view — and the denominator for cart-to-checkout and cart-to-purchase analysis.

add_to_wishlist is a GA4 recommended e-commerce event that fires when a visitor saves a product to a wishlist or favourites. It carries the items saved plus currency and value. It signals interest without immediate purchase intent — a softer signal than add_to_cart — useful for understanding consideration and for products people return to buy later.

begin_checkout is a GA4 recommended e-commerce event that fires when a visitor starts checkout. It carries the items in the order plus currency, value, and an optional coupon. It marks the transition from cart to purchase flow and is the entry point for measuring checkout abandonment — the gap between starting checkout and completing a purchase.

add_payment_info is a GA4 recommended e-commerce event that fires when a visitor submits payment information during checkout. It carries the order items, currency, value, and a payment_type label (such as the card brand or wallet). It is a late-funnel step, just before purchase, and one where privacy discipline matters most: it must record that payment was entered, never the payment details themselves.

add_shipping_info is a GA4 recommended e-commerce event that fires when a visitor provides shipping information during checkout. It carries the order items, currency, value, and a shipping_tier label such as 'Ground' or 'Express'. It is a mid-to-late checkout step, often where unexpected shipping costs cause abandonment, and like all checkout events it must avoid recording the address itself.

refund is a GA4 recommended e-commerce event that records a refund against a prior transaction. It references the original transaction_id and carries the refunded value (and items, for partial refunds). It matters because reported revenue is misleading if refunds are not subtracted — refund events let analytics reflect net revenue rather than gross.

generate_lead is a GA4 recommended event that fires when a visitor expresses interest in a product or service — typically a form submission for a quote, demo, or contact. It can carry currency and value to express an estimated lead worth. It is the core conversion event for lead-generation sites, but a raw lead count says nothing about lead quality.

sign_up is a GA4 recommended event that fires when a visitor creates an account. It carries a method parameter naming the registration mechanism, such as 'Google', 'email', or 'Apple'. It is a key activation event for products with accounts, marking the move from anonymous visitor to registered user — distinct from logging in, which returning users do repeatedly.

login is a GA4 recommended event that fires when a returning user authenticates into an account. It carries a method parameter naming how they signed in. It measures engagement of existing users and, paired with sign_up, distinguishes new registrations from returning authentications — but it must never record credentials.

share is a GA4 recommended event that fires when a visitor shares content. It carries method (the channel, such as 'Twitter' or 'email'), content_type, and an item_id. It measures sharing intent on your own site — the click of a share control — not whether the share was completed or what reach it earned off-platform.

select_content is a GA4 recommended event that fires when a visitor selects content — clicking an article, a promotion, or a media item. It carries content_type and item_id to identify what was chosen. It is a general-purpose engagement event for non-commerce content, the editorial counterpart to the retail select_item event.

A subscribe event records when a visitor subscribes — to a newsletter, an updates list, or a paid plan. Unlike many e-commerce events, subscribe is not in GA4's standard recommended-events list for the web, so it is typically implemented as a custom event with consistent parameters. It marks an ongoing-relationship commitment distinct from a one-off purchase.

screen_view is the GA4 event that records when a screen is displayed in a mobile app, the app analogue of the web's page_view. It carries firebase_screen and firebase_screen_class parameters identifying the screen. It is collected automatically by the Firebase/GA4 SDKs and is the basis for app navigation and screen-engagement analysis.

app_open is a GA4 event collected automatically by the Firebase/GA4 SDK when a user opens an app or brings it to the foreground after it was in the background. It marks app launches and returns, underpinning app engagement, retention, and session analysis — but a foreground event is not the same as meaningful use.

view_search_results is a GA4 recommended event that fires when a visitor views the results of a search. It carries a search_term parameter holding the query. It captures what people look for on your site and whether results were shown — a direct window into demand and content gaps — but search terms can be sensitive and need careful handling.

video_start and video_complete are GA4 video events that mark the beginning and end of a video play. GA4's enhanced measurement collects them (plus video_progress) for embedded YouTube players. Together they bracket viewing: starts show interest, completes show retention, and the gap between them measures how much of your video people actually finish.

Event deduplication is the practice of ensuring a single user action is counted once, even when the same event is sent through multiple paths — for example browser tag and server-side. GA4 deduplicates purchases by transaction_id, and pixel platforms commonly use an event id shared between client and server. Without deduplication, dual-sending inflates conversions and revenue.

Consent state determines whether and how analytics events may be collected. Frameworks like Google Consent Mode pass signals such as analytics_storage to adjust behaviour: with consent granted, events are collected normally; when denied, collection is restricted or limited to cookieless signals. This page explains the mechanics of consent-gated event collection — it is educational, not legal advice.

view_cart is one of GA4's recommended retail/e-commerce events. You send it when a user opens or displays their shopping cart, with an items array plus currency and value parameters so reports can attribute cart-viewing behavior. It sits between product-list events and begin_checkout in the standard purchase journey, and like all recommended events it has a documented name and parameter shape GA4 understands without custom configuration.

remove_from_cart is a GA4 recommended retail event you fire when a user takes a product out of their cart. It mirrors add_to_cart in shape — an items array plus currency and value — but signals the opposite intent. Tracking it alongside add_to_cart lets you read net cart behavior and spot products that are frequently added then discarded, which is hard to see from add events alone.

view_promotion is a GA4 recommended e-commerce event for internal merchandising. You fire it when a promotion — a banner, hero slot, or campaign creative inside your own site — becomes visible. It carries promotion_id, promotion_name, creative_name, and creative_slot, plus an items array. Paired with select_promotion, it measures the on-site impact of promotional placements distinct from external ad campaigns.

select_promotion is the click counterpart to view_promotion in GA4's recommended e-commerce set. You fire it when a user interacts with an internal promotional banner or slot. It carries promotion_id, promotion_name, creative_name, creative_slot, and items so you can join clicks back to impressions and read which on-site placements drive engagement with featured products.

Checkout progress in GA4 is expressed through distinct recommended events rather than one staged event. Where Universal Analytics used a checkout_progress hit with a step number, GA4 names each stage: begin_checkout, then add_shipping_info, then add_payment_info, then purchase. This page explains how to model the multi-step checkout funnel using those events plus an optional shipping_tier and payment_type parameter.

ad_impression is a GA4 event used to record that an ad was shown, most commonly in mobile apps monetised through ad mediation. It can carry ad_platform, ad_source, ad_format, ad_unit_name, and a value/currency representing estimated revenue. It is distinct from internal view_promotion: ad_impression is about third-party ad inventory served in your app, not your own merchandising slots.

ad_click represents a user interacting with a served advertisement. In GA4's model it is the click counterpart to ad_impression for third-party ad inventory, just as select_promotion pairs with view_promotion for internal merchandising. This page clarifies which click event belongs where so you do not conflate paid ad interactions with on-site promotion clicks or generic outbound link clicks.

In 2024 GA4 renamed its measurement concept of 'conversions' to 'key events', while 'conversions' became the term used in Google Ads bidding. A key event is an event you mark as important in GA4; a conversion is how Ads counts it for optimisation. They can differ. This page explains the terminology shift, why it reduces confusion across products, and how to mark and read key events.

GA4 events come in three tiers: automatically collected, recommended, and custom. Automatic events fire without setup; recommended events have Google-defined names and parameters that unlock standard reports; custom events are ones you invent. The practical rule is to prefer a recommended name whenever one fits, because custom names miss out on prebuilt dimensions, reports, and predictive features.

level_start is part of GA4's recommended events for games. You fire it when a player begins a level or stage, passing a level_name parameter. Paired with level_end, it lets you measure how many players start versus finish each level — the core of game progression and difficulty analysis. Like all recommended events, its documented name plugs into GA4's gaming-oriented reporting.

level_end is the completion counterpart to level_start in GA4's recommended gaming events. You fire it when a player finishes a level, with level_name identifying the level and a success boolean indicating whether they completed it. Comparing level_end (success=true) against level_start per level gives a completion rate, the foundation of difficulty tuning and progression analysis.

level_up is a GA4 recommended gaming event for character or account progression — distinct from completing a stage. You fire it when a player advances a level, passing a level number and optionally a character parameter. It measures long-run progression and retention depth, answering how far players advance rather than whether they finished a single stage.

post_score is a GA4 recommended gaming event for recording a player's score. You fire it when a score is achieved or submitted, passing a score value and optionally level and character. It supports analysis of skill distribution, leaderboard behavior, and how scoring correlates with progression and monetisation events across your player base.

unlock_achievement is a GA4 recommended gaming event you fire when a player earns an achievement, identified by an achievement_id. Achievements are engagement and goal-completion signals: which ones unlock often, which are rarely reached, and how unlocking relates to retention. It complements progression events by capturing discrete milestones rather than continuous leveling.

earn_virtual_currency is a GA4 recommended gaming event for in-game economies. You fire it when a player earns soft currency — coins, gems, points — passing virtual_currency_name and value. Paired with spend_virtual_currency, it lets you model the in-game economy: earning and spending balance, currency sinks and faucets, and how the economy relates to real-money purchases.

spend_virtual_currency is the sink side of a GA4-tracked in-game economy. You fire it when a player spends soft currency, passing virtual_currency_name, value, and the item_name purchased. With earn_virtual_currency it closes the economy loop, showing where currency drains and which in-game items absorb it — key to balancing faucets against sinks.

tutorial_begin and tutorial_complete are a paired set of GA4 recommended gaming events that bracket onboarding. You fire tutorial_begin when a player starts the tutorial and tutorial_complete when they finish. The ratio between them is a direct onboarding-completion metric — one of the strongest early predictors of whether new players stick around, making this pair central to retention analysis.

Universal Analytics had a dedicated user-timing (timing_complete) feature. GA4 has no direct equivalent, so site-speed and timing measurement is done with custom events carrying numeric parameters, often sourced from the browser's Performance APIs and Core Web Vitals. This page explains how to measure timing in GA4 without inventing benchmarks, and how Web Vitals map onto custom events.

Google Consent Mode works through two commands: a default consent state declared before any tags load, and an update issued when the user makes a choice in a consent banner. Parameters like analytics_storage and ad_storage are set to granted or denied. This page explains the default/update sequence and how it gates whether analytics events use identifiers — it is educational, not legal advice.

GA4 collection can batch several events into a single HTTP request rather than one request per event, reducing network overhead. The Measurement Protocol and gtag transport both support batching within documented size and count limits. This page explains how batching works, the constraints on payload size and events per request, and why batching affects how you debug and read near-real-time data.

GA4 groups recommended events by industry, and games have their own set: level_start, level_end, level_up, post_score, unlock_achievement, tutorial_begin, tutorial_complete, earn_virtual_currency, and spend_virtual_currency. Using these documented names instead of custom ones unlocks GA4's progression and economy reporting. This overview maps the set and how the events combine into funnels.

GA4's e-commerce events are not independent — they form an ordered journey: view_item_list, select_item, view_item, add_to_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, and purchase, with remove_from_cart and refund as branches. The items array threads through them so a product can be followed end to end. This page maps the canonical sequence and why ordering matters for funnels.

Across GA4 monetary events — purchase, add_to_cart, refund, and others — two parameters carry the money: value, a number, and currency, an ISO 4217 code. GA4 requires currency whenever value is set so the figure is interpretable. This page explains the pairing rule, how mixed currencies are handled in reports, and why an unlabeled value cannot be aggregated correctly.

Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — are field performance metrics you can record as analytics events. Google's open-source web-vitals JavaScript library measures them in real browsers and hands you a value and an id you can send as a custom GA4 event. This page covers what each metric means and how to model it as an event without any personal data.

Page timing events record how long parts of a page load took — DNS, connection, time to first byte, DOM content loaded, and full load. The browser's Navigation Timing API exposes these durations precisely, and you can send them as analytics events to monitor real-world speed. They are pure timings, so they are among the safest events to collect, carrying no information about who the visitor is.

in_app_purchase is an automatically collected GA4 event on mobile apps that fires when a user completes a purchase through the App Store or Google Play. It captures the product id, price, currency, and quantity from the store, giving app monetization reporting without manual instrumentation. It is the app-store analogue of the web purchase event, and like it, records the transaction, not the buyer.

ad_reward is a GA4 mobile event fired when a user finishes a rewarded ad and receives the in-app reward — extra lives, currency, or content. It is distinct from ad_impression (the ad was shown) and ad_click (the ad was tapped): ad_reward marks completion and payout. For apps using rewarded video to monetize, it is the event that ties ad engagement to the value the user got.

app_update is an automatically collected GA4/Firebase event that fires when a user opens an app after it has been updated to a new version. It records the previous app version so you can see adoption of releases and behaviour changes after an update. It is distinct from first_open (a brand-new install) and app_open (any foreground), marking specifically the first launch on a new version.

os_update is an automatically collected GA4/Firebase event fired when a user opens an app after the device's operating system has been updated to a new version. It records the previous OS version, helping you correlate behaviour or crash changes with platform updates. Like app_update it is a lifecycle signal about the environment, not the person — useful for compatibility analysis after a major OS release.

app_remove is an automatically collected GA4/Firebase event indicating that an app package was removed (uninstalled) from a device, available on Android via Play. It is the closest thing to a churn signal at the device level — but it is reported with delay and is platform-limited, so it is directional, not real-time. This page covers how it works and how to read uninstall data honestly.

notification_receive and notification_open are GA4/Firebase events that track the lifecycle of a push notification: receive marks that a message arrived on the device, open marks that the user tapped it. Together they reveal delivery versus engagement — how many notifications land versus how many actually pull users back. They describe the message and campaign, not the recipient's identity.

Dynamic-link and campaign_details events attribute app sessions to the campaign that drove them. When a user opens the app via a tracked deep link, GA4/Firebase records campaign attribution parameters (source, medium, campaign) on a campaign_details event. This is how app installs and re-engagements get tied to a marketing source — using campaign metadata, never anything that identifies the individual user.

join_group is a GA4 recommended event that records when a user joins a group, team, guild, or community within your product. It carries a group_id parameter identifying which group was joined. It is a social/engagement signal — useful for products where group membership drives retention — and like all recommended events it records the action and a non-identifying group reference, never the user's identity.

GA4 defines two search-related events that are easy to confuse: search, a recommended event you fire when a user performs a search, and view_search_results, the event GA4 enhanced measurement fires automatically when a site-search results page is detected. They overlap in meaning but differ in origin and use. This page clarifies which is which, so you do not double-count on-site searches.

GA4 reserves a set of event names, parameter names, and user-property names for its own use, plus reserved prefixes you cannot start your own names with. Reusing a reserved name (like a built-in event) or a reserved prefix (like ga_, google_, firebase_) causes the event to be dropped or mishandled. Knowing the restricted list keeps your custom events from silently failing.

Create event and modify event are GA4 admin features that let you derive new events from existing ones, or alter incoming events, entirely in the interface — no code changes or redeploys. Create event builds a new event when conditions match; modify event changes parameters or names of events as they are processed. They are powerful for fixing taxonomy after the fact, within documented limits.

Debug mode is how you validate GA4 events as you build them: when enabled, events carry a debug flag that routes them to DebugView, a real-time stream of incoming events and parameters for a single device. It lets you confirm an event fires with the right parameters before trusting it in reports — and debug traffic is kept separate so your testing does not pollute production data.

In the gtag.js API, set and config look similar but do different jobs. gtag('config', ...) initialises a destination (like a GA4 measurement id) and can pass configuration for it. gtag('set', ...) sets values that apply to subsequent events globally, regardless of destination. Mixing them up leads to parameters that do not attach where you expect. This page clarifies their scope.

Consent Mode lets you set different consent defaults for different regions, so events from visitors in regions with stricter rules can default to denied while others default to granted. This region-specific configuration shapes what is collected before a user chooses, which matters where regulation differs by geography. It is a technical control, not legal compliance by itself.

first_open and first_visit are the new-user events in GA4, split by platform: first_open fires on the first launch of an app after install, while first_visit fires on a user's first visit to a website. They play the same role — establishing a user as new — but trigger on different platforms and signals. Confusing them, or comparing them across app and web, leads to misread new-user numbers.

user_engagement is the GA4 event that carries active engagement time. The SDK and tag send it periodically — and when the page or app goes to the background — to report how long the user was actively engaged via the engagement_time_msec parameter. It underpins engaged sessions, engagement rate, and average engagement time. It measures attention duration, never who the user is.

In GA4 app analytics, a screen_view event carries two related parameters: screen_class and screen_name. screen_class is automatically derived from the UI component class (like the Activity or ViewController name), while screen_name is a label you set to describe the screen meaningfully. Knowing the difference keeps app screen reporting readable instead of full of code-level class names.

GA4 events come in tiers by how much you do to get them: automatically collected events need no setup, enhanced-measurement events are toggled on per stream, recommended events you send manually using predefined names, and custom events you both name and send. Knowing which tier an event belongs to tells you whether it needs code, a toggle, or nothing — and prevents duplicate or missing events.

Cross-domain tracking keeps a single session intact when a user moves between two domains you own — for example a marketing site and a separate checkout domain. GA4 does this with a linker that appends the client id to outbound links as a URL parameter (_gl), so the destination domain recognises the same user. Without it, the second domain starts a fresh session and attribution breaks.

There are two common ways to send events to GA4: gtag.js, where you call the gtag() function directly in code, and Google Tag Manager (GTM), where tags fire based on triggers reading a data layer. They reach the same destination but differ in who controls firing and how events are defined. Choosing between them is about workflow and governance — not about privacy, which applies equally to both.

A rage click is a UX-signal event: a user clicks the same element several times in quick succession, usually because something looks interactive but does not respond. Frustration-signal tooling defines it by a click count within a short time window on a small pixel area. It is not a standard GA4 event name; it is a derived behavioural signal you compute or import. Treated carefully it flags broken or confusing UI.

A dead click is a UX-signal event where a user clicks an element and nothing observable happens — no navigation, no DOM change, no network call. Experience tooling derives it by watching for the absence of a reaction after a click within a short window. Like rage clicks it is not a native GA4 event; you compute it and send it as a custom event. It flags elements that look interactive but are inert.

An error click is a UX-signal event where a user's click is shortly followed by a JavaScript error, suggesting the click triggered a fault. Experience tooling correlates click timing with the next thrown error within a window. It is a derived signal, not a native GA4 event; emit it as a custom event. Unlike a dead click (no reaction) it indicates the handler ran and failed.

A copy interaction event records that a user copied text from the page, using the browser copy event. As a UX signal it can hint at which content people find worth saving — code snippets, addresses, prices — without telling you who copied. It is not a native GA4 event; you listen for copy and send a custom event. Crucially you log that a copy happened and where, never the copied text itself.

A print intent event records that a user printed (or opened the print dialog for) a page, using the browser beforeprint and afterprint events. As a UX signal it suggests reference-grade content people want offline — recipes, tickets, instructions. It is not a native GA4 event; you listen and send a custom event. It carries only the page or section context, never anything identifying about the visitor.

A page-visibility event comes from the Page Visibility API's visibilitychange event, which fires when a tab becomes hidden or visible. Analytics uses it two ways: to pause engagement timing when a tab is backgrounded, and as the safest moment to flush pending events before a user leaves. It is a browser primitive that underpins reliable measurement, not a GA4 event you name yourself.

Idle and active signals separate time a user is actually interacting from time the page is merely open. Analytics derives an active state from recent interaction (clicks, keypresses, scroll) and treats prolonged silence as idle, so engagement time does not inflate. This is a derived concept built from input events and visibility, not a single named GA4 event. It keeps engagement-based metrics meaningful.

Largest Contentful Paint (LCP) is a Core Web Vitals metric for perceived load speed: the render time of the largest content element in the viewport. To analyse it per page you capture LCP via PerformanceObserver (or the web-vitals library) and send it as an event with the value as a parameter. It is a real performance signal, not a GA4-named event, so the event name and parameter are yours to define.

Cumulative Layout Shift (CLS) is a Core Web Vitals metric for visual stability: the sum of unexpected layout-shift scores during the page's life, bucketed into session windows. You capture it from the layout-shift PerformanceObserver entries (or web-vitals) and send it as an event with the score as a parameter. It is a genuine UX signal, defined by a documented formula, that you report under your own event name.

Interaction to Next Paint (INP) is a Core Web Vitals metric for responsiveness: it reflects the latency of interactions across the page's life, reporting a representative worst interaction. You capture it from the Event Timing API (or web-vitals) and send it as an event with the value as a parameter. INP replaced First Input Delay as the responsiveness Web Vital; it is a documented signal you report under your own event name.

When a Firebase/GA4 app project is linked to the Apple App Store or Google Play, the stores can report subscription lifecycle events — purchases, renewals, cancellations, refunds — into analytics. These app-store subscription events let you analyse recurring revenue alongside in-app behaviour. They originate from the store, not your client SDK, so their availability and naming depend on the platform's own documentation.

In-app message events record how users interact with messages shown inside an app — impressions, dismissals, and action clicks from an in-app messaging campaign. In the Firebase/GA4 model these arrive as automatically collected events when in-app messaging is in use. They let you measure whether on-device prompts drive the action you intended, distinct from push notifications delivered outside the app.

A push-notification open event (notification_open in the Firebase/GA4 model) records that a user tapped a push notification to enter the app, as opposed to merely receiving it. It is the re-engagement counterpart to notification receipt: receipt means delivered, open means acted on. As an automatically collected event for messaging-enabled apps, it lets you measure whether push campaigns actually bring users back.

A deep-link open event records that a user entered the app via a deep link — a URL that routes to a specific in-app screen rather than the home screen. Combined with campaign details it attributes app entries to the link that drove them. In the Firebase/GA4 model this relates to dynamic-link and campaign-details collection. It answers where an app session began and which campaign or context sent the user there.

An app_exception event records that an app hit an error or crash, with a parameter indicating whether it was fatal. In the Firebase/GA4 model it is automatically collected when crash reporting is integrated, linking stability data to behaviour. It is the app analogue of the web exception event: a way to see crashes in the same analytics where you see engagement, so you can connect instability to drop-off.

Automatically collected events are events GA4 logs by default once the tag or SDK is present, without you instrumenting them — first_visit, session_start, user_engagement, and app lifecycle events among them. They are distinct from enhanced measurement (auto web-interaction events you toggle) and from recommended/custom events you send yourself. Knowing what is automatic prevents you from re-instrumenting events GA4 already provides.

Item-scoped parameters are parameters attached to each entry inside an e-commerce event's items array — item_id, item_name, price, quantity, and custom item parameters — describing the product rather than the event as a whole. They contrast with event-scoped parameters that describe the event (currency, value, transaction_id). Knowing the scope determines where a parameter belongs and how it can be reported in GA4.

User-scoped parameters — set as user properties — describe an attribute of the user that persists across their events, such as a membership tier or preferred language, rather than a fact about one event. They contrast with event-scoped parameters (per event) and item-scoped ones (per product). GA4 reports them as user dimensions once registered. The scope you choose decides whether a value follows the user or stays with a single event.

The ignore-referrer setting (an unwanted-referrals / referral exclusion list in GA4) tells analytics to treat traffic from specified hostnames as not a referral, so it does not start a new session or overwrite source attribution. The classic case is a third-party payment domain: without exclusion, returning shoppers look like they came from the payment provider. It is a configuration that protects session and source integrity.

Cross-domain measurement lets GA4 treat a user moving between domains you own as one journey rather than two visitors. It works by passing a linker parameter on outbound links so the destination domain recognises the same session. Without it, each domain starts a fresh session and self-referral noise appears. It is essential when a single funnel spans, say, a marketing site and a separate checkout domain.

In gtag.js, gtag('event', name, params) sends a single analytics event, while gtag('config', target_id, params) initialises a destination and its settings. They are easy to confuse because both accept a parameter object, but one transmits a hit and the other sets up where hits go. Mixing them means events that never send, or configuration passed as if it were data. This page separates their roles cleanly.

Event count and event value are two different ways to summarise events. Event count is how many times an event occurred — a simple tally. Event value sums the value parameter you attach to those events. One answers 'how often', the other 'how much'. Confusing them leads to wrong conclusions: a high count can pair with low total value, and vice versa. Reporting both keeps frequency and worth distinct.

Cardinality is the number of distinct values a parameter or dimension takes. When an event parameter has very high cardinality — many unique values — reports can exceed row limits and collapse the overflow into an (other) row, hiding detail. Understanding cardinality helps you design parameters that stay analysable: bucket continuous values, avoid unique-per-event strings, and reserve high-cardinality fields for where they are truly needed.

A custom conversion event is a conversion you define from your own events rather than a built-in one. In GA4 there are two routes: mark an existing event as a key event so each occurrence counts, or create a conversion from conditions (e.g. a page_view where a parameter matches) to synthesise an event. Both let you measure goals specific to your site, with different trade-offs in precision and maintenance.

Channel grouping classifies each session's traffic into a channel (Organic Search, Paid Social, Direct, and so on) using rules over the source/medium that events carry. GA4 ships a default channel grouping with fixed rules; custom channel groupings let you redefine those rules to match your taxonomy. Knowing the difference explains why the same traffic can land in different channels depending on which grouping a report uses.

first_open is an automatically collected app event that fires the first time a user opens an app after installing or reinstalling it. It anchors app acquisition the way first_visit anchors web acquisition, marking the start of the user's relationship with the app. It is logged by the SDK without instrumentation. Understanding it helps you read new-user and install-attribution reports correctly on mobile.

GA4 enhanced measurement fires a single scroll event when a user reaches 90% of page depth — useful but coarse. When you need finer resolution, you implement custom scroll-depth thresholds (for example 25/50/75/100%) and send your own events at each. This page covers why the built-in signal is one-shot at 90% and how to add granular thresholds without double-counting or spamming events.

form_start is an enhanced-measurement event that fires the first time a user interacts with a form on the page — well before form_submit. The pair lets you measure form abandonment: how many people begin a form versus how many finish it. It is captured automatically when form interaction tracking is enabled, with parameters describing the form, not the entered data. It turns 'did they submit' into 'where did they drop'.

GA4 imposes limits on events: a cap on parameters per event, and separate caps on how many custom dimensions/metrics you can register to surface those parameters in reports. An unregistered parameter is collected but not reportable as a dimension. Knowing these limits prevents the surprise of sending data that never appears. This page explains the relationship between sending, registering, and reporting parameters.

Session timeout is the period of inactivity after which the next event starts a new session rather than continuing the old one. It governs how GA4 groups events into sessions: a return after the timeout begins a fresh session_start. The default window is configurable. Understanding it explains why a single user can generate several sessions, and how changing the timeout shifts session counts without any change in behaviour.

video_progress is an enhanced-measurement event that fires as a user reaches playback milestones — commonly 10%, 25%, 50%, and 75% — of an embedded video. Sitting between video_start and video_complete, it shows engagement depth: not just whether play began, but how far viewers got. It is captured automatically for supported embeds with parameters describing the video and percent, not the viewer. It turns a binary into a drop-off curve.

Onboarding step events model a multi-step first-run flow as a funnel. While GA4 offers tutorial_begin and tutorial_complete, the steps in between are yours to define: send a custom event per onboarding step with a step index or name. This reveals where new users stall before they finish setup. It complements the begin/complete pair with the granular middle, all keyed to step identity rather than the user.

Every GA4 event is associated with a client/instance identifier that distinguishes a browser or app instance, set automatically. A user ID is a separate, optional identifier you assign to authenticated users so their events join across devices. The two answer different questions: device/instance continuity versus cross-device identity. This page explains how each attaches to events and why user ID demands extra privacy care.

Observed event data is what analytics directly recorded; modeled data is estimated to fill gaps left by consent declines, cross-device journeys, or privacy limits. GA4 can blend modeled conversions into reports when behavioural modeling conditions are met. Understanding which is which keeps you honest about precision: modeled figures are estimates with assumptions, not counted hits. This page explains the distinction and how to read blended reports.