No, not every form submit should be a key event. Google's Analytics Help describes a key event as an event that measures an action that is particularly important to the success of your business. The test is not whether something happened on the page but whether the action changes the outcome you care about.
It is written for marketers, store managers and analysts who have already collected events and now need to decide which ones deserve the label. If your question is about one specific interaction, see the narrower write-up on click-to-call and chat key events.
Choosing key events: forms, purchases and landing pages
The rule fits in one sentence. Mark the actions that represent your business outcome, or that are an unavoidable step toward it. Everything else stays a regular event, which is still useful for analysis.
A filter of three questions
Ask three things about every candidate. First, would the business outcome still happen if this action never occurred? If the outcome is impossible without it, the action is a strong candidate. Second, would a higher or lower count change a decision, such as a budget, a page or a channel? If no decision depends on it, the number is decoration. Third, does it signal intent or only interest? Scrolling shows interest. Sending a quote request shows intent.
A short list is the goal: five clear key events are easier to act on than thirty vague ones.
Forms: the valuable and the routine
The common mistake is to bundle all forms into one event and mark it. A typical site has a contact form, a newsletter box, a quote request, a support ticket, a product question and an account registration. They do not carry the same value. If they all fire "form_submit" and that event is marked, the Key events column becomes large but meaningless.
Split the forms by what they mean to the business. A sales-qualified request is a key event. A newsletter signup is a key event only if your model is built on subscribers, such as a publisher. A support ticket is usually a service metric, not an acquisition metric, so marking it would count existing customers asking for help as wins in your acquisition reports.
Also protect the count against noise. Bot submissions, test entries and double clicks inflate the number. An event fired after the server confirms a valid submission is more trustworthy than one fired on a button click.
Purchases and checkout steps
For a store, the completed purchase is the obvious key event. The steps before it, such as adding to cart, starting checkout and entering payment details, are valuable for funnel analysis but usually do not need the label. If you mark them, the Key events column mixes outcomes and steps, and the session key event rate stops describing real results.
There is one exception: when the sale finishes offline. A business that closes deals by phone after a web request has a request event as its online outcome. Mark that request and document which business result it stands for.
What a campaign landing page should report
A campaign landing page usually exists for one action, such as a form, a download, a call or a booking link. Define that single action as the page's event and keep its name stable across similar pages. A page view is a visit record, not a goal; marking it erases the difference between traffic and results.
When you read the Landing pages report, compare pages that share the same event name. If two pages carry the same form and report it under the same event, you can see which page performs better. If every page invents its own event name, the comparison breaks.
The decision table at a glance
| Action | Mark as key event? | Reason |
|---|---|---|
| Purchase completed | Yes | Direct business outcome |
| Quote or demo request submitted | Yes | Start of a sales process, clear intent |
| Newsletter signup | Depends | Yes for subscriber models, otherwise a regular event |
| Support form submitted | Usually no | Service metric, not acquisition |
| Add to cart | Usually no | Funnel step, not an outcome |
| Click to call or chat | Depends | An outcome for service businesses, a step for stores |
| Page view, scroll | No | Interest, not intent |
Checklist before you mark anything
- Is the link between the event and a business outcome written in one sentence?
- Does the event fire once, only when the action is truly complete?
- Are spam, test and duplicate submissions filtered out?
- Does the event name follow your team's naming standard?
- Do you know which decision changes when this count moves?
- Is there an owner and a report where this number will be read?
Example scenario: a software trial site
Example scenario: a small software company offers a free trial. The site has a pricing page, a blog, a trial signup form, a newsletter box and a help center search. In the first setup, the marketer marks every one of these as a key event because they are all "engagement". The report looks healthy because the Key events column is large. Yet the sales lead notices that most key events come from the blog newsletter box, while the trial signups barely move.
The correction has three parts. The trial activation event gets its own name and fires only after the account is confirmed on the server. The newsletter signup stays a regular event because the company does not sell subscriptions. The help center search is unmarked entirely. After the change, the key event count falls, but now it moves together with the trial numbers the sales lead sees in the product database. A lower number is not a loss; it is the first time the metric reflects the goal.
Show the before and after periods separately in reports and annotate the switch date. Otherwise the drop reads as a collapse in performance when it is really a cleaner definition.
Key events and conversions: what the help page says
Many teams still say "conversion" when they open GA4, and the habit causes real confusion when the same word is used for two different objects. Separate the vocabulary first, then the setup becomes easier to reason about.
The definition
According to the Analytics Help page on key events (Opens in a new tab), a key event is an event that measures an action that is particularly important to the success of your business. When a user triggers one, Analytics records it and shows it in your reports. The page describes a simple flow: an event is collected, and an event you choose can then be marked as a key event. Any collected event can be marked, which does not mean every event should be.
The page does not define "conversion" on its own. It points to a separate topic about conversions. So a sentence such as "a key event is simply the new name for a conversion" is not something that page states. A careful reading is that the important action inside Analytics is now called a key event, while a conversion in advertising is a separate object created from it.
Reports that change when you mark an event
The same page lists several places. The Landing pages and User acquisition reports include a Key events column. The All events menu lets you filter down to one key event. In Explorations you can use the metrics Key events and Session key event rate. The Pathing and Attribution reports in the Advertising section show how touchpoints on the path to a key event receive credit under different attribution models.
That list tells you what marking an event actually changes: a new column in acquisition and landing page reports, and a new rate metric. If you mark the wrong event you will read the wrong number by channel and by page, which is why the choice deserves a rule rather than a guess.
How Google Ads fits in
The help page says you can create a Google Ads conversion from a key event and manage its settings in both Google Ads and Analytics. The benefits it lists include matching conversion counts across both tools, reporting on non-Google and organic channels, bidding on conversions and building remarketing audiences. It also states that Google Ads conversions do not appear in standard Google Analytics reports; you evaluate them in Google Ads or in the Advertising section of Analytics.
In practice, do not expect the conversion count in your ad account to match the key event count in a standard GA4 report. If you need to compare, use the same event, the same date range and the same counting method. The counting method itself is covered on a separate help page.
Some details are simply absent from that page: a limit on key events per property, whether marking an event changes past data, and the list of default key events. Check the current Help pages for those before you rely on them, because limits and behaviors can change over time.
Event names and parameters
Choosing the right event is half the job. The other half is making sure the same action always arrives under the same name, on every page, in every language and on every device. Otherwise the same form shows up as three rows and your marking applies to only one of them.
A naming standard that lasts
A short rule set is enough. Use lowercase, separate words with underscores, describe the action with a verb or an object plus verb, and keep language out of the name. If one developer writes "quote_form_submit" and another writes "teklif_formu_gonderildi", you now have two events for one action. Pick one language for event names and keep it regardless of the interface language of the site.
Think about history before renaming. A renamed event is collected as a new event, while the old name stays in past data, so reports need to read both. Settling names before launch is cheaper than repairing them later.
One name per action, parameters for the rest
Variations of one action belong in parameters, not in new event names. You could send a single "form_submit" event and describe which form with a parameter. The catch is that marking happens by event name. If all forms share one name, they are marked together. When some forms should be key events and others should not, give the valuable ones their own name.
The summary rule: each action you intend to mark gets its own name, and variations you do not intend to mark travel under a shared event with parameters. Keep parameter values in a fixed vocabulary too, because "Quote", "quote" and "QUOTE" read as three values.
An example vocabulary
| Action | Event name | Sample parameters | Key event |
|---|---|---|---|
| Lead request | generate_lead | form_name, page_type | Yes |
| Purchase | purchase | transaction_id, currency | Yes |
| Newsletter signup | newsletter_signup | placement | Depends |
| Support request | support_request | topic | No |
| File download | file_download | file_name | Depends |
These names are an example standard, so adapt them to your team. How to populate item, value and transaction fields for purchase events is a separate technical subject.
Preventing double counts
When the same action can fire from the page, from a tag manager container and from the server, the event can be counted twice. A thank-you page that fires its event again on refresh inflates purchases. Send a transaction identifier with the event, fire on the first view only, and keep test orders out of the stream. Double counting raises the session key event rate artificially and damages every decision that follows.
Where visits came from: campaign tags and organic
A key event answers how many. To answer where they came from, traffic has to be tagged correctly. For campaign links, UTM parameters do that work.
Required UTM parameters
The Analytics help page on custom campaign URLs (Opens in a new tab) says you should always use utm_source, utm_medium and utm_campaign when you add parameters to a URL. Values are case sensitive, so utm_source=google and utm_source=Google are different. Missing parameters cause (not set) values in reporting. Keep tagging in one shared vocabulary, because inconsistent spelling splits your key events across fragmented source rows.
The page also notes that UTM information is not captured in the Landing page + query string and Page path + query string dimensions and appears in the Page location dimension instead. For channel questions, read session source, medium and campaign instead. The full tagging standard is a separate subject; here we only look at its effect on key events.
Search Console beside GA4
For organic search, read the Key events column next to the Search Console Performance report. According to the Search Console help page on the Performance report (Opens in a new tab), it shows clicks, impressions, CTR and average position. GA4 counts sessions and events. The tools measure different units, so a click count will not match a session count or a key event count, and the difference is expected. For the organic reading itself, see analyzing organic traffic in GA4.
Which report answers which question
| Question | Where to look | Caution |
|---|---|---|
| Which queries bring visibility | Search Console, Queries | Measures clicks and impressions, not key events |
| Which page produces key events | GA4 Landing pages | Key events column, exposed to consent loss |
| Which campaign produced key events | GA4 Traffic acquisition | Depends on UTM consistency |
| How many ad conversions | Google Ads or the Advertising section | Not in standard reports |
Verifying with DebugView
A setup that looks like it works is not a verified setup. Check three layers: the event is sent, it carries the right name and parameters, and it is marked and visible in reports.
Live checks
DebugView in the GA4 admin area shows events from a device in debug mode as they arrive. While testing, watch for the following. Does the event appear once when you complete the action? Does the name match your vocabulary exactly? Are the parameters filled with the values you expect? Menu names are given in English here; if you use the interface in another language, labels can look different.
Repeat the test in different conditions: desktop and mobile, consent given and declined, a successful and a failed form submission. A failed submission should not fire the event. If it does, your counts will be inflated.
Marking the event and checking reports
Once the event arrives correctly, use the "Mark as key event" option from the events list. Menu labels can differ in your interface. The Help page does not walk through the marking steps, so follow the guidance shown in the admin screen. After marking, confirm the Key events column appears in the Landing pages and User acquisition reports. It can take a while for a new event to show; the page gives no exact timing.
Seven verification steps
- Definition: write the event name, parameters and business outcome in your vocabulary.
- Trigger: confirm in DebugView that it fires once when the action completes.
- Negative test: submit an empty or failing form and confirm no event is sent.
- Marking: mark the event as a key event.
- Reports: check the Key events column in Landing pages and User acquisition.
- Reconciliation: a week later, compare the count with the system of record.
- Record: note the date and version so later site releases can be retested.
When consent lowers the numbers
Even a perfect setup will not capture every visit when visitors decline analytics cookies. The technical details of consent modes live in a dedicated article.
Why GA4 reads below reality
If a visitor rejects analytics storage in your consent banner, standard measurement for that visit can be reduced or absent. As a result the key event count in GA4 can sit below the number of orders in your shop or the number of leads in your inbox. That is not a bug; it is the normal difference between a measured sample and the full picture. How large the difference is depends on your audience, banner design and configuration. Google's Help pages give no general rate, so do not assume one.
For the full framework, read the cookie consent, privacy and measurement loss guide.
Reconciling with your own records
For each key event, name a system of record. For purchases it is the order database. For leads it may be the CRM or the shared inbox. Once a month, compare the GA4 count with that source and write down the ratio. A stable ratio means the measurement is consistent and GA4 is reliable for trends. A sudden change in the ratio suggests a broken tag, a changed banner or a site update.
Low-volume rows that disappear
Low-volume key events can also vanish from some breakdowns, which is a separate phenomenon explained in our note on GA4 data thresholds. A missing row does not mean zero events.
Who answers the legal questions
Consent is both a legal and a technical subject. Which cookies need consent, what the banner must say and how long data is kept depend on your jurisdiction. Ask your legal advisor and read the applicable rules.
A maintenance routine
Key event setup is not a one-time task. Pages are redesigned, forms are replaced, payment providers change and people leave the team. A small routine keeps the data trustworthy.
Weekly, monthly and quarterly checks
Weekly: glance at key event counts and look for sudden zeros or spikes. Monthly: reconcile with the system of record and write down the ratio. Quarterly: review the vocabulary. Are there events nobody reads, key events that no longer represent an outcome, or new actions that deserve the label? If the business model changed, the list should change too.
Release-time questions
Whenever a new form, checkout step or landing page ships, ask three questions before launch: which event fires here, is its name in the vocabulary, and is it a key event? Add these to the release checklist and attach a DebugView note to the change log. A month later, when a number moves, that record shortens the investigation considerably.
What to hand over
An agency or a new colleague taking over needs four things: the event vocabulary, the list of marked key events with reasons, the latest reconciliation against the source of truth and the change log. Without them a handover means rediscovering the setup from scratch.
Mistakes and fixes
Many meanings under one name
Bundling different actions under one event name is the most common error. Split valuable actions into their own events and keep shared variations as parameters.
Breakage nobody notices
A redesigned form component can quietly break the trigger. Run a quick DebugView test after every release, review critical counts weekly and alert on sudden drops to zero.
History does not rewrite itself
Do not assume past reports stay the same after you rename an event or change what is marked. The help page does not describe retroactive behavior, so record the change date and read reports in two segments around it.
Ad numbers versus analytics numbers
Google Ads conversions do not appear in standard GA4 reports, and the two tools may count differently. Write down which report answers which question instead of hunting for a single number in two places.
Unclear ownership
If nobody knows who may add events or mark key events, the vocabulary decays quickly. Keep a short change log with date, person, change and reason. It becomes the first place to look when a report number moves unexpectedly.
Frequently Asked Questions
Is a GA4 key event the same as a conversion?
The Analytics Help page defines a key event as an event that measures an action particularly important to the success of your business, and it does not define conversion itself. A Google Ads conversion can be created from a key event, so the two are related but separate objects in reports and in ad accounts.
Should every form submission be marked as a key event?
No. Mark only forms that represent a business outcome or an unavoidable step toward it. A quote request usually qualifies, while a support ticket or newsletter box may stay a regular event depending on your model. Marking everything inflates the count and blurs the signal.
How long until a new key event shows in reports?
The Help page gives no exact timing. DebugView shows the event as it arrives, while reports may need some time. Check the current Help pages if you need a precise expectation.
Do visitors who decline cookies count toward key events?
Standard measurement can be reduced for visits without consent, so GA4 may show fewer key events than your real orders or leads. No general loss rate is stated in Google's Help pages; compare with your own system of record. Consult a professional about consent.
What happens to history if I rename an event?
A renamed event is collected under the new name while old data keeps the old name. The Help page does not describe retroactive behavior, so note the change date and read reports in two segments.
Why are Google Ads conversions missing from standard GA4 reports?
The Help page says Google Ads conversions do not appear in standard Google Analytics reports and should be evaluated in Google Ads or in the Advertising section of Analytics. Counts can therefore differ between the two places.
Why do Search Console clicks not match GA4 key events?
Search Console reports clicks and impressions, while GA4 counts sessions and events. The tools measure different units, so compare trends rather than forcing the numbers to match.
Related guides: What Is Conversion Rate Optimization (CRO)? First Steps, Lead and Contact Form Design for Conversion, Social Proof and Reviews on Landing Pages.
Conclusion
A good GA4 key event setup is small, consistent and verified. Mark the few actions that represent your business outcome, give each one a single stable name, reconcile counts with a system of record to manage the gap left by cookie consent, and retest in DebugView after every release. Skip the habit of marking every form submit; choose the events that would change a decision. Where the Help pages are silent, such as on limits and retroactive behavior, check the current documentation.
If you plan a campaign or visibility effort where you will measure these events, you can review the options under ad spaces at Akua Adforce; scope and terms are written on that page.
Post a comment
Please log in to leave a comment. Login