Forem: red bean

You Don't Have 50,000 Users — How Ghost Profiles Pollute Your PostHog Data

red bean — Mon, 20 Apr 2026 12:27:47 +0000

You open PostHog. Persons tab says 50,000. You tell your team, your investors, your board: "We have 50,000 users."

You don't. You probably have 35,000. Maybe fewer.

The rest are ghosts — duplicate person records that PostHog created because its identity resolution isn't perfect. The same human, counted twice, three times, sometimes more. Different devices. Different browsers. An app session here, a web session there. PostHog sees each one as a new person.

Why this happens

PostHog links anonymous sessions to known users when you call posthog.identify(). In theory, this merges the anonymous profile with the identified one. In practice, it fails more often than you'd think:

Same person, two devices. They use your app on their phone and your website on their laptop. Two separate distinct_id values. If they don't log in on both, PostHog has no way to connect them. Two person records.
Same person, same device, cleared cookies. They visited your site in January. Cookies expired or got cleared. They came back in March. New distinct_id. PostHog creates a second person.
Race conditions in identify calls. PostHog's merge logic is eventual, not transactional. When identify events come in close together from different clients, the merge can silently fail. The result: two person records with the same email.
In-app browsers. Your app opens a link in a WebView. PostHog's web SDK sees a completely new session with no connection to the native app. One user, two people in PostHog.

This isn't theoretical. PostHog has had open GitHub issues about identity merging since 2020. They built $merge_dangerously specifically because the standard merge doesn't always work.

Why it matters more than you think

Ghost profiles don't just inflate a vanity metric. They break everything downstream.

Your funnels are wrong. A user who signed up on their phone and converted on their laptop shows as two separate journeys. One person who completed the funnel, but PostHog sees it as one dropout and one direct conversion. Your conversion rate is wrong in both directions.

Your retention is wrong. Same user counted twice means they can "retain" by switching devices. Or they look churned on one device while still active on another. Your retention curves are lying to you.

Your cohorts are wrong. Behavioral cohorts include ghost profiles. You're targeting "users who did X but not Y" — except some of them did Y, just on a different device under a different person record.

Your A/B tests are wrong. If the same person is in your experiment as two different participants, potentially in different variants, your results have noise you can't account for.

You're making product decisions based on data that's 15-30% wrong. That's the real cost.

How bad is it in your project?

We built a free tool that connects to your PostHog instance and tells you exactly how many ghost profiles you have. It checks three signals:

Email duplicates — multiple person records with the same email address. PostHog should have merged these but didn't.
Phone duplicates — same thing with phone numbers.
Device ID duplicates — PostHog's own SDKs set a $device_id on every event. If two different person records have events from the same device ID, that's the same browser or phone creating two people. This catches anonymous duplicates that email matching can't.

It takes about 60 seconds. No code changes, nothing gets modified in your PostHog instance. You paste a read-only API key and get a report.

Run a free audit on your PostHog data

What you can do about it

Once you know the scope of the problem, you have a few options:

Manual merges. PostHog lets you merge person records manually in the UI. Fine if you have 20 duplicates. Not practical if you have 2,000.

Better identify() hygiene. Make sure every client calls posthog.identify() with a consistent user ID as early as possible. This prevents some duplicates going forward but doesn't fix the ones already in your data.

CrossTrack. We're building an identity resolution layer that sits alongside PostHog. It detects duplicates in real-time using email, phone, device fingerprinting, and a WebView bridge that links app sessions to in-app browser sessions. The SDK is open source, 3.2 KB, zero dependencies.

The number you should actually be tracking

Instead of "persons" in PostHog, look at your ratio of distinct IDs to persons. If you have 50,000 persons and 80,000 distinct IDs, that's 1.6 distinct IDs per person on average. Some of that is normal (one anonymous ID + one identified ID = 2). But if your average is above 2.0, or if you find persons with 5, 10, 20 distinct IDs — your identity resolution has gaps.

The audit report shows you this ratio along with the specific duplicate clusters. At minimum, it tells you whether your user count is a number you can trust.

Check your PostHog data for free

How to Track Users Across Your App and Website

red bean — Sun, 19 Apr 2026 09:36:06 +0000

If your company has both a mobile app and a website, you've probably noticed a problem: the same person using both platforms shows up as two completely different users in your analytics.

Your website assigns them a visitor ID. Your app assigns them a device ID. These two systems have no way to know they're looking at the same person.

Why this happens

Every platform generates its own anonymous identifier:

Website: A visitor ID stored in localStorage or a cookie (e.g., visitor_8f2k)
Android app: A device-scoped ID (e.g., device_x9m2)
iOS app: Same concept, different ID (e.g., device_p4wn)
In-app WebView: Yet another visitor ID (e.g., visitor_q7wv)

None of these systems talk to each other. So one real person browsing your site and using your app looks like 2, 3, or even 4 separate "unique users" in your data.

The impact

This isn't just a data quality issue. It causes real business problems:

Inflated user counts — your "monthly active users" number is higher than reality
Broken funnels — a user starting on web and converting in the app looks like a web drop-off
Wasted ad spend — you're retargeting users who already converted, because your ad platform doesn't know they're the same person
Blind support teams — when a user calls, your support team can't see what they just did in the app

Common approaches (and their limitations)

1. Wait for login

The simplest approach: once a user logs in on both platforms with the same account, you link them.

Problem: Many users never log in, or only log in on one platform. You're blind to anonymous cross-platform behavior, which is often the majority of your traffic.

2. Build it yourself in dbt

Some teams write SQL models that try to stitch identities together in the warehouse after the fact.

Problem: This gets complex fast. You need to handle edge cases like cascade merges (two already-merged profiles need to merge again), shared email addresses, and retroactive event re-tagging. Most DIY solutions break on these edge cases.

3. Use Segment's identity resolution

Segment has a basic identity graph that merges anonymous and known users.

Problem: It's limited — last-seen-wins merge logic, no WebView bridge, no real cross-platform stitching. If your user opens a WebView inside your app, Segment creates a brand new identity.

4. Enterprise tools (Celebrus, mParticle)

These handle identity resolution well but cost $50k-$500k/year and take months to integrate.

The WebView bridge problem

The hardest part of cross-platform identity is the WebView. When a user taps a link inside your app that opens a web page in an embedded browser (WKWebView on iOS, WebView on Android), a completely new web session starts. The web page has no idea it's running inside your app.

This is where most solutions fall short. The WebView session becomes an orphaned identity that never gets connected to the app user.

The solution is a bridge: the app SDK injects the device's visitor ID into the WebView's localStorage before the web page loads. The web SDK reads it and includes it with every event. The server sees both IDs and merges them — no login required.

How we solved this

We built CrossTrack specifically for this problem. It's a set of lightweight SDKs (Web, Android, iOS) that handle visitor ID generation, cross-platform session stitching, and WebView bridging automatically.

The SDKs send events to an identity resolution service that merges anonymous sessions into unified profiles. When identifiers overlap (same user logs in on both platforms, or a WebView bridge fires), profiles merge and all historical events get re-tagged to the surviving profile.

You can see this working in an interactive demo: https://crosstrack-demo.onrender.com

It walks through the full scenario — anonymous web visit, app open, WebView bridge, login on both platforms — and shows profiles merging in real-time.

If cross-platform identity is a problem your team deals with, take a look: https://crosstrackdata.com