How a custom event trigger works
A custom event trigger listens for a name. When the website performs a data layer push containing an event key with that name, the trigger matches and every tag attached to it runs. The match is exact, capital letters included, which is either reassuring or infuriating depending on how carefully the names were agreed.
Conditions can narrow it further. The same event name can fire one tag only when the form was the enquiry form, or only on a particular hostname, or only when the order value is above a threshold the business cares about. Pattern matching lets one trigger cover a family of related names, which is useful once naming has settled and dangerous before that.
Why custom event triggers matter
This is the only trigger type where the website decides. Every other kind infers what happened from what a browser can observe — a click landed here, a URL changed, an element became visible. A custom event is a statement from the application itself: this order completed, this payment cleared, this enquiry was saved. Statements are worth far more than inferences when money depends on the answer.
That is why serious conversion tracking is built on custom events wherever the site can supply them. It is also why they survive redesigns: the event lives in the code that does the work, not in the wording of a button or the shape of a URL.
Where custom event triggers go wrong
Name drift causes most failures. A developer pushes generate_lead, the trigger waits for generateLead, and nothing happens. No error appears anywhere, the tag simply never runs, and the drop in conversions is usually spotted weeks later by whoever checks the ad account.
Firing on intent rather than outcome is the more damaging mistake. An event pushed when the submit button is clicked counts people whose form failed validation, whose payment was declined, or who clicked twice. Push on success, not on attempt.
Timing catches the rest. A tag fired at the instant the browser leaves for another page may not finish its request, so a form that redirects immediately can lose its conversion. Where that happens, the answer is to push the event on the destination page instead, or to let the redirect wait until the tag has run.
How to act on it
Agree the names before anything is built, write them down in one place, and use past-tense outcomes: enquiry_submitted, purchase_completed, quote_requested. Keep one event per meaningful outcome rather than a single generic name carrying a type field, unless there are enough variations to justify the extra condition logic.
Test each trigger in preview using the real journey, not a shortcut, and then confirm at the far end that the destination platform actually recorded it. A trigger that fires and a conversion that arrives are two separate facts, and only checking both catches the case where the tag ran but the value was empty.
Finally, review the list whenever the site changes. Custom events break silently by design — that is the price of their precision — so a short check after each release is what keeps them honest.