Custom Events
Custom events are happenings you define because the built-in page view, click, scroll, and unload events cannot express them cleanly — a purchase, a signup, a video complete, a “plan upgraded” signal. In everyday language they are business milestones, not generic page activity. In CROForge you create the event in the Events catalog (name, stable apiName, properties), copy the API snippet onto your site, fire it with the CROFORGE.event queue API after the action really succeeded, then build a metric that listens for that event and attach the metric to campaigns.
Words used on this page
| Word | Everyday meaning | Meaning in CROForge |
|---|---|---|
| Event | Something that happened. | A workspace-owned catalog item you create under Events. Distinct from standard events, which have workspaceId null. |
| Standard vs Custom | Shipped vs homemade. | Use standard events for page view/click/scroll/unload. Use custom events for business-specific conversions. |
| apiName | A stable machine name. | The string you pass as the first argument to CROFORGE.event. Auto-suggested from the display name (snake_case) when you type. Letters, numbers, underscore. Do not rename after metrics exist. |
| Payload | The data sent with the news. | A flat object of property apiNames to values, for example { amount: 150, country: "india" }. Keep it typed and small — do not stuff HTML into properties. |
| Data type | Text, number, yes/no, or URL. | Each custom property is Text (0), Number (1), Boolean (2), or URL (3). Number properties can feed “value of event property” metrics (sum/avg/min/max/first/last). |
| CROFORGE.event queue API | A mailbox that holds calls until the library is ready. | window.CROFORGE = window.CROFORGE || []; then assign CROFORGE.event so each call is pushed as ["event", apiName, payload]. Runtime may also expose window._CROFORGE.event inside init.js. |
| Event property vs Attribute | Fields on a happening vs traits of a person. | Put amount, country, plan name on the event. Put device, UTM, new vs returning on attributes for segments. Metrics filter event properties, not attributes. |
| Metric | A measuring stick. | After the event exists, create a Data Vista metric that listens for that event (plus conditions), then attach it to the campaign. |
| Conversion | The outcome you wanted. | Fire the custom event only after success is confirmed (purchase API returned OK), then let the metric count unique visitors or sum revenue. |
Screenshot filename: custom-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.
When to create a custom event
Create one when standard click or page_view cannot describe the outcome without brittle guessing. “Clicked a button whose text is Purchase” is a click metric. “Order actually placed for $150 in India” is a custom purchase (or similar) event with numeric and text properties. Prefer the custom event whenever you need a number (revenue) or a fact that never appears in the DOM.
Create in the app
- Open Events → create a custom event (display name, stable apiName, optional description).
- Add properties (name, apiName, data type: text / number / boolean / URL, description).
- Copy the snippet from the API tab onto your site. It already uses this event’s apiName and property keys.
- Create a metric in Data Vista that listens for that event, with conditions if needed, and a calculation type (unique visitor, unique session, event count, or value of a numeric property).
- Attach the metric to campaigns.
The recommended product path is still: Add a source (website) → Define events → Run campaigns. Custom events sit in the middle of that path.
Fire from the site
Use the queue stub, then call CROFORGE.event with the event apiName and a flat payload. Example:
window.CROFORGE = window.CROFORGE || [];
CROFORGE.event = CROFORGE.event || function () {
CROFORGE.push(["event"].concat([].slice.call(arguments)));
};
CROFORGE.event("purchase_countrywise", {
amount: 150,
country: "india"
});
The Events API tab wraps the same pattern in a <script> block and fills property placeholders from the catalog. Prefer that snippet. Runtime may also expose window._CROFORGE.event inside init.js once the library is ready; the queue API is what you should paste on the site.
Best practices
| Do | Do not |
|---|---|
Use stable apiNames for the event and every property | Rename an apiName after metrics already listen to it |
| Keep payloads flat and typed (number for amount, text for country) | Stuff huge HTML, PII dumps, or nested objects into properties |
| Fire after success is confirmed (thank-you page, API 200) | Fire on mousedown or “clicked Buy” before the purchase API succeeds |
| Document each property in the description so marketers can build conditions | Leave mystery fields with no description |
Triggers note
A product-level Triggers builder is not a shipped surface in this frontend. You cannot draw “when form submits, fire purchase” inside the CROForge UI. Event firing is via Smart Code standard listeners and/or CROFORGE.event from your site. Leftover editor state such as campaign-executes is not a client feature.
When the custom event fires, Smart Code still matches Data Vista metrics and attaches
[experimentId, variationId]pairs for live experiments — the same runtime path as standard events.