Skip to main content
Once the Tag is installed, call:
The general event command accepts custom event names. Use the standard taxonomy for consistent reporting; OpenAI delivery also requires a matching configured event map. Purchase aliases use the validated purchase path described below.

Standard events

The category column describes event data used for measurement. Purchases have validated order fields; supported leads and registrations use customer_action data and their own submission identities.

Examples

Leads and signups

Use a stable opaque identity from each completed submission, without customer details. Reuse the same event_id when reporting that submission again; use a new ID for a different submission. No order_id, value or currency is required.
For OpenAI measurement, configure mappings to lead_created and registration_completed. Existing names such as lead and signup require matching configured mappings. The tag supplies customer_action event data. Signed Thrad and OpenAI source context are retained when available. An organic event with no supported attribution context is not submitted by this tag.

Event properties

General events may carry additional properties. Supported measurement fields are normalized by the tag and collector; avoid assuming every property is forwarded unchanged to a measurement provider. That said, using consistent property names across your site makes the data much easier to slice in reporting. Common conventions you’ll see in the examples above (content_id, quantity, value, currency, form_id, …) are conventions, not requirements. For a completed purchase, use Track purchases. The conversion command and purchase aliases such as order_created, purchase and checkout_completed share the canonical purchase path: final order_id, nonnegative value and three-letter currency are required. A lead or signup must not be sent as a purchase just to obtain attribution.