Governing AI-generated analytics with your tracking plan

You have a tracking plan — maybe in a spreadsheet, maybe in another tool, maybe just conventions people try to keep in their heads. The problem isn’t that it doesn’t exist; it’s that it isn’t governed (nothing stops inconsistent names, duplicates, or events that ignore your conventions) and it isn’t connected to your implementation (the code is written by hand from a doc that drifts). AI coding agents make both worse: they generate tracking fast, with no shared plan to follow and no memory of what already exists, so each one invents its own names and the code drifts further from the plan.

Avo governs that plan and connects it to your code. It doesn’t matter whether your plan is already in Avo — getting it in is a quick, two-step import (below), and from there everything is the same. Avo doesn’t rewrite your existing code for you; it surfaces what’s already inconsistent and stops new drift at the source.

Your tracking breaks down in two places: what gets designed (names, duplicates, conventions) and whether the implementation matches the plan. Avo addresses both — with different machinery for each.

Problem 1: Bad event and property design

Left to design analytics on its own, an agent proposes event and property names that are inconsistent or non-standard, descriptions that are missing or machine-generated and unreadable, events and properties that duplicate ones already in your plan, and structures that ignore the naming patterns your team has established. Concretely:

• Inconsistent names (signup vs Sign Up vs user_signed_up) — no awareness of your conventions.
• Non-human-readable or absent descriptions — impossible to maintain without context.
• Duplicates of events and properties that already exist — the agent has no memory of what’s in the plan.
• Structures that don’t follow your team’s naming conventions — each agent invents its own patterns.

How Avo fixes the design problem:

• A shared tracking plan as the source of truth. One plan for every event and property, so the agent reuses existing definitions instead of inventing new ones. (See What is a Tracking Plan?.)
• Audit rules that enforce consistency by construction. The Tracking Plan audit checks names against your conventions and flags duplicates and inconsistencies automatically — see the configurable audit rules. This is the mechanism that prevents bad design from entering the plan.
• The Avo MCP reads your rules and plan before proposing anything. When your agent uses the Avo MCP, it reads your workspace’s audit rules and searches for reusable events and properties before proposing anything new — so design is rule-following, free of duplicates, and consistent by construction.

Problem 2: Implementation that drifts from the plan

Even a well-designed plan can go wrong in implementation: misnamed events, missing or wrongly-typed properties, code that never quite matches the plan. This shows up in two common workflows:

• Single-pass dev or agent. One developer (or one agent) designs and implements in a single pass, with no checkpoint between design and code. Design mistakes and implementation mistakes compound, and there’s no moment where the design is reviewed before the code goes in.
• The spec lives somewhere disconnected from the code. The tracking gets written up in a doc — a Google Sheet, a Notion page, a ticket — often by a PM (or an agent), and a developer (or agent) implements it by hand from that doc. Nothing links the spec to the implementation: it’s copy-paste, so names get mistyped, properties get missed, the doc goes stale, and the code quietly drifts from what was specified.

How Avo fixes the implementation problem:

• The plan in Avo is the single source of truth, directly connected with implementation — not a doc on the side. Every event and property lives in Avo; the developer (or agent) builds from the plan, not a static document that drifts. (See What is a Tracking Plan?.)
• Auto-generated branch implementation instructions keep design and code in sync. Every branch in Avo generates implementation instructions and per-source code snippets, so the developer knows exactly what to implement — see branch code changes. The MCP can return these snippets directly in your agent’s context.
• Avo Codegen generates type-safe tracking functions. For supported sources, Avo Codegen generates typed wrapper functions directly from the plan — so the implementation is generated from the definitions, not hand-copied from a doc, and cannot drift from the plan because the compiler enforces it. Set up Codegen. (For sources not on Codegen, use illustrative snippets plus Inspector validation.)
• Inspector surfaces discrepancies between live tracking and the plan. Inspector observes your live event stream and flags events that don’t match the plan — catching drift for any source, whether or not it uses Codegen.

Before and after:

• Before Avo: the agent designs and implements in one pass (or the spec lives in a separate doc and a developer copy-pastes from a stale version) → inconsistent names, duplicates, and code that doesn’t match the plan → analysis breaks downstream.
• With Avo: the agent reads your rules and reuses from the plan → proposes events on a branch → you review and approve the definitions → the agent implements them with the code Avo generates from those definitions (or Inspector validates manual instrumentation) → you merge the branch → consistent, governed tracking that matches the plan ships.

The change isn’t that your agent stops generating tracking — it’s that every proposal now passes through a plan, an audit, and a human before it counts, and the implementation is verified against the plan.

Give your agent the tracking-plan skill

Once your plan is in Avo, the avo-mcp skill is the most direct way to keep your agent from drifting off it. It’s an Agent Skill that teaches your agent to work within your plan through the Avo MCP: look up and reuse existing events, properties, and metrics; design tracking for a new feature against what already exists; and propose changes on a branch instead of inventing new, inconsistent tracking.

• It reuses before it creates. The skill searches the plan for an existing event or property before proposing a new one — preventing duplicates at the source.
• It follows your rules. Proposals are shaped by your audit rules, so names and structure match your conventions.
• It stays on a branch. Everything lands on a branch and merges only when you approve.
• It follows the Avo workflow. The skill runs inside the Avo workflow — an extra harness that keeps it doing the right things in the right order, and pulls a human in whenever it’s unsure.

Get your tracking plan into Avo

If your plan isn’t in Avo yet, getting it there is quick:

1. Create a workspace via the Avo onboarding flow.
2. Import your existing tracking plan — the fastest way is through the Avo MCP. With the Avo MCP connected and the avo-mcp skill added, ask your agent to import your plan from wherever it lives today — a spreadsheet, another tool, or an analytics platform like Amplitude or Mixpanel. Prefer to do it by hand? You can also import it in the Avo web app once the workspace exists.

From there everything is the same whether you imported a minute ago or have been on Avo for years: your agent designs within the plan — governed by your audit rules and implemented from generated code, on a branch you approve.

Starting a project with no tracking plan at all? See Setting up a tracking plan for AI-generated analytics.

Related

• Adopting Avo with AI agents — back to the section overview.
• Agentic data design — Avo’s in-app AI suggestions for designing tracking.
• What is a Tracking Plan audit? and audit rules.
• Avo Codegen overview — type-safe generated tracking for supported sources.
• Start using Inspector — validate live tracking against the plan.