---
name: analytics-tool-selector
description: Recommends which product and web analytics tools to run and which to skip, from who runs the reports, the decisions they make, the unit those decisions count, company stage and volume. Applies hard requirements, forecasts each billing meter, prices a switch and writes a one-page memo. Use when asked for the best product analytics tool for a startup, do we need product analytics yet, when to start tracking, which analytics tools to use, whether GA4 is enough or how to replace it, Mixpanel vs GA4, Mixpanel vs Amplitude, PostHog vs Mixpanel, Amplitude vs PostHog, Heap vs Mixpanel, Pendo vs Mixpanel, Statsig vs PostHog, Plausible or Matomo, warehouse-native analytics, whether to run two analytics tools, whether to switch from Mixpanel to PostHog, Mixpanel, Amplitude, PostHog or Heap pricing, MTU vs event pricing, or what happens when a free tier or startup programme ends.
license: CC-BY-4.0
metadata:
  tier: free
  category: product-analytics
  version: "0.3.0"
  last_reviewed: "2026-10-17"
  status: reviewed
---

# Analytics tool selector

Recommends which analytics tools to run and which not to buy, with the billing forecast behind it, in a short memo. It reads and proposes; it never signs up, changes a plan or installs an SDK.

## When to use

Use this skill when:

- A founder asks whether they need product analytics yet, which tools to start with, or whether GA4 is enough.
- A team is choosing between GA4, Mixpanel, Amplitude, PostHog, Heap, Pendo, Statsig, Plausible, Matomo or a warehouse-native option.
- A team pays for one tool and asks whether to switch, or whether two tools both earn their cost.
- A free tier, free year or startup programme is ending and the question is which plan or billing unit.

Use something else when:

- The tool is chosen and needs instrumenting: tracking-plan-builder, then the vendor's SDK docs.
- Numbers look wrong in an installed tool: the identity check in [references/pilot-and-signoff.md](references/pilot-and-signoff.md), or tracking-break-map.
- An existing bill jumped and the tool stays: [references/billing-meters.md](references/billing-meters.md) (martech-cost-forecaster, when installed).
- The decision is made and data must move: analytics-migration, when installed.
- Mobile install attribution: mobile-attribution-fundamentals.
- What a specific contract includes: the vendor's order form.

## Inputs

Read first, if they exist (marketing-context-kit creates the folder):

- `martech-context/stack.md`, `metrics.md`, `decisions.md` and `tracking-plan/`: tools, owners, SDK locations, Google Ads links, metric definitions, earlier decisions and what is instrumented.

Then gather:

- Three decisions from the last month the team could not make confidently, each with the person who acts on it. With no analytics tool installed, take the decisions planned for the next 90 days instead: launch baseline, activation, acquisition source.
- The operator for each (founder, marketer, PM, engineer, analyst, data team), and whether they will build reports themselves.
- The unit each decision counts: person, account or workspace, device, order.
- Volume from usage, not registrations: active people, anonymous sessions, events per session, autocapture, backend events, imports, replays, flags, experiments, AI spans. Worksheet: [assets/usage-forecast.yaml](assets/usage-forecast.yaml).
- Dependencies that must survive: Ads conversions or audiences on GA4 key events, BigQuery jobs, scheduled reports, warehouse models, live flags, a CDP in the path.
- An installed tool's plan, committed volume, renewal date, notice period, weekly reports (count them) and what depends on it.
- Hard constraints: data region, regulated data (PHI, BAA), platforms shipped, SSO and roles, history, raw export, budget ceiling, annual commitment, startup programme eligibility.
- Stage: whether repeat usage is defined, how many people use the data, whether a named data owner exists.

Evidence handling:

- Never ask for logins, API keys or customer records.
- Ask for usage screens cropped to volume by product and month, with billing details redacted.
- Through MCP, run only aggregate counts by event name, month and identified status. Never select person properties, distinct IDs or emails.

## Procedure

### Before step 1: no analytics tool installed yet

When no web or product analytics tool is installed, or only page views are collected:

- Missing events are expected, not a data gap; step 1's "no new tool" rule does not apply. Work from the planned decisions, each with an operator and a unit.
- Go straight to steps 2 and 3 to choose the first destination. A launch that needs a baseline is a step 2 trigger.
- In parallel, send event design to tracking-plan-builder, starting with backend outcomes whose history would otherwise be lost (signup, first value, payment).
- Start with one destination. A second tool must pass step 6.

### 1. Classify the gap behind each decision

