A new landing page ships. The signup button moves. Someone asks whether the new placement helps. Suddenly the next tiny task is another event call, another review, and another deploy.

Owleye Analytics's tracking rules are designed for that moment. They let you configure supported browser interactions in the console after one installation of the rules SDK. The promise is fewer repeat instrumentation deploys, not a website that installs its own analytics by magic.

## Start with a question, then a selector

Say you want to measure clicks on an existing button with `id="signup-button"`. An owner or admin creates a click rule named `signup_clicked`, sets `#signup-button` as the selector, and enables it. Leave text capture off unless you have a specific reviewed need for it.

The optional rules entrypoint fetches the site's enabled catalog when it initializes. It matches interactions in the browser and sends bounded events to the ingestion API. For this workflow, changing the event rule no longer means editing the site source.

There is a timing detail worth spelling out: saved rules reach a visitor on the next rules SDK initialization, usually a new page load. An already open tab keeps its catalog. Reload your test page after saving a change before deciding the rule is broken.

## What still needs code

If a button has no stable selector, adding an ID or data attribute is still a site change. If a checkout must be counted only after a backend confirms payment, a browser click is the wrong signal. Send an explicit application event at the actual success point instead.

Rules configure supported click, submit, and visibility behaviour. They are not remote JavaScript execution, a replacement for your business logic, or a way to reconstruct last week's uncollected events. Changing a selector also changes what the metric means, so keep event names stable when you want a useful comparison over time.

## Privacy is part of the event design

A selector can point at useful UI or at a field full of personal information. Choosing one does not make its contents safe to collect. Prefer named actions and small categorical properties. Avoid free text, emails, account identifiers, and generated selectors that embed user data. Test the payload in the Network panel before trusting the dashboard.

The SDK's cookie-free defaults and bounded fields reduce collection. They do not decide your lawful basis or absolve a team from explaining what it measures.

## Check the result, not just the status code

Confirm the event name and site ID, inspect the ingestion response, and find the event in the console. Inspect accepted and dropped counts rather than assuming an HTTP 202 means every submitted event was stored; a monthly allowance can limit acceptance. The SDK applies its privacy controls before sending, while the ingestion API does not suppress events solely because of DNT or GPC headers. Page views, custom events, and rule events count toward billable usage; verified bot views, page-duration records, and performance telemetry do not.

The [quickstart](/docs/quickstart/) walks through installation and verification. The [rules reference](/docs/rules/) covers the available controls. [Start free](https://app.owleye.dev/) with one supported interaction, then build a funnel toward a confirmed signup. Find the step that needs attention before choosing the next change.