Event Tracking & Analytics

The site has its own lightweight, first-party event layer provided by the analytics system (the yax-analytics mu-plugin). It records what visitors do on the site, enriches every event with context about where it happened and forwards events to any external analytics destinations that are present and consented.

How it works

Events are fired declaratively (data-track attributes), automatically (link-intent and form detection) or programmatically (window.wha.track()). Each event is enriched with context and dispatched to every detected adapter.

Adapters

The yax-analytics plugin ships five adapters and auto-detects each at runtime; an adapter only sends when its destination is present (and, for third-party adapters, consent is granted). WHA explicitly disables two of them (see below), so three are live:

Third-party adapters only fire when the visitor has granted analytics consent via window.yaxConsent.hasConsent('analytics'). If the cookie-consent plugin is not active, consent is assumed. The local adapter is first-party and always records, so we retain on-site visibility regardless of consent state.

GA4 and Meta are downstream of FreshPaint, not direct adapters. FreshPaint is the tag layer: the site sends named events to FreshPaint, which forwards them to GA4 and the Meta Pixel. The plugin also ships GTM/GA4 (dataLayer) and Umami adapters, but WHA disables both through the yax_analytics_disabled_adapters filter in the theme's functions.php.

Auto-tracked events

These fire automatically, with no per-element annotation. Every event also carries the page context below.

Link-intent auto-detection

For un-annotated links, analytics.js infers a cta_click type from the href. It only covers universal intents so the shared plugin stays generic across sites:

Site-specific intents (scheduling, the patient portal, find-a-provider and so on) aren't guessed here. The theme stamps those explicitly with data-track (see btn.php).

Links that match no intent fall through to outbound_click (external host) or file_download (document extension).

Event context

Every event is enriched so you know where it happened. Precedence is explicit props → element context → page context (most specific wins).

Page context (server-side)

Injected by class-enqueue.php and merged into every event. Public, non-PII identifiers only.

Element context (client-side)

Captured from the clicked element and its ancestors.

Any component can scope the interactions inside it with a context wrapper, for example a provider card:

<article data-track-context="provider" data-track-context-id="1234">
  …
  <a href="tel:+15035551234">Call this office</a>
</article>

A phone click inside that card fires:

{
  "type": "phone_call",
  "label": "Call this office",
  "context": "provider",
  "context_id": "1234",
  "post_type": "wha_providers",
  "page_type": "single",
  "lang": "en_US"
}

Adding tracking

There are three places to add tracking, most robust first: in the theme (code, below), in wp-admin (a per-menu-item toggle), or in FreshPaint (URL and click rules). Prefer the highest one available: named events in code carry page and element context and survive redesigns.

<a href="/providers/" data-track="cta_click" data-track-type="find_provider">
  Find a Provider
</a>

<section data-track-impression="section_viewed" data-track-section="hero">…</section>

<article data-track-context="location" data-track-context-id="42">…</article>

window.wha.track('event_name', { key: 'value' });

Adding tracking without code

Not everything needs a deploy. Two no-code paths feed the same pipeline.

In wp-admin (menu items)

Nav menu items can fire an event on click with no code. In Appearance → Menus, expand a menu item and set:

• Track Clicks — toggle on to send an analytics event when the item is clicked.
• Event Label — optional. Becomes the event type (e.g. schedule_appointment, bill_pay); defaults to the menu item slug.

This fires a nav_click event with your label as type, dispatched to every detected adapter like any other event.

In FreshPaint

FreshPaint can define an event from its own UI, on a URL or click/href rule, with no deploy. Use it for a page or intent the theme doesn't already emit a named event for. Where a named event exists, prefer it: it carries context and won't break on a redesign, whereas selector- and URL-based rules can. To turn any event into a GA4 key event or Google Ads conversion, see Conversions.

Relationship to FreshPaint and conversions

Because window.wha.track() forwards named events to FreshPaint (when consented), conversions can be defined on stable, named events rather than fragile CSS selectors or exact-URL pageview matches.

Conversions themselves are defined in FreshPaint (and downstream in GA4 / Google Ads), not in this layer. The site's job is to emit clean, named events; which of those count as a conversion is configured in FreshPaint.

What the events do and don't measure

A few boundaries worth knowing before reading these as outcomes:

• schedule_an_appointment_complete is a booking handoff, not a confirmed appointment. It fires when the wizard hands the visitor to MyHealth (it opens the MyHealth URL). The actual appointment is booked on MyHealth, a separate system on another domain. Treat it as "reached the booking handoff," a strong intent signal, not a booked visit.
• No cross-domain tracking into MyHealth. The session ends at the handoff; what happens on MyHealth (completed, abandoned, rescheduled) is invisible to this layer and to FreshPaint/GA4. Measuring true booked appointments needs data from MyHealth itself.
• Phone and directions are click intent, not outcomes. phone_call / directions record that someone clicked, not that a call connected or a visit happened.

Consent

Consent is enforced at the adapter layer: third-party adapters only send when window.yaxConsent.hasConsent('analytics') is true (opt-in by default via the cookie-consent plugin; assumed if that plugin is absent). The first-party local log always records.

This is custom upstream gating, not Google Consent Mode; there are no gtag('consent', …) signals. Consent is applied by allowing or blocking whole adapters before they fire, rather than by passing consent state into Google's tags.

Viewing the data

Page views are reported as total, not unique: there's no visitor deduplication.

Storage

Two custom tables, created automatically:

• {prefix}_yax_analytics_counts: compact aggregate daily counts per event.
• {prefix}_yax_analytics_log: rolling event log with properties (JSON), URL, user ID, timestamp. Capped at 5,000 rows (oldest pruned).

Reference

• Plugin source: mu-plugins/yax-analytics/ (assets/js/analytics.js, includes/class-enqueue.php, includes/class-rest.php, includes/class-db.php)
• Button auto-detection: wha2025/components/ui/btn.php
• See also: Plugin System, Editing Basics