A focused PostHog alternative for teams that need decisions, not a suite

PostHog is an unusually broad product platform. It combines product and web analytics with replay, feature flags, experiments, surveys, data pipelines, warehouse capabilities, error tracking and AI features. Its usage-based model also provides generous free allowances. If you want one developer-oriented suite and will actively operate those products, PostHog is a strong choice.

Breadth creates a different problem for a small product team. Capturing data is easy; establishing a clean event model, agreeing which report is authoritative and turning dozens of surfaces into a weekly decision can be hard. MetricFold is for teams that want the behavioral depth of product analytics and the clarity of a concise web dashboard without adopting a wider product-delivery platform.

The MetricFold boundary

MetricFold connects six kinds of evidence:

1. acquisition: visits, sources, channels, campaigns and landing pages;
2. behavior: semantic product actions, paths, engagement and feature adoption;
3. conversion: goals, funnels, activation and retention;
4. commercial truth: verified payments, renewals, refunds and disputes;
5. experience quality: errors, Web Vitals, dead clicks, rage clicks and form abandonment;
6. recommendations: bounded hypotheses that cite the affected pages, controls, segments and sample limits.

This is deliberately not a feature-flag service, experimentation engine, survey product or data warehouse. Use PostHog when those are the primary jobs. Use MetricFold when a smaller decision surface and privacy-minimized collection are the priority.

Product actions without event-call sprawl

Traditional product analytics often begins with explicit calls throughout the application. Explicit server events are still correct for durable business state: account created, first project completed, subscription paid, export delivered or booking confirmed.

Browser interaction needs a lighter mechanism. MetricFold automatically captures bounded page navigation, outbound links, downloads, form lifecycle, scroll depth, client errors and performance. Important controls receive stable semantic attributes such as data-analytics-action="checkout_opened". One delegated listener handles those elements across SSR and SPA navigation.

The collector never uses the visible button text as an event name and never copies input values. A tracking-plan scanner can show meaningful controls that lack an action, action names that are never observed and duplicate names used for different jobs. This makes instrumentation a reviewable contract rather than a trail of calls scattered across components.

Friction evidence without default replay

Replay is useful when a team needs to reproduce a visual sequence and has the consent, masking and operating process to use recordings responsibly. It also creates a large privacy, bandwidth and review surface. A library of recordings is not automatically a diagnosis.

MetricFold's core does not record the screen. It records stable, bounded signals: repeated clicks, controls that appear inert, abandoned forms, failed requests, client exceptions, slow interactions, layout shifts and the path leading to a conversion or exit. Reports group those signals by page, semantic target, device, browser and release annotation.

That structure is easier to query. An LLM can rank a checkout dead-click spike, identify that it is concentrated on mobile Safari after a release, state the sample limitation and propose a reproduction step. It does not need raw DOM, typed values or a video archive.

Replay may later exist as a separate, explicitly enabled and consent-aware module. It should never silently widen the privacy contract of the core collector.

Pricing and predictability

PostHog meters separate products and event classes. That is flexible for teams that want to compose a stack and optimize each allowance. MetricFold uses one accepted-signal meter for the complete analytics decision surface. Dashboard reads, rejected bots, duplicate retries, rollups and payment-webhook attempts do not consume quota.

The distinction is philosophical as well as commercial. Funnels, revenue and friction are not premium decorations; they are required to understand whether traffic creates value. MetricFold does not hide them behind an upgrade.

Privacy and identity trade-offs

PostHog can analyze anonymous events and create identified person profiles. That supports cross-session and user-specific analysis. MetricFold's default web collector avoids persistent browser identity and rotates its pseudonymous visitor key daily. Logged-in products may send a host-owned, non-reversible subject reference for explicitly configured product analysis, but no email or profile is accepted by the public collector.

The default therefore sacrifices long-lived anonymous person history. Trusted server-side lifecycle events and payment metadata supply durable commercial evidence without asking the browser to become an identity store.

A safe PostHog migration

Export the current event catalogue before changing code. Label each event as a business transition, meaningful product action, automatic browser signal or unused noise. Preserve business transitions on the server. Convert meaningful controls to semantic actions. Let the collector own standard browser signals. Retire unused properties and anything containing personal or free-form data.

Rebuild only the funnels, retention cohorts and paths used in a real review. Run both collectors in parallel, align time windows and bot rules, and annotate the migration. MetricFold measures product-owned experiment exposure, conversion and lift, but experiment assignment and feature rollout must remain in the product's tested flag system. Keep PostHog only when invasive replay or PostHog-owned assignment is a deliberate requirement.

