The tracking plan
What a plan declares — each conversion, its stable identifier, and the steps expected before it — and what happens when you change one.
The tracking plan 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 a plan 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 plan is marked primary |
The primary conversion is what a bare "conversion rate" means and what the digest 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. 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:
Send the declared stable identifier with every conversion event.
Use one stable identifier for one conversion record and keep its value consistent.
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 plan
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 Shopify app and the WooCommerce plugin declare the same
template themselves, so a project created from them already has a plan.
On a script or npm install, edit the plan afterwards to match your own funnel. On Shopify and WooCommerce the plan comes from the app or plugin and is not edited.
Versioning
Each change creates a plan version. 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 a plan safely
- Ship the code that sends the new names first.
- Edit the plan once the new events are arriving.
- Watch the Installation page verify against the new version.
If you edit the plan before the code, the project goes into receiving:
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.