Name the missing ingredient per decision:

- Data: the event does not exist, or fires on the click instead of the committed outcome.
- Identity: people or accounts are split or merged wrongly.
- Skill: nobody can build or read the report.
- Capability: the current tool cannot express the analysis, for example a funnel where different workspace members complete different steps.
- Workflow cost: it can, but someone rebuilds it by hand every week.

Rules:

- With a tool installed, if every gap is data or identity, recommend no new tool; a new tool inherits the broken definitions. Data gaps go to tracking-plan-builder; identity gaps get the identity check in [references/pilot-and-signoff.md](references/pilot-and-signoff.md).
- Skill gap: test whether the operator can learn the current tool before buying another.
- Only capability and recurring workflow cost justify a tool change, with the evidence in the memo.

### 2. Decide whether a dedicated product tool is due

Stay on existing sources (SQL on a read replica, GA4, customer calls) when a reproducible query answers the question, repeat value is undefined, or nobody will own the reports. Record a review date instead.

Add a dedicated product tool when at least one holds:

- The same product question reaches engineering every week.
- The decision counts accounts or workspaces and GA4 needs an unowned manual join to answer it.
- Several people need to change segments and windows without waiting for a query.
- A launch needs a baseline and the history would otherwise be lost.

Funding and headcount are not triggers: a five-person B2B company can need account analysis on day one.

### 3. Shortlist at most two candidates by operator and job

Overrides, applied first:

- Regulated data: when PHI or HIPAA applies, GA4 is never the default for authenticated journeys or care pages, because Google offers no BAA for Analytics. Shortlist only vendors whose BAA covers the plan to be bought; the legal or privacy owner decides which pages carry analytics (privacy-sensitive-analytics, when installed).
- Volume: apply "Volume bands" in [references/tool-fit.md](references/tool-fit.md). Above 20M events a month, get same-forecast quotes from every candidate; GA4 standard above about 1M events a day needs filtering, streaming export or 360; backend-heavy producers check ingestion limits; a licence above the warehouse-native cost lines, with models in place, adds a warehouse-native candidate.

Starting points to test, not rankings:

- Founder, marketing site or ecommerce acquisition: GA4 with verified outcomes; a product tool only when a recurring in-product question survives step 1.
- Web-only GA4 replacement: Plausible for aggregate goal reporting with no cross-day identity; Matomo when deployment control is required.
- PM or growth owner rebuilding funnels and retention weekly: Mixpanel first, Amplitude runner-up; Amplitude first when several teams need governed definitions and experiments.
- Engineers joining analytics with replay, flags and releases: PostHog first; Statsig when experiments are the central job.
- Retrospective interface questions with little engineering time: Heap, on its session meter.
- Adoption analysis plus in-app guidance owned by one team: Pendo.
- Data team with product, billing and CRM in maintained models: a warehouse-native candidate ([references/warehouse-native.md](references/warehouse-native.md)).
- Mobile app: GA4 through Firebase, plus a product tool only for an unresolved question.

Fit, skip conditions and GA4 report limits: [references/tool-fit.md](references/tool-fit.md). Each dropped candidate gets its operator reason in the memo.

### 4. Apply hard requirements as pass or fail

A missing mandatory capability removes the candidate; no weighted score repairs it. Test on the plan kept after any trial or programme. An unshipped capability fails until it ships on that plan; if the purchase depends on it, delay or get a contractual condition.

Test: account analysis; saved behavioural cohorts; experiment results; history and replay retention; raw export and the exit test; at-limit behaviour, including live flags; Google Ads dependency; data region; regulated data and BAA; access controls; an SDK per platform; API on free plans. Facts per vendor, checked on 2026-10-17, with URLs: [references/hard-requirements.md](references/hard-requirements.md); re-check the live plan page before a pass.

### 5. Map each candidate's billing meter and forecast it