MetricFold is a good replacement when the goal is not “everything PostHog can do.” It is a good replacement when the goal is to understand what brought people in, what value they reached, what blocked them, what they paid and what the team should improve next.

Compare jobs before replacing a product suite

Review PostHog's current product analytics documentation and pricing before migration because its suite evolves. MetricFold's public capability matrix intentionally preserves missing or excluded cells rather than using “alternative” to imply identical scope.

Run a tracking-plan reduction workshop

Classify every event

Mark each current event as server-owned business truth, semantic product action, automatic browser signal, experiment evidence or unused noise. Identify its owner, consumers, required properties and retention. Delete or quarantine events with no decision, personal/free-form properties or implementation-only names.

Rebuild authority

Move completed workflows, entitlements, payments, refunds and subscription states to trusted server adapters. Leave attempts, CTA interactions and performance observations in the browser. The revenue attribution guide describes how a short-lived visit token joins to a verified webhook without letting client code invent money.

Rebuild only used analyses

List the funnels, paths, cohorts, experiments and dashboards reviewed in the last quarter. Recreate those first and require an owner for each definition. Preserve the historical PostHog export rather than forcing incompatible person identity into a new anonymous model.

Validate the privacy and diagnostic trade

MetricFold's rotating anonymous boundary makes long-lived anonymous person history weaker. This is a real loss for teams that depend on person-level exploration. After authentication, an approved product account reference can support activation, adoption and retention without putting a raw user id or email in the public collector.

Structured friction can rank affected controls, pages, devices, failures and performance regressions. It cannot show the visual screen state that replay can. Use the friction analytics guide to test whether the smaller evidence surface resolves the team's actual cases before removing a governed replay system.

When PostHog is the better choice

Keep PostHog when the team actively uses its replay, feature-flag delivery, experimentation assignment, surveys, data tooling or other suite capabilities and accepts the corresponding implementation and governance surface. A focused analytics product should not pretend those jobs disappeared.

Choose MetricFold when breadth has become operational noise and the desired weekly loop is acquisition → action → friction → activation → verified revenue → retention, with a small cookie-free collector and explicit server authority.

Frequently asked questions

Does MetricFold replace PostHog session replay?

No. It provides aggregate friction, errors, performance, paths and bounded event journeys. Keep a specialist replay system when the visual sequence is necessary and its consent, masking, access and retention are governed.

Can MetricFold run A/B tests?

It records observed experiment exposure and conversion, detects assignment conflicts and reports outcomes. Runtime assignment and release safety remain in the product's feature-flag and experiment systems.

Can identified PostHog users be imported directly?

Do not expose emails or raw person ids to the public collector. Map only the approved product-owned pseudonymous subject needed for account analysis and retain incompatible historical identity in an archive.

What is the safest cutover?

Parallel-run one site, one activation funnel, one friction case and one trusted payment lifecycle. Reconcile definitions, bot exclusions and quota before removing the old collector.

Where should tracking-plan design begin?

Use the user behavior analytics guide to separate automatic safety signals from semantic outcomes. PostHog documents funnels and paths as distinct analyses; preserve the reports the team uses rather than mapping every event.

What migration evidence should be archived?

Keep the prior event catalogue, property classifications, person-identity boundary, retained analyses, export location, parallel-run definitions, deterministic event fixture and cutover date. Preserve replay only according to its existing consent, retention and access policy; do not copy it into MetricFold. Confirm the old client is removed from every SSR/SPA entry after the final reconciliation.

How do API and AI workflows differ?

Rebuild them against scoped report contracts, not a raw-event compatibility layer. MetricFold REST and MCP return bounded evidence with definitions and truncation. Existing jobs that require person lookup, feature-flag mutation or unrestricted queries remain outside the replacement boundary and should keep their appropriate system.

How should the team review the result after cutover?

Run a weekly acquisition-to-retention review with the same mature window and event versions used during parallel collection. Inspect unknown events, exclusions, unattributed outcomes and provider reconciliation before product hypotheses. Select one adequately sampled leak, reproduce adjacent friction, record the release and compare an equal period.

If an old PostHog workflow remains essential, keep it deliberately instead of building a weak duplicate. A smaller stack is valuable only when it preserves the decisions, authority and evidence the team actually needs.

Keep the retained boundary explicit in the architecture and operating runbook.