# Find broken product analytics events before trusting a funnel
> Compare an agreed tracking contract with analytics taxonomy, event data, and existing engineering work before making product decisions.
Canonical: https://www.mcpfolio.com/workflows/audit-analytics-events-against-tracking-contract
## Target user

Product manager and analytics engineer at a SaaS team whose event names, user IDs, or properties have become unreliable.

## Trigger

A funnel result is surprising, an important event appears missing, or product and engineering are disputing whether an analytics metric can be trusted.

## Why run it repeatedly

Use after a disputed funnel result or during an instrumentation audit. Ask teams how often they distrust key metrics and how much they currently inspect manually; the public report describes weeks of dashboard investigation but does not establish a general cadence.

## What you receive

A read-only variance report: expected versus observed event names and properties, query windows, source-code references, known Linear work, and unverified findings.

## Pain evidence

A first-person PM report describes inconsistent event names, user IDs split across devices, missing properties, and a core onboarding event absent for roughly a third of users. It is one public account and does not establish prevalence or prove MCPs improve the work.

## Alternatives and remaining gap

Amplitude governance and data-quality features plus a deterministic contract test are better for continuous monitoring. A developer can script these exact comparisons. AI is useful for interpreting contract intent and assembling code/backlog context, not for counting, declaring correctness, or identifying root cause.

## Execution flow

1. Input the Amplitude project, metric/event window, and exact repository path to an approved tracking contract or instrumentation spec.
2. Read the contract file from GitHub and retrieve the Amplitude taxonomy, ingestion-source details, and event aggregates for the same UTC window.
3. Compare exact event names and explicitly required properties. Calculate observed counts and missing-field rates from returned data; disclose truncation, pagination, identity, or sampling limits.
4. Inspect supplied instrumentation file paths to locate candidate emitters. Code presence is not proof an event fires in production; do not claim a runtime fix or root cause.
5. Search Linear for existing work by exact event name and linked paths. Produce a source-linked variance report and optional issue draft; require approval before create_issue or code changes.

## Required tools

- Amplitude: get_amp_taxonomy, query_amplitude_data, get_data_ingestion_sources, get_data_source_details
- GitHub: get_file_contents
- Linear: list_issues, get_issue, create_issue (only after review)

## Prerequisites and costs

Amplitude organization/project access and MCP enabled; a written event contract and exact repository paths; GitHub read access; Linear read access and write scope only after approval. Amplitude tool exposure is client/role-dependent; verify the live tool list. No runtime or plan-cost claims.

## Run this prompt

```text
Audit [Amplitude project] against this tracking contract at [GitHub repository and exact path] for [UTC date window]. Read the contract file, Amplitude taxonomy/ingestion context, and event aggregates. Compare exact names and required properties only; calculate counts from returned rows and identify truncation or missing pages. Inspect the supplied implementation paths [paths] as candidate emitters, but do not treat code presence as proof an event fires. Search Linear for exact event names and existing tasks. Return observed facts, contract variances, source links, identity/data-quality caveats, and proposed tests. Do not edit code, change Amplitude taxonomy, create an issue, or claim cause until I approve.
```

## Review checkpoints

An analytics engineer confirms the intended event contract, identity rules, environments, data window, and whether a missing event is instrumentation failure or expected product behavior. Issue creation, schema/taxonomy edits, and code changes need separate approval and normal tests.

## Limitations

An aggregate query cannot establish what a particular user experienced. Identity stitching, delayed ingestion, sampling, and undocumented legitimate changes can mimic defects. The recipe depends on a maintained contract and exact file paths. A deterministic data-quality test is preferable for repeatable CI checks.

## Manual work and missing capabilities

A team must author and maintain the expected contract, validate identity resolution, and run behavior tests in staging/production. This MCP stack only reads the files explicitly supplied; it does not crawl a repository or test emitted events.

## Failure handling

Use bounded retries for read failures and mark partial results incomplete. Keep source record IDs and links. Do not guess across missing or conflicting identifiers. Search for an existing target record before any approved write, then retrieve it to verify.

## Pilot acceptance criteria

On a synthetic dataset with known missing events/properties: exact counts match a reference query; every finding cites the contract, query window, and source; truncation is marked incomplete; code is labeled candidate evidence only; no taxonomy, issue, or repository write occurs before approval.

## Product fit

MCPfolio recipe for a read-only investigation. Package only if teams validate repeated use; deterministic CI/data tests should own continuous quality gates.

## Demo storyboard

Use a synthetic contract requiring checkout_started and plan_id, Amplitude data with missing plan_id and an event-count gap, a repository file showing a candidate emitter, and one existing Linear task. Show missing identity/sample caveats and stop at a reviewed issue draft.

## Evidence

Pain reported by users; official tool docs/catalog checked; workflow not runtime tested

## Required MCPs

- [Amplitude MCP](https://www.mcpfolio.com/servers/amplitude): Reads the event taxonomy, data-source context, and actual event aggregates for the specified project.
- [GitHub MCP](https://www.mcpfolio.com/servers/github): Reads the supplied tracking-contract or instrumentation files from the repository.
- [Linear MCP](https://www.mcpfolio.com/servers/linear): Checks whether the instrumentation gap already has an issue and holds a draft follow-up after approval.

## Official sources

- [Product manager reports broken IDs, missing event properties, and funnels missing an event for a third of users](https://www.reddit.com/r/ProductManagement/comments/1m5cscy/i_think_our_amplitude_events_are_garbage_and_its/)
- [Amplitude MCP documentation](https://amplitude.com/docs/amplitude-ai/amplitude-mcp)
- [GitHub MCP server documentation](https://github.com/github/github-mcp-server)
- [Linear MCP documentation](https://linear.app/docs/mcp)


## Related

- [All workflows](https://www.mcpfolio.com/workflows)