> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/define-your-tracking-plan.md).
# Define your tracking plan
Decide which events and properties each property sends, before anyone writes tag code.
## Your goal
Agree the exact list of events and properties each site and app will send, so that the people implementing the tag and the people querying the data are working from the same document.
## Expected outcome
A plan that names, per channel: each event, its name, its properties, the identifiers sent with it, and the use case it serves.
## Where to start: the events that already mean something
Do not design event names from scratch. Start from the [predefined event names and properties](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/standard-events.md), because they are what the platform's automatic processing keys off, and only invent a name when nothing standard fits.
For an e-commerce journey, the recommended placement is fixed:
| Page | Event | Properties |
| ------------------------------- | ------------------------ | --------------------------------------------------------------------- |
| Home page | `$home_view` | - |
| Category or search results page | `$item_list_view` | `$items` - **only the first 3 items** in the list should be declared |
| Product page | `$item_view` | `$items` with one product |
| Basket page | `$basket_view` | `$items` with `$id`, `$price`, `$qty`; `$currency` |
| Transaction confirmation page | `$transaction_confirmed` | `$items` with `$id`, `$price`, `$qty`; `$transaction_id`; `$currency` |
A list of products is always attached with the reserved property `$items`.
* `$id` is the product ID. On `$transaction_confirmed` it should be **the same ID as the one used in your product feed**.
* `$price` holds the product price **without** the currency.
* `$qty` holds the quantity of that product.
* `$currency` is optional - with a single catalogue, the catalogue currency is used by default.
## Decide these things per event
{% stepper %}
{% step %}
### Which channel it belongs to
An event is attributed to a channel through `$site_id`, `$app_id`, or `$ctv_id`. A distinction you cannot make with channels is one you will not be able to query. See [Channels](/setup-and-monitor/plan-and-integrate/set-up-the-environment/set-up-channels.md).
{% endstep %}
{% step %}
### Which identifiers travel with it
At minimum a device identifier; wherever the user is known, an account ID with its compartment, or an email hash. This is the decision that determines how much of your data consolidates per person. See [Resolve identities](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/resolve-identities.md).
If you have a unique identifier for the user, send it - tracking without it is materially less useful.
{% endstep %}
{% step %}
### Which properties, and no more
{% hint style="warning" %}
Sending too many properties creates confusion when people have to decide which property to query. **Only send what you know is required.**
{% endhint %}
Each property in the plan should point at a use case. Properties with no use case are noise in the segment builder for years.
{% endstep %}
{% step %}
### Whether it must be queryable
A property is only usable in a `WHERE` clause if it is indexed in the schema. Decide this in the plan, not later - adding an index later only covers data arriving after publication. See [Schema definition](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/schema-definition.md).
{% endstep %}
{% step %}
### Where the value comes from
The page's JavaScript, the data layer, or a server-side call. If the same value exists in the data layer already, prefer reading it there - see the one-tag approach in [Web tracking](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/web-tracking.md#the-one-tag-approach).
{% endstep %}
{% step %}
### Its unique key convention, if you generate keys
Needed for imports and corrections. See [the activity unique key](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time.md#the-activity-unique-key).
{% endstep %}
{% endstepper %}
## Traps to write into the plan explicitly
| Trap | What to write instead |
| -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Using `$page_view` to record page history | `$page_view` events are **dropped when the session closes**. They are useful to test that events arrive, and nothing else. Use a custom name, or `$item_view` if the pages show products. |
| Inventing an event name where a standard exists | Custom events are not counted in built-in analytics, dashboards, or funnels. |
| Sending a property that an event rule or analyzer will rewrite | Anything that must reach storage untransformed - Edge-available properties in particular - must not pass through a rule or an analyzer. |
| Assuming the tag can send anything | **Activities are limited to 8,000 characters.** |
| Forgetting consent | The cookies used by the tag are considered advertising cookies. **You must obtain user consent before using it.** |
## What the tag already sends
By default the tag already collects the **URL, the referrer, the user agent, and the time**. There is no need to add them to your plan as properties.
## Verify
* Every event in the plan has a name, a channel, an identifier strategy, and a use case.
* Every property in the plan is either indexed or knowingly not queryable.
* The predefined equivalent is used wherever one exists.
* After implementation, one real user's activities read the way the plan describes. See [Explore a user profile](/setup-and-monitor/operate-and-monitor/explore-a-user-profile.md).
## Related pages
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.mediarithmics.io/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/define-your-tracking-plan.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.