A click can reach the right element while the tracking callback runs twice, runs too early, or never runs. Changing the GTM trigger cannot repair every listener problem. First check how the browser event reaches the code and who owns that code’s installation.
Define what the listener can observe
Consider a hypothetical resource page with download links. The tracking requirement is one download_link_clicked event for each activation of a marked link. The link can contain text and an icon. Its data-download-id attribute supplies the reporting identifier.
This measures an interaction with a link. It does not establish that the server returned the file or that the visitor saved it. If the requirement is a completed export, use the application state that confirms completion. A listener should not turn an attempted action into a successful business outcome.
Before adding code, check whether the application or an existing GTM configuration already measures the same interaction. Two independent implementations can each work correctly and still produce duplicate events.
Follow the event through the page
For an ordinary bubbling click, capture listeners on ancestors run before the target phase. The event can then bubble through ancestors. MDN’s event bubbling guide explains this path. A parent listener can therefore observe clicks from its descendants without a separate listener on every link.
The clicked object and the listener’s attachment point are different concepts. The target property identifies the event target. The currentTarget property identifies the object whose listener is running. A click on an icon inside a link can target the icon. A document listener’s currentTarget is the document, not the download link.
