Who PostHog is
PostHog was founded in January 2020 and began as open-source product analytics. Its team is fully remote, spread across more than 20 countries, and PostHog Inc. lists its address in San Francisco. Today it calls itself a platform for self-driving products: analytics, session replay, feature flags, experiments, surveys, error tracking, logs and a data warehouse, with AI agents that find problems in that data and propose fixes.
Its product analytics turns events into funnels, retention, paths and lifecycle reports, each a click away from the session replays behind it. PostHog is audited for SOC 2 Type II by an independent firm and keeps its code public on GitHub, mostly under the MIT licence. It publishes and maintains its own Flutter SDK, for the toolkit our mobile apps are built with, and runs an EU cloud in Frankfurt, which is why our analytics and monitoring module counts it among its product analytics connectors.
What it does in your platform
Analytics & monitoring
Puts your apps' numbers and the sessions behind them in one place: funnels, retention and paths for your product team, and replays for what a chart cannot explain. The apps report screens and taps through PostHog's SDKs, the platform's server reports the money, and every event carries one random platform ID, sent only for customers who agreed to analytics.
How the connection works
Our Flutter apps use posthog_flutter, which PostHog publishes on pub.dev under its verified publisher, posthog.com, and the web apps use posthog-js, its JavaScript SDK. Money events come from the platform's server through one of PostHog's server libraries, and all of them go to PostHog Cloud EU.
The customer agrees
Nothing reaches PostHog until the customer agrees to analytics: only then does the app set up PostHog's SDK. The choice is kept in the platform, and if they turn analytics off later, the SDK's optOut() stops every capture, replays included.
They sign in
The app calls identify() with the customer's random platform ID, with no name, email or phone number attached. The web apps and the server use the same ID, so PostHog counts one person across phone, browser and platform.
They order a card
PostHog's navigator observer records each screen of the card order, and taps on the tracking plan go out as events. The SDK queues them on the phone, offline too, and sends them to the EU cloud in batches, by default once 20 are queued or every 30 seconds.
The card is issued
The card issued event comes from the platform's server, so PostHog counts what the platform actually did. Each server event carries its own ID and original time, so PostHog recognises a retried copy as a duplicate and merges it away in the background.
The team sees where customers stop
Your product team builds a funnel from the first card screen to the card issued, opens the customers who dropped at the weakest step and replays their sessions. The Flutter SDK masks all text and images on the phone by default, and the app pauses recording on card and identity screens.
They ask to be forgotten
The app opts them out and the platform stops sending, since a deletion covers only events already received. It then asks PostHog's persons API to delete them by platform ID, with their events and recordings: PostHog destroys the recordings' encryption keys and clears the events at quiet times, while the platform checks the deletion status until it reads completed.
Next to other providers
PostHog is one of the module's product analytics connectors, with Mixpanel, Amplitude and Google Analytics for Firebase, next to the connectors for customer data, engagement, attribution and monitoring. Each knows a customer by the same random platform ID and gets only what the tracking plan lists, so a journey can be followed across tools without a name or an email address passing between them.
The tracking plan, the consent choices and the platform IDs belong to your platform rather than to PostHog, so replacing it later, or adding a second analytics tool, does not change your apps. Events already in PostHog can be copied out with its batch exports, to S3, BigQuery, Snowflake and other destinations.
When PostHog fits best
A strong fit when
- Your product and engineering teams want analytics and session replay in one tool, each chart a click away from the recordings behind it.
- You want Flutter replays masked on the phone by default: text, images and embedded views such as web views.
- You want a tool whose code your engineers can read on GitHub, run for you in PostHog's EU cloud.
Also worth a look
- Mixpanel, Amplitude or Google Analytics for Firebase, the module's other product analytics connectors.
- An analytics tool your team already works with, connected the same way.
How we get you live
The contract
We help you get your PostHog account and contract in place, including the data processing agreement PostHog offers every cloud customer, and set up your team's access with you.
The data
We create your organisation in PostHog Cloud EU. IP capture stays off, as PostHog sets it for new EU projects, and we switch off its GeoIP enrichment, so no IP address or location derived from one is stored. The tracking plan lists every event and property your team agrees, including which of the SDK's automatic events, such as app installed, stay on.
The keys
Your apps, and the server when it sends events, use only the project token, which PostHog says can safely be public because it gives no access to your private data. The personal API key that deletions need, scoped to persons alone, stays in your platform's secrets and never goes into an app.
A full test run
Test builds and your staging environment send to PostHog projects of their own, as PostHog recommends, and we check every event, the masking on every recorded screen and a complete deletion there before your first real customer.
