[FR] Add consolidated revenue charts and financial overview

[LukasB-DEV]

Feature request: Consolidated revenue charts and financial overview

Hi Hyo,

first of all, thank you for building and maintaining this awesome project. IAPKit / OpenIAP already looks very promising as an open-source alternative for handling in-app purchases across platforms.

I would like to suggest a possible future feature: revenue charts and a consolidated financial overview.

The idea would be to have a dashboard where developers can quickly understand their overall IAP and subscription performance across platforms.

Possible metrics

• Total revenue over time
• Revenue split by platform, such as iOS and Android
• Monthly recurring revenue / estimated recurring revenue
• Active subscriptions
• New subscriptions
• Renewals
• Cancellations
• Churn
• Revenue by product or subscription plan
• Daily, weekly, and monthly charts

Useful filters

• App
• Platform
• Product
• Subscription plan
• Country or region
• Date range

Why this would be helpful

For indie developers and small teams, financial data from App Store Connect and Google Play Console is often fragmented and not very convenient to analyze together.

A consolidated revenue dashboard would make OpenIAP even more valuable, not only as an IAP implementation layer, but also as a central place to understand financial performance across stores.

This does not need to be a fully advanced analytics system from day one. Even a first version with basic revenue charts, platform breakdowns, product breakdowns, and estimated recurring revenue would already be very helpful.

Would this be something you would consider adding to the roadmap?

Thanks again for your great work!

[gitdogbot]

@LukasB-DEV Thanks for the detailed and thoughtful suggestion! Here's some context on how it maps to the current OpenIAP architecture:

Where this would live

The most natural home for a revenue dashboard is packages/kit — the hosted receipt-validation SaaS at kit.openiap.dev. According to the README, kit is already the "dashboard" layer of OpenIAP (free, MIT-licensed, self-hostable). A revenue analytics view would be an extension of that existing dashboard rather than a new standalone product.

The core IAP libraries (packages/apple, packages/google, and the framework SDKs) are pure purchase-execution layers — they don't store or aggregate transaction history, so revenue charts would need to live server-side in kit.

Key considerations for the maintainer

1. Data source: App Store Connect and Google Play Console don't expose real-time financial data via public APIs that a third-party backend can freely pull. Revenue data would need to come from verifyPurchase / finishTransaction events that kit already processes — so charts would reflect what passes through kit, not total store revenue.

2. Scope of v1: The suggestion to start small (basic revenue over time, platform breakdown, product breakdown) is realistic and aligns well with what kit already tracks per-transaction.

3. Self-hostability: Since kit is MIT and self-hostable, a revenue dashboard would benefit indie devs who run their own instance — not just users of the hosted version.

Recommendation

This is best tracked as a feature request for packages/kit (the dashboard SaaS), not the IAP libraries themselves. If you'd like to contribute, the packages/kit/CONVENTION.md file (referenced in the codebase) would be the starting point for understanding kit's data schema and conventions.

The maintainer (@hyodotdev) would need to weigh in on roadmap priority.

---

🤖 Generated by gitdog.dev · Have more questions? Tag @gitdog and let me know!

[hyochan]

Hi @LukasB-DEV — this just landed on main in #131 (squash-merged as 1880bc3) and is live on the kit dashboard's new Analytics tab.

What's in this first cut:

Headline cards & charts

• Revenue (initial purchases + renewals)
• Active subscriptions (end-of-period snapshot, including historical-day accuracy via Expired sub backfill)
• New subs, renewals
• Cancellations + refunds
• Churn rate — (cancellations + refunds) / activeSubs, same definition Stripe / RevenueCat surface

Filters

