How a click trigger works
Tag Manager offers two kinds. All Elements fires on a click anywhere on the page. Just Links fires only on clicks that follow a link, and adds the option to hold the browser back briefly so the tag can finish sending before the next page loads. Neither should be left wide open: conditions narrow the trigger to the element you actually care about, using the click URL, the element’s classes or identifier, or the text inside it.
Those conditions come from the click built-in variables, which only hold a value during a click event. That is why testing has to involve clicking the real element in preview, rather than reading the variables on the page view that came before.
Why click triggers matter
They measure the things a website never reports. Tapping a phone number, opening WhatsApp, downloading a price list, following a link to a booking or payment system hosted elsewhere: none of these produce a page the site controls, so without a click trigger they leave no trace at all.
For businesses in Nepal that matters more than it does in markets built around web forms. A great deal of enquiry traffic arrives on a phone and turns into a tap on a number or a chat link, so a site measuring only form submissions is often blind to its busiest route to a customer. Click triggers close that gap without waiting for a development release, which is their other virtue.
Where click triggers go wrong
The first problem is what a click actually proves. It is intent, not outcome. A tapped phone number may be a mis-tap, the same person tapping twice, or a call nobody answered. Recording it is worthwhile; treating it as equal to a completed enquiry, and feeding that to an ad platform’s bidding, teaches the platform to buy the wrong people.
The second is fragility. Conditions built on button wording break when the copy is edited, and conditions built on classes break at the next redesign. Nested markup causes the sneakier version: the click lands on an icon or a span inside the button, so the button’s own class never matches and the trigger stays silent on the one element you meant to track.
Duplication finishes the list. A submit button that is both clicked and followed by a form event can end up counted twice, in two places, with nobody comparing the totals.
How to act on it
Write down the click actions worth measuring, then ask for something stable to hook onto — a dedicated class or data attribute added deliberately to those elements. It is a small request, it survives redesigns, and it removes most of the guesswork from the conditions.
Test on a real device as well as a desktop browser, because tap targets and layouts differ, and check the trigger fires when the icon inside a button is pressed rather than only its edge. Give click events distinct names so reports never confuse them with confirmed enquiries, and keep them as secondary measures in advertising accounts unless you have a way to confirm the outcome afterwards. Where an action really does need to be exact, a custom event trigger pushed by the site is always the sturdier choice.