Choose TelemetryDeck when your indie app primarily needs usage and retention insights with a privacy-focused identity design. Choose PostHog when you need ordered funnels and linked customer journeys for deeper investigation. Both support RevenueCat; the decisive work is defining your events, identifiers, and report semantics.
The short version
- TelemetryDeck supports funnels, retention, and RevenueCat integration; it is not limited to active-user counts.
- A funnel based on event membership and a sequential funnel can produce different correct answers.
- Decide the identity handoff before joining app behavior to subscription events.
Choose by the question you need to answer
Official documentation and public pricing checked September 20, 2026. This is a documentation-based comparison and an original planning worksheet. We did not run a cross-platform SDK benchmark, submit customer events, or measure ingestion speed, battery use, or dashboard accuracy.
TelemetryDeck is a strong candidate when you want to improve an indie app using feature adoption, return behavior, and subscription patterns while keeping direct customer identification out of the analytics workflow. PostHog is a stronger candidate when your regular work requires ordered journey analysis, person-level investigation, or analytics alongside feature flags and experiments. These are recommendations based on the documented workflows, not a measured winner.
Both have more capability than a simple “privacy versus power” label suggests. TelemetryDeck documents funnels, retention, and RevenueCat integration. PostHog lets you configure collection and identity rather than requiring you to send a customer's email. The useful distinction is the question, the identifier, and the data you are prepared to maintain.
We make Hogly, an independent PostHog client. That creates a commercial interest in the PostHog ecosystem; Hogly is optional and is not an analytics backend for TelemetryDeck. Platform logos identify the products and do not imply endorsement.
Three indie-app questions that lead to different choices
| Your question | Minimum evidence | How to compare |
|---|---|---|
| Do people use the feature I spent a week building? | A meaningful completion event, app version, and eligible-user denominator. | Start with aggregate events in either tool. You do not need a name or email to answer this. |
| Do people who see this paywall start a trial and return? | Stable analytical identity, subscription events, and explicit funnel and return definitions. | Both merit evaluation. Check event order and cohort semantics before comparing percentages. |
| A customer says they paid but stayed locked. What happened to this account? | A permitted link between the support account, app events, and subscription history. | PostHog's identified-person workflow is a direct fit; keep RevenueCat's entitlement state as the purchase-side reference. |
PostHog's funnel documentation describes inspecting people who complete or drop out of a step. TelemetryDeck's product description emphasizes usage analysis without identifying individual people. Do not assume an aggregate dashboard can answer an account-specific support question just because it contains the same purchase total.
A reusable event worksheet for an iOS subscription app
The following is a proposed event contract for a fictional reading app. These names are ours, not promises about either SDK's automatic events. Map them to your provider's event names once, and assign one source to each fact.
| Concept | When it is true | Owner and useful fields |
|---|---|---|
reading_completed | The reader finishes the app's core reading action. | App; feature version, entry surface. Exclude document names and contents. |
paywall_viewed | A specific paywall becomes visible. | App, or a chosen paywall integration; placement and offering. Choose one source to avoid duplicates. |
trial_started | The subscription service confirms a trial began. | RevenueCat integration; product and environment. A purchase-button tap is insufficient. |
trial_converted | The service reports the trial's paid conversion. | RevenueCat integration; product and defined revenue basis. Keep direct paid purchases separate. |
subscription_renewed | A subsequent subscription period renews. | RevenueCat integration; product, event time, and deduplication key where provided. |
For each row, record its actual SDK or integration name, allowable properties, test/production filter, deduplication rule, and identity source. Keep subscription lifecycle facts server-owned: an app can be closed when a renewal happens. Neither a button tap nor a locally cached success screen is a substitute for the subscription service's event.
Inspect default metadata too. TelemetryDeck documents app/build, device, operating-system, and run-context parameters in its parameter reference. PostHog documents capture switches and before-send redaction in its iOS configuration guide. The worksheet should describe the outgoing payload you actually allow, including automatically attached fields.
Both have funnels. Do they answer the same question?
TelemetryDeck's TQL funnel reference describes aggregating users for each step and intersecting those sets. PostHog documents sequential steps by default, with strict-order and any-order alternatives. A chart with decreasing bars is not enough to establish equivalent conversion semantics.
Use this tiny synthetic event set as a reasoning check. In one reporting interval, A views the paywall and then starts a trial. B starts a trial and later views the paywall. C views the paywall without starting a trial. All three have stable, distinct identifiers.
Membership asks: who performed both actions in the interval? A and B qualify: 2 of 3. Sequence asks: who started a trial after viewing the paywall, within the chosen conversion window? Only A qualifies: 1 of 3. These are different questions with different correct answers.
The set-intersection description does not establish PostHog-equivalent order or conversion-window enforcement. Confirm the exact TelemetryDeck query or feature you intend to use before relying on those requirements. This is a documentation distinction, not a claim that every TelemetryDeck analysis ignores time.
For retention, both tools have documented analysis: TelemetryDeck retention queries describe intersections between an initial period's users and subsequent periods; PostHog retention lets you specify start and return events and cohort options. Decide whether you mean calendar-week return, day-seven return, or a later core action. Exclude cohorts that have not had enough time to return. An active subscription is not itself proof that somebody used the app again.
Write an identity contract before joining subscriptions
TelemetryDeck describes hashing and salting the user identifier on the client, then another server-side hashing step. Its identity explanation says the same original identifier and custom salt can recognize a user across platforms. This design preserves analytical continuity without turning the dashboard into an email lookup tool.
PostHog's identity documentation describes joining anonymous activity to an identified user and resetting identity on logout. An opaque account ID can be your stable key; sending a name or email is a separate decision. Do not use a shared placeholder such as unknown for multiple users.
Record four lifecycle decisions for either implementation:
- First launch: where does the identifier come from, and which events happen before an account exists?
- Login: which identifier becomes authoritative, and what evidence shows that earlier and later events belong together?
- Logout or account switch: what changes before the next event and before the next purchase?
- Reinstall or second device: is continuity intended, and what restores the same account identity? Do not assume a device-derived identifier is a permanent person identifier.
For TelemetryDeck, also record who owns the custom salt and what happens if it changes. For PostHog, record when identification and reset occur. For both, verify the boundary between app identity and the subscription service's identity using synthetic accounts before relying on retention or revenue joins.
RevenueCat works with both; the handoff differs
| Destination | RevenueCat attributes | Common mismatch to check |
|---|---|---|
| TelemetryDeck | $telemetryDeckAppId and $telemetryDeckUserId. | The user attribute must contain the already-hashed identifier expected by the integration, not the raw account ID. |
| PostHog | $posthogUserId; without it, the integration falls back to RevenueCat's App User ID. | The fallback may differ from the ID used by app events. |
Sources: RevenueCat's TelemetryDeck integration and PostHog integration. TelemetryDeck's Swift integration walkthrough explains obtaining the client-hashed identifier. Update RevenueCat’s $telemetryDeckUserId whenever the TelemetryDeck user identifier changes, including relevant login or account-switch transitions. Follow the matching SDK documentation instead of inventing a second hashing pipeline.
Use the app's configured TelemetryDeck ID, or the correct PostHog project and region, and inspect the integration's available event and environment settings. Then make a synthetic sandbox purchase and verify both the delivery record and the destination event. Confirm that the app event and purchase event participate in the intended user history or analysis; a successful HTTP delivery alone does not establish a correct join.
Repeat for login, account switching, and restore scenarios relevant to your app. Changing a mapping today is not proof that historical events have been repaired. If you choose PostHog, our acquisition-to-RevenueCat guide covers the surrounding implementation.
Budget the data and the maintenance work
PostHog's current public pricing includes 1 million analytics events per month; its no-card Free plan lists one project and one-year data retention. Replay and flags have separate meters. The no-card plan stops usage at free limits, while pay-as-you-go uses product billing limits.
On September 20, 2026, TelemetryDeck's public pricing calculator, at its default 455,000-event estimate, displayed an Indie plan at €9/month with 750,000 monthly events, 24 months of retention, real-time data, and unlimited apps. This is a displayed plan estimate, not a paid invoice or a verification of taxes, renewal terms, or every available plan. Replace the default apps and volumes with your own.
As an original planning example, 2,000 monthly active users × 60 app events produces 120,000 events. Add an assumed 4,000 subscription events: 124,000 total. That is before any other automatic events you omitted. These inputs are fictional; they establish a counting method, not equivalent vendor billing or a predicted bill.
TelemetryDeck's FAQ distinguishes queryable retention from collection limits: on Free, events arriving after the cap are discarded. Write down the plan's current cap, retention window, and over-limit behavior before shipping. A retention report needs both stable identity and sufficient historical data.
Maintenance has its own cost. Count the work required to review automatic properties, preserve identity through login changes, reconcile subscription events, and explain a report. If aggregate app questions cover your weekly decisions, evaluate TelemetryDeck first. If account-linked investigation and ordered journeys are recurring needs, evaluate PostHog first. Do not add two production SDKs merely to postpone the decision.
A small evaluation you can finish before committing
- Choose one question from the decision table and the minimum events that answer it.
- Pin your SDK versions and save the actual configuration, payload fields, and identity transitions.
- Use synthetic A/B/C accounts to test event order, repeat events, and the chosen time window. Record expected counts before opening the report.
- For subscriptions, verify a sandbox lifecycle in both the sending service and the destination. Check that synthetic and production data remain distinguishable.
- Review the data you collect against your app's privacy disclosures. Apple's App Privacy Details guidance covers your app and integrated partners; a vendor's privacy positioning does not decide your implementation's disclosures or legal obligations.
- Choose the tool whose evidence answers the question at a maintenance cost you can sustain.
Keep the TelemetryDeck funnel reference open when defining membership, and the PostHog retention guide open when defining start/return behavior. These public resources explain the report semantics and remain useful without a sales demo. Recheck current pricing separately.
If PostHog is your choice and you want to check its data from an iPhone, see PostHog on iPhone with Hogly. That is an optional viewing workflow after the analytics backend and identity model are settled.
Quick answers
Frequently asked.
Does TelemetryDeck integrate with RevenueCat?
Yes. RevenueCat documents a TelemetryDeck integration using $telemetryDeckAppId and $telemetryDeckUserId. The user value must be the already-hashed identifier expected by TelemetryDeck. Verify the delivery and the resulting join with synthetic sandbox purchases.
Can TelemetryDeck measure funnels and retention?
Yes. Its documentation includes funnel and retention queries. Check the query's exact semantics: the TQL funnel reference describes intersections of users who performed steps, which should not be assumed equivalent to a sequential funnel with a conversion window.
Do I have to send email addresses to use PostHog?
No. You can choose opaque identifiers and explicitly control event properties. If you need account-linked analysis, design identification and logout/reset behavior deliberately. Your actual data collection, integrations, and disclosures still need review.
Which should an indie iOS developer try first?
Try TelemetryDeck first when aggregate app usage and return behavior cover your main decisions. Try PostHog first when ordered conversion analysis and account-linked investigation are recurring needs. Evaluate with a small event dictionary and synthetic identities rather than assuming a universal winner.