A GA4 payment event counted button clicks: an event audit checklist

In September I checked every event happymonday.ua sends to GA4: 38 event names, 38 event tags in Google Tag Manager, and data from July 29 to September 25, 2026 in BigQuery, compared with the site’s database. The main numbers held: job applications, clicks to employer sites, sign-ups, B2B lead forms. Two of the nine key events did not. They fired every time, and they counted something other than their name.

The event called “vacancy payment” was a click on the Publish or Save button in the vacancy form, edits included. For each paid vacancy in the database, GA4 had about 14 of these events. The event called “guide purchase” fired on every “thank you for your payment” page, and 84% of its events were vacancy payments.

A tag check doesn’t catch this. The tags fired, the hits reached GA4, and the reports had numbers in them. It takes a second count of the same action: the database, the payment system, a CRM. Below is the checklist I use for that, with the bug behind each line. The first audit of this site, which caught every sign-up counted twice, is a separate case.

One ratio sorts the events

For each event that has a matching record in the database, I divided the GA4 count by the number of records for the same days. A browser-side event loses some hits to ad blockers and to tabs closed before the hit goes out, so a working event sits a little under 1. In the week of September 19–25 job applications came to 0.96 and clicks to employer sites to 0.95. B2B lead forms came to 0.99 over two months.

Two kinds of values point to a broken event. Above 1, it counts another action, or the same one several times. Zero means it no longer fires. In a report on one event, both look like ordinary numbers, and on one line of ratios they stand out at once.

A ratio needs a record to compare with. If an event matches no row in any database, it is a click or a view, and its name should say so. In August the event called “apply” was a click on the Apply button, which only opens the form: for every 100 of these clicks, the database had 56 applications.

The second count needs its own check. The site’s internal dashboard showed about two thirds of company sign-ups, because it counted only the companies that had gone on to fill in their settings. The table of users had them all.

What the two payment events counted

The “vacancy payment” tag fired on the button that sends the vacancy form. The same button saves an edit, so in one week of September a third of these events were edits and two thirds were new vacancies, paid or not. The amount was empty in every event, so neither GA4 nor the linked Google Ads accounts saw any revenue from them.

The site already sent the right signal. On the thank-you page of a paid order it pushed a payment event with the product type to the data layer, and no tag in the container listened to it.

“Guide purchase” waited for the thank-you page, and every product on the site shares that page.

Reloads added to the count: one order was counted seven times. An event on a shared page needs two conditions, the product it is about and one count per order number.

A tag silent for a year

The job alert tag had no events in the 59 days of data. Its last event in GA4 was on September 29, 2025. The trigger waited for a click on a button with a certain label and CSS class. The live button had a new label and a new class, and the tag stopped without any error.

Eight more of the 38 event tags fired twice or less in 59 days. Some waited for events the site no longer sends, others for clicks on campaigns that had ended. None of them changes a number in a report, but each makes the container harder to read.

One event came from neither the container nor the site’s code. It was a rule in GA4 itself, under Admin → Data display → Events → Create event, which turned a page view of one page into a separate event. The property had five such rules, and in a year only that one had fired.

Repeats, impossible pairs and wide selectors

Closing the article-limit popup counted every click. In September 17% of closes were repeats on the same page, up to 26 on one page, and on two days there were more closes than shows. Closes above shows can’t happen, just like purchases above checkouts, so a pair like that is a quick test for any funnel.

The impression trigger for promo cards in one section of the site also matched the news feed and special project cards on the same page. Those made up 10% of the section’s card impressions, some of them in positions 1–3, so a filter by position in reports didn’t remove them.

Five parameters arrived with events but were not registered as custom dimensions, so no report could show them. The sign-up push also carried UTM tags and the referrer, and the tag didn’t pass them on.

How we fixed it without breaking Google Ads

The GA4 property is linked to three Google Ads accounts. If Ads imports a key event as a conversion, a change to its trigger changes what the campaigns optimize for on the same day. So the package of fixes didn’t change the trigger of any old key event. It added correct events next to them: payment success from the thank-you signal, a guide purchase limited to the guide, and a job alert on the screen that confirms the alert was saved. The popup close now counts once per page, the promo trigger reads only its own block, and the parameters are registered.

The package went live on October 13. On the first day the new payment event stayed below the number of paid orders, and the old one recorded twice as many events as there were orders. The referrer arrived with 64% of sign-ups and UTM tags with 26%. The key events are due to switch to the new ones after two weeks of this comparison.

The new events have limits of their own. Orders paid by invoice never open the thank-you page, so the payment event can’t see them; for those the site needs an event from the server when an order is marked paid. The job alert event sees alerts created on the search page, not the ones created with a checkbox on the application form.

Some findings stay as they are. Outside hosts, such as a test copy of the site and Google Translate, sent 0.05% of the week’s sessions into the production property, and filtering them would take a blocking trigger on about 40 tags, a bigger risk than the noise. The loss of about 5% on applications and employer clicks is stable from day to day, which is the usual sign of ad blockers, and volumes come from the database anyway.

GA4 event audit checklist

Start with the first two lines. They take an export of event counts and a few database queries, and they show which events are worth opening.