The path a conversion takes
Last updated Nov 5, 2026
What a conversion path declares — each conversion, its stable identifier, and the steps expected before it — and what happens when you change one.
The conversion path tells TraceLog which events to expect. For example: view a product, add it to the cart, start checkout and complete a purchase. You define it when you create the project, and TraceLog checks your installation against it, first to verify it and later to notice when something stops arriving.
What the path declares
For each conversion:
| Field | What it is |
|---|---|
| Type | One of purchase, lead, booking, signup, subscription, request, donation |
| Event name | The name your code sends, in the event-name form |
| Stable identifier | What accompanies every conversion — an order number, lead id, booking reference |
| Value and currency | Optional, and declared together |
| Steps | Optional: the ordered events expected before the conversion, in one session |
| Primary | Exactly one conversion in the path is marked primary |
The primary conversion is what a bare "conversion rate" means and what the Monday digest — the weekly email about the project — leads with. The others are captured and checked in the same way.
Why declare steps
Steps are optional. Without steps, a step of your funnel can stop arriving while the conversion keeps arriving, and nothing notices. With no steps declared, each conversion reported by the browser also carries a warning that no step came before it in the session.
The stable identifier
It lets TraceLog count each conversion once. Verification is blocked if the identifier is missing, or if the same identifier arrives with conflicting data; an identifier that comes back with another value on fewer than 1 in 100 of a day's conversions only warns. Use the order, lead or booking ID your system already assigns, not a random id created in the browser, and keep it when you resend the same conversion:
A conversion arrived without its stable identifier. Send the declared stable identifier with every conversion event.
Give each conversion its own identifier, and always send it with the same value and currency.
A conversion's identifier, such as its order number, arrived again with a different value. Check that each identifier belongs to one conversion and is always sent with the same value.
It is also what lets browser and server evidence of the same outcome reconcile into one conversion — see the server API.
Templates
Creating a project picks a template from the conversion type and fills the
path in. A purchase, for example, arrives declared as view_item,
add_to_cart, begin_checkout, then purchase identified by the order
number with a value. The WooCommerce plugin, the PrestaShop module and the Shopify app declare the same
template themselves, naming the identifier as their platform does — the order
number, the order reference and the order id — so a project created from them
already has its path.
On a script or npm install, edit the path afterwards to match your own funnel. On WooCommerce, PrestaShop and Shopify the path comes from the plugin, module or app and is not edited.
Versioning
Each change creates a new version of the path. TraceLog checks against the new version from then on, and each alert states the version in force when it was raised. A step you rename on purpose is not reported as a fault.
Changing the path safely
- Ship the code that sends the new names first.
- Edit the path once the new events are arriving.
- Watch the Installation and keys page verify against the new version.
If you edit the path before the code, the project shows Events are arriving: events arrive, but a declared element has not been seen, and TraceLog tells you which one.
Trigger the declared conversion and check that its event is sent after the preceding steps.