A tracking plan defines what an event means before anyone adds the SDK call or builds a report. Use it to keep the product team, developers, and report owners working from the same definitions.

Start with the decision

Write down the question your report should answer. For example: “How many people create their first workspace after signing up?”

Then define the actions required to answer it. A click on Create workspace is not equivalent to a successfully created workspace. Choose the successful product outcome when that is what your report should measure.

Fill in one row for each event

Keep this plan in a document or spreadsheet your team maintains. The table is a planning template, not an import file for Userorbit.

Field Example
Business question Do signed-up people create a workspace?
Event title Workspace Created
Code key workspace_created
Exact trigger Workspace creation succeeds and the application confirms success.
Do not fire when Validation fails, the request fails, or the person cancels.
Identity Stable application user ID after authentication.
Expected count One event for each successful workspace creation.
Profile fields needed Subscription tier, only if the analysis requires it.
Prohibited data Workspace names, free-form content, credentials, payment details.
Owner The team responsible for workspace creation.
Verification One success appears once in Live Events; failure appears zero times.
Report owner The person maintaining the activation report.

Add a review date and the release containing the change. If more than one application performs the action, record which applications use the definition.

Match the plan to Userorbit's event model

Create a Code event in Events before using its key in track(). The title is the readable label; the key is the exact string in code and the name sent to Analytics.

Choose stable keys, such as workspace_created and invite_sent. Do not create a different key for each customer or insert a changing value into the key. The code-event key is read-only when editing an existing event in the current UI.

The browser track() call does not accept arbitrary custom Analytics properties. Its typed hiddenFields option is not forwarded as custom Analytics event properties by the current code-event path. Do not plan a report around per-event fields until you have confirmed how those fields will be collected.

Profile attributes describe a person and can change. They should not automatically be treated as a snapshot of a value at the moment of every event. Verify the report's behavior if a historical analysis depends on changing fields such as subscription tier.

Implement and validate

  1. Create the code event with the agreed title and key.
  2. Initialize the browser SDK once and identify the person when required.
  3. Call track() only after the defined product action succeeds.
  4. Open Analytics → Live Events in the intended project.
  5. Test one successful action, one failed action, and an action performed twice intentionally.
  6. Check identities, counts, and the event key before building the report.

Test the flow after a reload and a client-side route change. For applications with multiple customer accounts, include tenant switching. For shared devices, validate sign-out and a second person's sign-in separately.

Use How to set up event tracking for the setup steps and SDK Troubleshooting Reference if an event is missing or duplicated.

Build a report from validated events

Choose a report that fits the original question. An Insights report can show the volume of an action over time. A Funnel can show progression through a defined sequence. Retention can examine return behavior after an initial action.

Check the selected project, date range, and filters before interpreting the result. See Choose an analytics report type.

Maintain the definition

When a product flow changes, review the corresponding tracking-plan rows. Avoid reusing an existing key for a materially different behavior without documenting the change and its effect on historical comparisons.

After release, compare received events with a small set of known actions. Investigate unexpected changes before attributing them to customer behavior. Keep the definition, implementation owner, and report owner current so the next person can tell what the numbers represent.

Was this helpful?