Skip to content

Tracking and Number Routing

Jump to bottom
Shane Rounce edited this page May 10, 2026 · 3 revisions

Tracking and number routing

This is the core of the plugin.

I want Adaptive Customer Engagement to capture useful first-party signals without becoming invasive or fragile.

What gets tracked

The public tracking endpoint accepts these event types:

  • pageview
  • click_to_call
  • download
  • form_submit
  • chat_start
  • chat_message

In practice, the current build is centred on pageviews, click-to-call events, downloads, and optional native form submissions.

Session model

The plugin keeps a first-party session UUID and visitor UUID so I can follow journeys over time without leaning on third-party analytics platforms.

Each session can include:

  • landing path
  • first URL and referrer
  • UTM values
  • location and provider data where enrichment is enabled
  • linked company data where that match exists
  • engagement events and commerce-interest metadata

Number routing model

Numbers are stored as rules, not just contacts.

Each number record can include:

  • a label
  • a display number
  • an E.164 number
  • source-type and source-value matching
  • page-match type and value
  • campaign matching
  • default and active state
  • priority
  • Amazon Connect phone number and contact flow identifiers

How resolution works

The public number resolver looks at the current request context and returns the most appropriate active number.

That context can include:

  • current path
  • UTM source
  • UTM campaign

The result comes back with:

  • internal number ID
  • display number
  • E.164 number
  • label

Recommended number setup pattern

I generally treat number setup like this:

  1. create one clean default number as the safe fallback
  2. add campaign-specific numbers where I need tighter attribution
  3. add page-matching rules only where they are meaningful
  4. keep priorities deliberate so overlap is easier to reason about
  5. store Amazon Connect identifiers early, even if the live integration is not switched on yet

The current build also lets me see the live Amazon Connect numbers already claimed in the connected instance and pull one into a local routing-rule draft from the same admin setup surface.

Frontend placeholders

The normal placeholder pattern is:

<span data-ace-phone="default">Loading…</span>
<a href="#" data-ace-phone-link="default">Call us</a>

That lets the frontend script replace the public number without hard-coding multiple copies through a theme.

Call tracking position

Call data is already part of the plugin model through the ace_calls table and the calls reporting surface. The full Amazon Connect import and matching workflow is still a later phase, but the schema and setup screens are already there so I do not have to retrofit them later.

Sample/demo numbers are also deliberately excluded from live number resolution, so I can keep seeded preview data around for admin work without risking it taking over the public-facing fallback number.

Clone this wiki locally