Why I run two analytics tools: Umami for pageviews, PostHog for funnels

I run two analytics tools side by side. Umami self-hosted on insights.draftedby.com provides traffic reporting for the Drafted By portfolio. PostHog Cloud EU supports product-event analysis. Collection is configured per application; a feature being available in PostHog does not mean it is enabled on every site.

Updated 15 September 2026: this article retains its original March publication date and now includes the April cloud migration and the current portfolio-site configuration.

The problem with one analytics tool

Most analytics tools try to do everything. Google Analytics tracks pageviews, events, and conversions, but it is heavy, slow, and legally risky without careful cookie consent setup. Plausible and Fathom are great for pageviews but do not do funnels or session replays. PostHog does funnels and replays well but its pageview dashboard is not as clean as Umami's.

When I started Drafted By, I used PostHog for everything. I self-hosted it on CT 108 in my homelab. That decision cost me four months of maintenance until I cut over to PostHog Cloud on 2026-04-28. The operational overhead of ClickHouse, Kafka, and recordings storage was not worth it for a solo operation.

Umami already served the simpler traffic-reporting need. Moving PostHog to Cloud let me keep that reporting alongside product analytics without operating the PostHog backend myself.

Umami for pageviews: cookieless and cheap

Umami is excellent for the simple question 'how many people visited this page yesterday'. My configuration uses cookieless collection. Self-hosting avoids a per-pageview software bill, but still requires hosting and maintenance. I run it on a small VPS with Postgres. The compute cost is marginal.

On this portfolio, NEXT_PUBLIC_UMAMI_WEBSITE_ID configures the website identity. The browser loads the script through /u/script.js; the server forwards requests to the configured Umami upstream. The integration records pageviews and selected custom events, including navigation and contact interactions.

I wrote a longer post about self-hosting Umami if you want the gory details on deployment and migration.

PostHog Cloud, configured for each application

PostHog can support funnels, recordings and experiments, but I choose the collection settings for each application. On this portfolio, the current configuration uses cookieless collection and disables person profiles, automatic event capture, session recording, surveys and feature flags. It sanitizes pageviews and sends a selected set of named business events.

That is a description of this repository, not a claim that every product has identical settings. An authenticated SaaS application can have different requirements from a public portfolio. Collection choices are documented in the site's privacy notice.

The hybrid integration shape

The shared track helper in this portfolio sends selected events to both integrations:

export function track(event: string, data?: Record<string, unknown>) {
  if (typeof window === "undefined") return;
  trackPostHog(event);
  window.umami?.track(event, data);
}

The PostHog wrapper filters the event names it accepts. The Umami call can receive the extra properties supplied by the caller. This is why the old description of Umami as strictly pageview-only no longer matches the code.

For a traffic overview, I start with Umami. For a sequence of product actions, I use the relevant PostHog events. There is deliberate overlap in collection; the useful distinction is the question each report answers.

When this hybrid earns its place

You have content sites and a SaaS product. Content needs simple pageview metrics. SaaS needs funnels. The two questions are different enough that one tool optimized for both will compromise on one side.

You care about cost. At the time of the original setup, PostHog Cloud’s free tier kept the software bill low. Umami's self-hosting cost is a few dollars per month for the VPS. The allowance used for that comparison was 1 million events per month; plan terms and actual usage need checking when budgeting today. At that point, my volume across all sites was under 200,000 events per month.

You do not have time to operate ClickHouse for self-hosted PostHog. That decision cost me four months of maintenance until I cut over to Cloud. PostHog self-host is not the right answer for a solo operation. Cloud is fine until you have a reason to leave Cloud, which is rare at small to medium scale.

When it does not earn its place

Single-page personal site: Umami alone is enough. You do not need funnels or session replays for a blog.

SaaS without content: PostHog Cloud alone is enough. You do not need a separate pageview tool if your entire product is a single-page app with no blog or content pages.

Massive event volume (10 million plus events per month): PostHog Cloud bills per event past the free tier. At that scale, evaluate whether self-hosted PostHog is back on the table. But you would also need the operational capacity to run it.

The cutover from self-hosted PostHog

I spent four months self-hosting PostHog on CT 108 in the homelab. Backup-restore drama. ClickHouse memory limits. Version upgrade pain. Decommissioned on 2026-04-28, migrated to PostHog Cloud.

The lessons: PostHog self-host is a serious infrastructure project. It requires a ClickHouse cluster, Kafka, and recordings storage. The homelab context matters here. I wrote about the Vercel-to-Coolify migration which covers the infrastructure decisions that led to this setup.

PostHog Cloud is fine for my volume. If I ever hit the free tier limit, I will pay the per-event fee. That is cheaper than my time maintaining the self-hosted stack.

Tradeoffs and a note on data duplication

The obvious objection: you are sending two pageview events for every visitor. One to Umami, one to PostHog. That is true. But both are lightweight scripts. Umami is under 10KB. PostHog is around 30KB. The overhead is negligible for the user.

The less obvious tradeoff: you are duplicating the pageview data. Umami stores it in its own Postgres. PostHog stores it in ClickHouse. If you reconcile the two, first align the event definitions, time windows and collection settings. The numbers will differ slightly because of script load timing, ad blockers, and cookie consent states.

I have accepted this. I do not need precise reconciliation. I need Umami for the trend line and PostHog for the funnel. If the pageview numbers are off by 5 percent, that does not affect my product decisions.

Final takeaway

Umami gives me a traffic overview; PostHog helps me inspect selected user journeys. Some events overlap. The important part is knowing what each application collects and which report supports the decision in front of me.

If you are a solo founder running content sites and a SaaS product, consider this hybrid. It is not the most elegant architecture. But it is the one that keeps the operating effort manageable, and that is exactly what you need when you are one person.