Continental DivideTracking governance

How to use this

Continental Divide is where a team agrees what its product records. You ask for an event in plain words, fixed rules check it, a person approves it, and it joins the tracking plan with code for engineers. In this demo you play every part.

What a tracking plan is

A tracking plan is the agreed list of what a product records about how people use it. Each entry is an event, named for something a person did, like Product Added or Order Completed. Its properties carry the details, like the product's price.

Engineers read the plan to know exactly what to send. Analysts read it to know what each number means. Without one, the same action ends up tracked three ways under three names, and nobody trusts the dashboards built on it.

The plan here belongs to a sample online store, based on Segment's public Ecommerce events. Events you request and approve join it. Open the tracking plan.

How a request moves

  1. Ask

    You're the requester

    On New request, describe in a sentence what someone did and why it matters. Not sure what to write? The guided request asks one question at a time, and Try a scenario fills the form for you.

  2. Check your draft

    You're the requester

    A model turns your sentence into a named event with properties. Fixed rules then check the name, the category, personal data, and whether the plan already has it. A name that breaks the convention is rejected, and you're offered one that passes. Personal data and duplicates are never rejected: they're flagged for a person to look at. A model also looks for events that mean the same thing; it can point one out, but it never rejects. Nothing reaches the approver until you submit.

  3. Decide

    You're the approver

    Open the Queue. Requests waiting on a decision come first. Read the checks, then approve or reject. Personal data and likely duplicates each need a tick before Approve works.

  4. See the result

    An approved event is published. It joins the tracking plan, and the request shows engineers the Segment code to send it, for the browser, the server, or both.

  5. Look back

    Every step is written to the request's audit trail, which nothing can edit. Open any request from the Queue to read its trail.

Three runs worth trying

Each is a tile under Try a scenario on New request.

A clean request
Fills the form. Add your name and team, draft it, submit it, then approve it from the queue. The draft should pass every rule, and the event joins the tracking plan.
A badly named event
Skips the model. The event name rule rejects it, and you're offered a name the convention accepts, or a way to dispute the rule.
An event that already exists
Skips the model. It goes straight to the queue, where the approver has to acknowledge the duplicate before approving.

On the public demo

  • Your sandbox is private to this browser. There's no sign-in, and nobody else sees your requests.
  • A sandbox holds 5 requests, made either way: drafted by the model or from a scenario that skips it.
  • Drafting shares one daily model budget across every visitor. If it runs out, the scenarios that skip the model still work.
  • Nothing is sent to Jira, Confluence or Notion. A published request shows what a connected setup would write.
  • Every approval is recorded as a self-approval, because you made the request you're approving. In a real team, someone else approves.
  • A sandbox unused for 7 days is deleted, with its requests and audit trail.

Words you'll see

Event
Something a person did, named Object Action in Title Case, like Order Completed.
Property
A detail sent with an event, like an order's total.
Where it happens
In the browser or app means on the person's own device. On our servers means your backend records it. Engineers call this the surface: client side or server side.
Draft
A request that passed the rules but that you haven't submitted yet. It's in nobody's queue.
Pending approval
Submitted, and waiting on the approver.
Published
Approved and written out: it's in the tracking plan.
Rule check
One of the fixed rules every draft is checked against. A failed name or category rule rejects the request. Personal data and duplicates are flagged for a person, never rejected, and a model never rejects.
Duplicate
An event the plan may already have. The rules catch the same name, or the same name written differently; the duplicate review is a model reading whether one means the same thing under another name. A person decides what to do about each.
Governance profile
The conventions, categories and personal-data list requests are checked against. See it under Governance.