Name the unit that grows the bill (events, identified events, MTUs, sessions, MAU, seats and compute, AI telemetry, a CDP's own meter) and forecast four cases: normal month, growth at 12 months, a fault (duplicate sender, re-initialising SDK, autocapture everywhere) and month 13 on the plan after any programme. Per-vendor meters and checked-on figures: [references/billing-meters.md](references/billing-meters.md).

Price rules:

- Every price carries "checked on YYYY-MM-DD" and the URL. Fetch the live page first and use its value, saying what changed. For a calculator, read the estimator values from the page data or ask the user; never interpolate.
- Price the cheaper of the smallest published tier at or above the forecast (read the whole ladder on the live page) and a lower plan plus that plan's overage, add-ons included on both sides. Route arithmetic per vendor is in the billing reference.
- Compare monthly with monthly, annual with annual.

Meter decision rules:

- Price the anonymous surface (marketing site, docs) separately on each meter. Keep it off MTU, session and identified-event meters unless a named decision needs pre-signup behaviour in the product tool; carry campaign context through first-touch properties at signup.
- MTU or event: when a candidate offers both, compute both bills for the normal, peak and import months with the break-even method in [references/billing-meters.md](references/billing-meters.md) and take the cheaper. Synthetic MTUs raise the MTU bill but do not by themselves make events cheaper; low events per identity favours events. Reject an MTU size billing over 200% of purchase in any month.
- If the growth case passes 80% of a free allowance within six months, price the paid plan now and set a usage alert at 80%.
- If the budget needs a hard cap, record what the cap does to data. Never cap PostHog's Feature flags & Experiments without a tested default for every live flag: over quota, `/flags` returns `quotaLimited` and production flags fall back to code defaults.

### 5b. If a tool is already in place, price the switch

- Payback months = (migration hours x rate + overlap cost + backfill charges) / (monthly licence saving - added upkeep hours x rate). Overlap is the new tool's bill during the parallel run plus incumbent months committed after cutover.
- Keep the current tool when the net saving is zero or less, or payback exceeds the remaining term plus 12 months, unless step 1 found a capability gap the incumbent cannot close on any plan.
- Time a justified switch to renewal. Cost lines and a worked example: [references/switching-cost.md](references/switching-cost.md).

### 6. Decide one tool or two

Two tools need a distinct recurring job, a named owner and a written mapping each. Pairs that usually pass: GA4 for acquisition and Google Ads plus one product tool; a product tool plus an experimentation platform whose assignment, exposure and outcome reconcile; a hosted tool plus the warehouse fed by its export. Never two product tools for the same questions, a second tool to check the first, or both SDKs on the marketing site.

Recommend one product tool without GA4 only when every condition in "One product tool without GA4" in [references/tool-fit.md](references/tool-fit.md) holds. Ads conversions and audiences on GA4 key events first need a replacement that passed its parallel test: the Ads tag with enhanced conversions or offline import, and Customer Match or Ads-tag audiences ("Google Ads dependency" in [references/hard-requirements.md](references/hard-requirements.md)).

Cost every second tool as dual tracking (both meters, two SDKs behind consent, double mapping, two identity configurations, reconciliation) in hours per month. If nobody can name a decision only the second tool supports, drop it. A tool kept for an external dependency such as Google Ads: price the replacement route against its monthly dual-tracking cost, and replace when payback is 12 months or less and no other job needs the tool. Cost model: [references/two-tools-and-dual-tracking.md](references/two-tools-and-dual-tracking.md).

### 7. Pilot two candidates when step 4 does not decide

Same journeys, fixtures, identities and window in both. The intended operator builds the report, explains the denominator and repeats it a week later unaided. Score correctness, usability and operability separately, run the exit test, and run until the slowest cohort matures. Pilot add-ons on a startup plan or a written, time-boxed trial, never an annual tier. Details: [references/pilot-and-signoff.md](references/pilot-and-signoff.md).

### 8. Write the memo and propose the record

Fill [assets/recommendation-memo.md](assets/recommendation-memo.md): a three-line Answer first, a body under 600 words, arithmetic and evidence in the appendix. Every "Not buying" line cites a step 3 reason, a step 4 fail with its URL, or a forecast, with that tool's growth-case cost; a rejected tool cheaper than every recommended or piloted tool needs a step 4 fail or pilot result. Propose the `martech-context/decisions.md` entry and the `stack.md` change, and wait for approval.

## Common failure modes

- Buying for features nobody will use. Detect: a quoted capability with no owner or decision.
- Mixpanel priced on the wrong route. Detect: entry overage multiplied above 1.5M events, or a tier skipped on the ladder.
- MTU or event chosen from events per identity alone. Detect: no side-by-side MTU and event bill.
- Anonymous pricing for a logged-in product. Detect: a PostHog estimate with no identified-event line.
- Account question answered with person counts. Detect: activation moves when one workspace adds members.
- A spending cap that silently deletes evidence. Detect: a flat chart that starts on a billing-limit date.
- A flags cap that changes the product. Detect: a PostHog flags limit with no tested default per live flag.
- Year-one budgeting. Detect: no month-13 line.
- Switching for a saving that never pays back. Detect: no payback line, or no upkeep hours in it.
- A cheaper candidate dropped on preference. Detect: a cheaper "Not buying" line with no step 4 fail or pilot result.
- Replacing GA4 without the Ads inventory. Detect: Ads conversions still import from GA4 in a plan that removes it.
- GA4 on a regulated journey. Detect: PHI in scope and a GA4 tag on an authenticated or care page.
- Buying on a roadmap promise. Detect: a step 4 pass for a capability not yet available on the plan.

## Worked example

Acme Reports (fictional 12-person B2B SaaS): 400,000 product events a month, 1.2 million in the growth case, 3.0 million with broad autocapture.

- GA4 keeps site landing pages and the Google Ads key event; one product tool on the app, piloting Mixpanel and Amplitude for the PM. The engineer's release question is a data gap, so PostHog drops at step 3.
- Growth case, checked on 2026-10-17: Amplitude Plus USD 0 (first 2M events free), Mixpanel USD 78.40, PostHog USD 63.80. If both pilots pass, Amplitude wins on month-13 cost.
- Replacing GA4's Ads role pays back in 8 months, but GA4 also owns site reporting, so it stays.

Full memo: [assets/example-acme-memo.md](assets/example-acme-memo.md).

## Acceptance checks

- Decisions: three decisions, past or planned, each with operator, unit and gap class. Pass: none lacks an operator or a unit.
- Gap routing: with a tool installed, data and identity gaps go to a fix. Pass: a tool change rests only on capability or workflow-cost evidence.
- Hard requirements: pass or fail per candidate and requirement, with URL and check date. Pass: no recommended tool fails one or passes on an unshipped capability.
- Not buying: each rejected candidate cites a step 3 reason, step 4 fail or forecast, with its growth-case cost. Pass: one cheaper than every recommended or piloted tool names a step 4 fail or pilot result.
- Meters: each recommended tool has normal, growth, fault and month-13 forecasts. Pass: every price has a checked-on date and URL from this session, the tier is the smallest on the live page at or above the forecast, and the cheaper of tier and overage is used.
- MTU or event: where both units are offered, both bills appear for the same month. Pass: the cheaper is chosen and billed MTUs stay under 200% of purchase.
- Switching: payback months and threshold stated when a tool is in place. Pass: the outcome follows step 5b or names the overriding capability gap.
- Two tools: one job and owner each, dual-tracking hours stated, and a tool kept for Google Ads shows its replacement priced. Pass: no two tools share a job.
- Limits and dependencies: at-limit behaviour, alert and owner per meter; a named path for Google Ads, exports, scheduled reports and flags. Pass: an alert below 100%, no flags capped without tested defaults, nothing orphaned.
- Memo: from the template, Answer block first. Pass: the body from "Answer" to "Revisit when" is under 600 words.
- Approval: nothing written to `martech-context/` without the user's approval.

## Boundaries

- Read-only. Creating accounts, starting trials, changing plans or billing limits, installing SDKs, changing Ads conversion actions and accepting terms are human actions.
- Prices are planning estimates; contract terms come from the order form, in writing. No legal, procurement or HIPAA advice.
- Reading volumes, aggregate counts only: Google's GA4 MCP server (`analytics.readonly`); the PostHog MCP server with `readonly=true`; Amplitude only after an admin assigns a role with Use MCP (read) and without Use MCP (write); Mixpanel's MCP server has write tools and no read-only mode, so call only read and query tools. Any write-capable connection: agent-write-safety. Billed usage comes from the vendor's billing page, via the user.
- Hand-offs: tracking-plan-builder; the vendor's SDK docs and MCP server in `sources.yaml`; marketing-context-kit. When installed: product-analytics-setup, the mixpanel, amplitude and posthog implementation skills, identity-merge-qa, analytics-migration, martech-cost-forecaster, privacy-sensitive-analytics, conversion-goals-and-key-events, enhanced-conversions, offline-conversion-import.

## Live docs

Platform settings, limits and menu paths change. Before stating any parameter name, limit, quota or UI path:

- Fetch the current page from the vendor docs MCP server or llms.txt listed in `sources.yaml`, or open the canonical URL.
- If the live page disagrees with this skill, follow the live page and tell the user what changed.
- Cite the URL you used.

Most important here: each vendor's pricing and billing pages, the Amplitude Plus terms, PostHog's flags API page, and Google's export, retention, HIPAA and Ads conversion pages. Every price was checked on 2026-10-17; re-fetch before quoting.