Web frameworks

This site is built in four web frameworks. Each page documents its own events.

For each web framework, how is the same site served?

Web framework	URL	Represents
Traditional	/button.html	Server-rendered, multi-page sites (WordPress, Drupal, storefronts); every click loads a new document and reboots the pixel
SPA /{path}	/button	History-mode SPAs (modern React default). URLs are formatted like /button, with no .html extension. No such extensionless file exists, so CloudFront returns the SPA shell (spa.html), which renders the appropriate page.
SPA /#/{path}	/spa.html#/button	Hash-routed SPAs (Vue hash mode, React HashRouter)
SPA /#!/{path}	/spa.html#!/button	Hashbang SPAs (AngularJS lineage)

Signals which Trigger Page-Change Evaluation

Five signals make the pixel evaluate whether an effective page change occurred. Only select URL changes matter — path, query string, or a route-style hash — anchor jumps do not.

For each web framework, how do you fire that signal?

Web framework	Full page load	hashchange event	history.pushState()	history.replaceState()	Back / forward (popstate event)
Traditional	click any link	[negative example] click an anchor link	—	—	— (browser Back arrives as another full page load)
SPA /{path}	arrive from outside, or refresh	—	click a nav SPA /{path} link, or a green button	green button	browser Back / Forward
SPA /#/{path}	arrive from outside, or refresh	click a nav SPA /#/{path} link	green button	green button	browser Back / Forward
SPA /#!/{path}	arrive from outside, or refresh	click a nav SPA /#!/{path} link	green button	green button	browser Back / Forward

1. The green buttons change the current URL in place — same page, bumped ?page=N — the way SPAs write pagination and filter state into the query string. They appear here and at the Scroll page's 50% and 75% markers, and only work when the page is served from a SPA row: pushState ?page=N replaceState ?page=N
2. [negative example] Clicking a link to the page you're already on: Traditional reloads the document — a page_view fires, since the page is re-presented. The SPAs change nothing and fire nothing — no presentation occurred. The click is captured as link_click in both. page_view counts presentations, not gestures; this is the same line GA4 draws.

Deanonymization

Deanonymization is not an event type. It is a downstream service, run in conjunction with the pipeline's enrichment step, that links an anonymous visitor to a known contact. The pixel's role is only to carry the identifying inputs.

Which inputs trigger deanonymization, and where do you generate them?

Input	Carried by	Generate it on
sys_id in the URL's query string	query_params, on a page_view event	Deanon (sys_id) page
Email address	form_submit form_values	Form + Deanon page, email forms
Phone number	form_submit form_values	Form + Deanon page, phone forms

Two rules to consider when testing.

1. Enrichment caches resolved visitors and skips them — to test again as a fresh anonymous visitor, use Clear Visitor ID in the nav.
2. Form triggers respect a form-ID allowlist in config: the sandbox form IDs must be on it — an empty allowlist disables form deanonymization entirely.

Not covered

A green sandbox does not prove: pixel behavior within real framework runtimes (React/Vue internals, including SSR hydration — possible separate effort), or third-party embeds (Jotform, Typeform, etc.).