Job ga4-key-event-not-recording · revised 11 October 2026
Get one GA4 key event recording again, proven with a test event
One named action on your site produces one GA4 event with the agreed name, visible in DebugView and then counted as a key event.
You might be seeing
- An event is starred as a key event but its count stays at zero while enquiries still arrive
- The action works for a visitor but nothing with the expected name shows in DebugView
No passwords, keys, card details or admin invites needed to start.
What usually happened
The action on the site is not producing an event with the exact name that was marked as a key event. The usual causes are a trigger that no longer matches the page, an event name that differs by case or spelling from the one starred, an event name too long to be reported as a key event, or an event that is sent but was never marked. Marking an event is not retroactive, so the gap is a collection fault, not a reporting setting.
Who it’s for: A marketer or small-business owner who reports on a form, booking or sign-up count in Google Analytics 4 and has seen that count stop or never start.
Usually starts when: The real action still happens on the site, but the key event count is zero or has dropped sharply since a change to the site, the tag setup or the property.
The result: A test visit that performs the agreed action produces exactly one event with the agreed name and parameters in DebugView, the event is marked as a key event, and, once Google has processed the data, a GA4 exploration shows the key event once for a test visit that carries the agreed test marker.
Check whether this job fits
Answer these without sharing logins or customer data. Nothing is sent unless you choose to contact us.
Checks you can run yourself
Look for the event in DebugView
Open Tag Assistant or Tag Manager preview for your site, accept analytics cookies if a banner is shown, perform the action once, then open DebugView in the GA4 property.
Look for: One event with the name you expect. Zero events suggests a trigger fault; an event with another name suggests a naming fault. Remove personal details before sharing a screenshot.
What you get
- The repaired tag or trigger prepared for your approval, with a before and after note
- DebugView screenshots of the failing test visit and the passing test visit, each showing the event name and parameters
- A one-page note naming the event, its trigger rule, who marked it as a key event and how to check it each month
Included
- One action, one event name, one web data stream in one GA4 property
- Find which of the four fault types applies by comparing the live behaviour in DebugView with the tag setup and the event list
- Repair the tag, trigger, event name or marking, and publish only the change you approve
- Record the before and after test visits with timestamps
Not included
- Repairing historic counts: marking an event as a key event applies from the time it is marked, not to past data
- Setting up several new events, an ecommerce funnel or a new tracking plan
- Google Ads, Meta or other ad-platform conversions, which are separate outcomes
- Consent banner configuration or legal advice on consent
- Any promise about ad performance, revenue or rankings
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Performing the agreed action once in a debug-enabled browser (in Tag Manager preview before you publish, and on the live site after) produces exactly one event with the agreed name in DebugView, with the agreed parameters present.
Evidence: DebugView screenshot showing the event name, its timestamp and its parameters, matched to the test visit time.
Performing the action twice produces two events, and performing a different action on the same page produces none, so the trigger is neither missing nor too broad.
Evidence: DebugView event counts for the three test steps, in order.
The event is marked as a key event in the property, and after Google has processed the data a GA4 exploration filtered to the test marker lists the key event once for the test visit.
Evidence: The Events list showing the event marked as a key event, then a screenshot of the exploration (event name and session campaign for the test marker) taken after Google's stated processing time.
Sign-off. We prepare the change and run the tests in preview; you review the DebugView evidence and publish the change yourself; we then repeat the test on the live site and read the report check; you sign off in writing after that. Payment follows sign-off.
If it fails. If the test visit does not pass, you do not pay for this fixed scope. If the cause turns out to be outside the agreed scope, we explain it and stop or re-quote in writing.
When it fits, and when we stop
It fits when
- You can name the action, for example a form being sent, and the event name you expect
- The site has the Google tag, directly or through Google Tag Manager, and you have an account holder who can grant a scoped role
- A test action can be performed on the live site or a staging copy without charging a card or contacting a real customer
- Analytics cookies can be accepted in the test browser. If your site has a consent banner, Google says DebugView shows no events when consent mode is on and the visitor has not consented to analytics cookies
- No Active data filter on the property drops the test traffic. Google says a developer-traffic filter removes activity from debug mode and that excluded data is never processed; if one is Active, the report check uses a separate test visit made without debug mode, agreed in writing before work starts
We stop and tell you if
- The only way to perform the action is a real payment or a message to a real customer
- Several unrelated events are missing, which makes this a wider measurement rebuild and needs a different scope
- No one on your side can grant access to the property or the container
What could go wrong
Every change is a Tag Manager workspace change. When you publish it, Tag Manager records it as a version, so you can republish the previous version at any time. Property settings changes are listed with their previous value.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The fix makes the event fire on more pages than intended and inflates the count. | The acceptance test performs the action twice and a non-matching action once, and counts events in DebugView each time. |
| A test visit pollutes real reports. | Test visits carry the agreed test marker and are listed in the handover so they can be told apart; we do not claim a clean report from test traffic. |
A separate reviewer checks that the event name, parameters and trigger match the agreement and that no personal data is added to the event. You publish the change under your own account.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the action, the event name, the stream, the test marker and the access route in writing
- Reproduce the failing test visit in DebugView and in Tag Manager preview, and capture both
- Identify which of the four fault types applies: trigger, name, length or marking
- Prepare the smallest change in a Tag Manager workspace or the property settings and test it in preview
- Have the change reviewed separately, then hand it over for your named person to publish
- After you publish, repeat the test visit on the live site and read the exploration for the test marker once Google has processed the data
This is a one-off job, not a subscription or emergency cover. We confirm eligibility, the price, a start window and a delivery date before you accept. Work starts only after the agreed inputs and the least access the job needs are in place. Fees charged by Google, Meta, your host or any tool you use are not included. No charge or booking is created by an enquiry.
Need to keep it working?
If the count matters every month, a standing check can run named test events and compare counts.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Your own analyst can compare DebugView with the Tag Manager preview using Google's DebugView guidance. support.google.com
- If an agency already manages your tags, ask them to show you the failing event in DebugView first.
Questions
Will this restore the numbers from when it was broken?
No. Marking an event as a key event applies from the time of marking, and events that were never sent cannot be recreated. The job restores correct collection from now on.
Why can the report lag behind DebugView?
DebugView shows events as they arrive, while Google says many reports and explorations can take 24-48 hours to process data, so the report check follows the DebugView check by a day or two.
Why does my own test not show in DebugView?
If your site has a consent banner, Google says events are not visible in debug mode while consent mode is on and the visitor has not consented to analytics cookies. Accept analytics cookies in the test browser, then try again.
Do you need my Google login?
No. You grant a scoped role to an identity we agree with you before work starts, and you can remove it afterwards.
Send an enquiry
Send us
- The name of the event you expect and what the visitor does to trigger it
- The date the count stopped or when you last trusted it, and any site or tag change around then
- Whether the site uses Tag Manager, a plugin or hand-placed code, as far as you know. No logins, no customer data.
Later, once you agree
- A scoped Editor role on the GA4 property and Edit access to the Tag Manager container (Google describes Edit as able to create workspaces and make edits but not create versions or publish; you publish), granted to the identity we agree with you before work starts
- The agreed test action and a safe way to perform it
- Your named person who will publish the change
You own the website, the Google and Meta accounts, the tag manager container and all the data. We ask for the lowest role that lets us do the job. Before any work starts we agree with you in writing which identity receives that role; you grant it and can remove it at any time. We never ask for your passwords. You keep the right to publish: we prepare changes and you publish them.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “ga4-key-event-not-recording” as the subject.