A selector that finds the right button is only the start of a tracking rule. It must also exclude unrelated controls and handle the element that actually receives the click. A later layout change can expose an assumption that was invisible during the first check.
Consider a hypothetical report page with an Export button, a nested text label and a separate Help button. The task is to measure export-button clicks. The selector should cover the intended control without treating Help as another export.
Define the action before choosing the element
Write the intended action in plain language before inspecting HTML. For this example, the action is a click within the report-export button. It is not every button click, every download link or a successful completed export. Those are different measurement requirements.
Decide which instances belong to the same action. A desktop button and a mobile copy might both qualify. A similar button in another report might require a different parameter. There is no universal rule that a good selector must match exactly one element. The expected set must come from the requirement.
A CSS selector describes elements in the document. It does not establish that the application accepted the action. Google’s click-trigger documentation distinguishes All Elements triggers from Just Links triggers. A real button belongs in the former category; Just Links targets HTML links that use the a element.
Prefer an agreed attribute over a layout position
A generated selector can describe where a button happens to sit, rather than what it does. A long chain of containers or an nth-child position can change when another panel or control is inserted. A styling class can also change during a redesign. Inspect what each selector component depends on.