• Range: 7d / 30d / 90d (server caps at 92 days)
• Period: daily / weekly / monthly bucketing
• Product (per-SKU)
• Currency (required pin on multi-currency projects — revenueMicros can't be summed across currencies without an FX rate)
• Platform (iOS / Android, with a per-store card breakdown that's always visible)

How it's powered

• New revenueMetricsDaily Convex table — pre-aggregated from webhookEvents so the dashboard never scans the raw event log on render.
• 10-minute cron walks the trailing 3-day window per project (Apple ASN v2 / Google RTDN late-arrival retries fold into their correct day automatically — bucketing is by occurredAt, not receivedAt).
• Scheduler-chained pagination on both the events scan and the subscriptions scan, with per-day commit fan-out, so projects with many SKUs / currencies / active subs land cleanly inside Convex's per-mutation budgets.

Prerequisite
Apple ASN v2 / Google RTDN webhooks need to be wired up — verify alone doesn't tell IAPKit when renewals / cancels / refunds happen. There's a callout on the Analytics tab pointing at the setup guide.

Not yet shipped (could do as follow-ups if useful)

• Country / region filter
• MRR series chart (the underlying counter exists in subscriptionStats but isn't on the analytics page yet — let me know if you want it as a separate issue)
• Subscription-plan-level breakdown beyond the productId filter
• CSV / data export

Pull main and try it on a project with a wired-up webhook integration — feedback welcome on what's most valuable to expand next.

[LukasB-DEV]

@hyochan thanks for the nice work. It seems to not work. I can see tracked subscriptions in the subscriptions tab so webhooks are working but no entry on the analytics tab.

[hyochan]

Thanks for the report — this was a real cron picker bug, not a webhook setup issue.

Root cause: the Analytics rollup cron only rotated projects that already had a revenueMetricsRunStatus row, then padded from subscriptionStats only if the stale-status cohort did not fill the batch. Once enough projects were already seeded, a newer project with working webhooks/subscriptions but no revenue run-status row yet could be skipped indefinitely, leaving the Analytics tab empty even though the Subscriptions tab showed tracked subscriptions.

Fixed on main in 5482e819.

What changed:

• the revenue rollup picker now prioritizes recent webhookEvents for projects that have not been seeded yet
• it also checks recent subscriptionStats for unseeded projects
• the remaining batch slots still come from stale revenueMetricsRunStatus rows, so existing project rotation is preserved
• added regression coverage for webhook-backed and subscriptionStats-backed unseeded projects

Validation run locally:

• bun run --filter @hyodotdev/openiap-kit test -- convex/subscriptions/revenueMetrics.test.ts
• bun run --filter @hyodotdev/openiap-kit typecheck
• bun run --filter @hyodotdev/openiap-kit test
• bun run --filter @hyodotdev/openiap-kit lint

After the next deployed cron tick, webhook-enabled projects that were stuck in this state should start receiving revenueMetricsDaily rows and appear in Analytics.

[hyochan]

Follow-up after the Discord report:

• Production Fly logs showed Google RTDN requests were initially returning 503 because GOOGLE_PUBSUB_PUSH_AUDIENCE was not configured. I set the Fly secret so the endpoint no longer fails closed for that missing env var.
• After that, a direct prod Convex recompute for the RescueDogs project exposed the real Analytics rollup blocker: recomputeRevenueMetricsForProject could run more than one .paginate(...) in a single Convex mutation, which Convex rejects.
• Fixed in b125798 by chaining the event -> subscription phases through scheduler mutations and by accepting both origin and concrete push-endpoint OIDC audiences for Google Pub/Sub.
• Deployed Fly and Convex functions, then manually recomputed the RescueDogs project in prod. revenueMetricsDaily now has rows for the trailing window, so the Analytics page should no longer be empty for the Apple/iOS data that already arrived.

Google/Android events have not landed in Convex yet; once Pub/Sub retries or a new test notification is sent, the endpoint should accept the OIDC audience shape and ingest those RTDN events as well.

[hyochan]

Update: I found two separate server-side blockers after the previous deploy.

• 13e9b9f3 fixes the Pub/Sub OIDC authentication path. Google signs the push token as the configured push service account, not as the Google-managed Pub/Sub service agent, so the receiver now accepts Google service accounts by default and logs redacted OIDC diagnostics.
• a702a67b fixes the follow-up Convex ingest failure. Google RTDN includes version: "1.0" inside the notification objects, and the Convex action validator was rejecting that as an extra field before the handler ran.

Both fixes are on main. I also deployed Convex production manually because the GitHub workflow currently skips Convex deploy when KIT_CONVEX_DEPLOY_KEY is unavailable.

Production verification after deploy:

• Convex logs now show webhooks/google:ingestGoogleRtdn returning OK for new Pub/Sub retries.
• RescueDogs Google RTDN events are now stored for Android premiumj.
• Revenue metrics were recomputed for the project, and revenueMetricsDaily now has Android rows for premiumj.

The Google Play -> Pub/Sub -> OpenIAP path should now ACK successfully. Please refresh Analytics and retry the Google-side test if needed.

[LukasB-DEV]

Test was now successfull