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 handles pageviews on every Drafted By site. PostHog Cloud EU (project name 'drafted-suite' for the monorepo apps; separate 'Carriva.fr' project for Carriva) handles product analytics: funnels, session replays, feature flags. This setup costs me almost nothing combined, and each dashboard answers exactly one question without overlap.

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.

After the cutover, I realized PostHog Cloud's pageview data was fine but not great for the simple question "how many people visited this page yesterday." I wanted something lighter. So I added Umami.

Umami for pageviews: cookieless and cheap

Umami is excellent for the simple question 'how many people visited this page yesterday'. It is cookieless, GDPR-safe by default, and free at any volume because it is self-hosted. I run it on a small VPS with Postgres. The compute cost is marginal.

Every page in every Drafted By site loads the Umami script at build time via NEXT_PUBLIC_UMAMI_WEBSITE_ID and NEXT_PUBLIC_UMAMI_HOST env vars. Umami fires automatically on pageview. I do not call umami.track for custom events. If I want a funnel, I am asking PostHog the question, not Umami.

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

PostHog Cloud for funnels, replays, and flags

PostHog Cloud handles the product-side questions: 'where did users drop in the signup funnel', 'what does this specific user's session look like', 'is this experiment converting better'. I use the free tier, which covers 1 million events per month plus session recordings. My actual volume is well under that.

The PostHog snippet loads on every page too, via NEXT_PUBLIC_POSTHOG_KEY and NEXT_PUBLIC_POSTHOG_HOST. I call posthog.capture('event_name', { properties }) for the actual product events: 'lesson_generated', 'export_clicked', 'signup_completed'. These feed the funnel and session replay.

Cookieless mode is enabled in PostHog config so it stays GDPR-compliant for anonymous traffic. Cookies kick in only after explicit consent for logged-in users. This matters because French law is strict on tracking.

The hybrid integration shape

The integration is simple. Every page in every Drafted By site loads both the Umami script and the PostHog Cloud snippet at build time via NEXT_PUBLIC_* env vars. Both fire on pageview.

Umami events are auto: just pageviews. I do not call umami.track for custom events because if I want a funnel I am asking PostHog the question, not Umami.

PostHog events: I call posthog.capture('event_name', { properties }) for the actual product events. These feed the funnel and session replay.

Cookieless mode is enabled in PostHog config so it stays GDPR-compliant for anonymous traffic. Cookies kick in only after explicit consent for logged-in users.

The decision flow I gave myself in March: Umami for everything pageview-shaped, PostHog Cloud for everything event/funnel/replay-shaped. No overlap, no confusion about which dashboard answers which question. If I find myself asking Umami for funnels, that is a signal to capture the event in PostHog instead.

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. PostHog Cloud free tier plus self-hosted Umami equals real zero-cost analytics at small volume. Umami's self-hosting cost is a few dollars per month for the VPS. PostHog Cloud's free tier covers 1 million events per month. My volume across all sites is 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 ever need to reconcile the two, you cannot. 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

Two tools, one question each. Umami for pageviews. PostHog for funnels. No overlap, no confusion. The cost is near zero. The maintenance is near zero. The data is good enough for the decisions I need to make.

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 scales down to zero effort and zero cost, and that is exactly what you need when you are one person.