A custom event trigger is a Google Tag Manager trigger that fires tags when a named event is pushed into the page’s data layer, for example “booking_confirmed” or “quote_submitted”. It lets your website tell Tag Manager exactly when something important has happened, instead of Tag Manager inferring it from clicks and page loads.
How a custom event trigger works
In Google Tag Manager, every trigger listens for something. Click triggers listen for clicks and page view triggers for page loads. A custom event trigger listens for a message in the data layer containing an “event” key with the name you specify.
That message comes from the site itself. When a visitor finishes a booking, the booking system or a developer’s code runs a dataLayer.push with the event name booking_confirmed and details such as the service booked and its value. Tag Manager reads the name, checks it against every custom event trigger in the container and fires any tag attached to a match. One push can fire a GA4 event, a Google Ads conversion and a Meta Pixel event together.
The trigger has only a few settings:
- Event name The exact text the site pushes. Matching is case-sensitive.
- Use regex matching Optional, so one trigger can match a pattern, such as any event name beginning with “form_”.
- This trigger fires on All custom events with that name, or only some, filtered by conditions such as the page path or a data layer variable.
Why it matters
Many UK small business sites depend on third-party tools that Tag Manager cannot see into: booking widgets, quote builders, hosted payment pages, forms loaded in an iframe and single-page checkouts. A form submission trigger often fails on these because the form never submits in the traditional way. An event pushed on success is far more dependable, because it fires only when the action has actually completed.
It also survives redesigns. A click trigger based on button text or a CSS class breaks the moment someone renames “Get a quote” to “Request a quote”. An event name agreed with the developer keeps working because it is tied to the outcome, not the look of the page. When I review tracking behind paid campaigns, moving the main conversions onto custom event triggers is usually one of the first changes I recommend.
Common mistakes
- A name that nearly matches. The site pushes “Booking_Confirmed” and the trigger listens for “booking_confirmed”. Nothing fires, and often nobody notices for weeks.
- Over-broad regex. A pattern such as “.*” matches every event, including Tag Manager’s own gtm.js, gtm.dom and gtm.load, so the tag fires several times on every page. That is a classic cause of double firing.
- Pushing the event before the data. If the event name goes in one push and the order value in a later one, tags fire with an empty value. Put the event and its details in the same push.
- Confirmation pages that can reload. If the push sits on a thank-you page, a refresh sends the conversion again. Guard against repeats, for example with a transaction ID.
- No record of what the site sends. Without a list of event names, the next person to edit the container has to work it out from scratch.
How to act on it
Agree a short specification with whoever builds or maintains the site: the event name, the moment it is pushed and the details it carries. Ask for the push to happen after the action succeeds, not when the button is pressed.
Then open Tag Manager’s preview mode, complete the action yourself and look for the event in the timeline on the left. Select it and check that the data layer tab shows the values you expect. Only then create the trigger, copying the event name exactly, and attach your tags. Test once more before publishing, and add the event to your tracking plan so the next person knows it exists.