Standard events
The category column describes event data used for measurement. Purchases have validated order fields; supported leads and registrations usecustomer_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 sameevent_id when reporting that submission again; use a
new ID for a different submission. No order_id, value or currency is required.
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.