Standard Events
Standard events are the happenings CROForge already knows how to detect: a page was viewed, something was clicked, the visitor scrolled a long way, or they left the page. You do not write those listeners yourself. Smart Code binds them (click, throttled scroll, focus/blur for active time, beforeunload). You still create metrics that listen to these events — often with conditions so “every click” becomes “click on Book Demo.” Exact apiNames and payloads are defined in the Smart Code event catalog and the Events UI; treat the names below as the typical set.
Words used on this page
| Word | Everyday meaning | Meaning in CROForge |
|---|---|---|
| Event | Something that happened. | A catalog item Smart Code can fire. Standard events have workspaceId null / shared. |
| Standard vs Custom | Built-in vs homemade. | This page is the built-in set. Custom events (purchase, signup) are documented separately and fired with CROFORGE.event. |
| page_view | Someone opened (or landed on) a page. | Fired on page load / live-mode init. Payload typically includes page URL, referrer, title, and a device/UTM snapshot. |
| click | Someone pressed a button, link, or similar control. | Document click listener with tag/class heuristics (button, link, input, or .btn). Payload highlights: selector, text, href, tag. |
| scroll | Someone moved down the page. | Throttled scroll; the typical standard event is scroll past about 60% of the page. Used as engagement, rarely as a primary revenue metric. |
| page unload | Someone left the page (closed the tab, navigated away). | beforeunload handler. Payload includes active time duration (focus + visibility tracking). |
| Payload | The data sent with the event. | Property values plus any runtime fields. Exact keys live in the Events UI Properties / Sample Values tabs. |
| UTM | Marketing tracking tags: source, medium, campaign, term. | Often included in the page view snapshot so you can see how the visitor arrived, without putting UTM on every later click payload. |
| deviceType | Phone, computer, or tablet. | Often part of the page view snapshot. Audience filtering still belongs on segments (attributes), not on the event itself. |
| Metric | A measuring stick. | You attach a metric that listens to click/page_view/scroll/unload, then optionally filter with event-property conditions. |
| Conversion | The outcome you wanted. | A click metric with a text/URL condition is the usual conversion for CTA tests. Scroll is engagement, not revenue. |
| Impression | Being shown a variation. | A separate runtime signal that a visitor was assigned/shown a variation. Distinct from page_view and click. Do not treat impression as your primary conversion metric. |
Screenshot filename: standard-events.png. Paste this page into the WordPress Code editor, then insert that screenshot from the Media library. Do not use a Markdown image tag.
Typical standard events
| Event | When it fires (trigger idea) | Payload highlights |
|---|---|---|
| Page view | Page load / Smart Code live-mode init | Page URL, referrer, title, device/UTM snapshot |
| Click | Click on button, link, input, or .btn | Selector, text, href, tag |
| Scroll (>60%) | Scroll past about 60% of the page (viewport heuristic) | Scroll position fields; typically one-shot per trigger id |
| Page unload | beforeunload | Active time duration |
Open each event in sidebar → Events to read the real apiName, property list, and API snippet. Do not guess names in metrics; copy them from the UI.
How Smart Code binds them
Handlers are bound in bindGenericEventHandler:
- click —
documentclick with tag/class heuristics - scroll — throttled scroll (one-shot per trigger id in the sample runtime)
- focus / blur / visibility — accumulate active time
- beforeunload — send the unload / active-time event
Page view–style events fire during live-mode init. A product-level Triggers builder is not a shipped surface in this frontend; you do not draw “when X then fire Y” graphs in the app. Standard listeners plus custom CROFORGE.event calls are the two firing paths.
Tips for marketers
- Use click metrics with text or URL conditions for CTA tests. Unfiltered click counts every matching control on the page.
- Treat scroll as engagement. It is a weak primary revenue metric.
- Unload / active time helps quality-of-session analysis (did people stay and read?), not checkout conversion.
- Page view is useful as a denominator or sanity check (“did they land?”), not as the sole proof that a variation won a CTA test.
Tips for developers
- Confirm page_view fires once on a full load. Soft navigations (SPA route changes without reload) may need extra handling — confirm with engineering.
- A CTA click payload should include recognizable text and href so metric conditions can target them.
- When a metric matches, Smart Code attaches live
[experimentId, variationId]pairs for running experiments.
