How the numbers are calculated

Net revenue is the headline

The P&L, the digest and the board all lead with net revenue: what reached you after payment fees, store fees, refunds and disputes. Gross is shown next to it where we have it, but it is never the main number.

The reason is that gross means different things in different places. Stripe's gross leaves out tax, while RevenueCat's gross is what the customer paid, VAT included. Adding the two would mix numbers that were never measured the same way. Net is the one figure that compares fairly across Stripe, the App Store, Google Play and the web.

Gross and net, per source

MRR from Stripe is built from subscription items, not payments: each item's price is normalised to a month (an annual plan counts a twelfth), recurring discounts are subtracted and tax is left out. Active and past-due subscriptions count; trials, paused and cancelled ones do not. Proration lines and one-off sales are cash, not MRR. Lifetime deals show up in revenue, never in MRR.

The app stores directly

If you don't use RevenueCat, App Store Connect and Google Play can supply app revenue themselves. Their numbers are proceeds: what Apple and Google pass on after their commission or service fee, so they compare with Stripe and RevenueCat net. Store reports arrive later than Stripe or RevenueCat: Apple publishes a day's sales about a day later and sometimes restates recent days, so the last three days are read again on every sync. Google posts estimated sales after a few days, and a month's earnings report in the following month, so the current and previous month are read again on every sync. “Data through” moves to the slower source. We backfill from Apple's daily reports, which cover the last 365 days, and from Google's report files for up to two years where they exist. Daily App Store figures come from Apple's sales reports; your monthly Apple payment is final and can differ slightly. Play figures for the current month are estimated until Google's monthly earnings report arrives. Active subscriptions and trials come from Apple's daily subscription summary.

GA4 as an estimate

A product with no Stripe, RevenueCat, App Store Connect or Google Play source can use the purchase revenue your site or app sends to GA4 (GA4's purchase revenue), if you switch the estimate on for that product. That figure is an estimate, as your tags report it, before store or payment fees, and without refunds your app doesn't report to GA4. It includes taxes if your tags do, and depends on your tracking being right. GA4's total revenue is never used, because it also counts ad revenue. The estimate is always labelled “Estimate”, profit built on it is labelled too, it never sets a dollar amount on a Focus card (traffic-based cards can still fire), it never drives a money alert, and it never appears on the board or earns a verified badge. When a product runs on an estimate, the portfolio total is marked as including an estimate. Connect a real revenue source and the estimate stops being used at the next sync. The estimate is never used for MRR or subscription numbers.

Ad earnings

If your app shows ads through AdMob linked to Firebase, or your site through AdSense linked to GA4, GA4 reports your daily ad earnings (its total ad revenue), and we read them with the same read-only GA4 access. Nothing to switch on. They are AdMob's and AdSense's own estimates, and the payout can differ, so they are always labelled “Ad earnings (estimated)”.

• Added to profit, not to revenue. Profit is revenue plus ad earnings, minus ad spend and fixed costs. Ad earnings never appear in Sales, Proceeds or Revenue, and a product with only ads shows revenue as “—” with a real profit.
• Where they count: profit, the digest, the “set aside for tax” line, and one Focus rule: a product that lost money three months running (sunset candidate), and only when it also has a revenue source.
• Where they don't: money alerts (revenue and MRR), “Did it work?” (net revenue), and the board, which shows verified revenue only.
• A day on which a connected revenue source hasn't synced keeps its profit unknown (“—”), even with ad earnings.
• They don't switch on the GA4 purchase estimate. A GA4 property and its own streams count once, like traffic, and no other source is read for ad earnings, so they are never counted twice.

Data-through dates, and a dash versus $0

The app shows “Data through” a date: the latest day every connected source has finished syncing, so a total never mixes a fresh Stripe day with a GA4 day that hasn't arrived yet. A new connection syncs as soon as you connect it, then every source refreshes four times a day; alerts and Focus cards run once a day. Stripe and RevenueCat report in UTC days, GA4 in your property's time zone. GA4 can still revise the last 24 to 48 hours, so we re-fetch recent days on every sync and the last couple of days can move a little.

A dash (“—”) means we have no data for that cell: the source isn't connected, hasn't reported yet, or doesn't measure that thing. $0 means the source reported and the answer really was zero. Data from connected sources is never gap-filled with zero, because a fake zero looks like a collapse.

Costs and profit

Profit is net revenue, plus any ad earnings, minus the ad spend and fixed costs you entered. Ad spend entered for a date range is spread evenly over its days, and monthly or yearly fixed costs are spread per day, so a week or a month always carries its fair share. Costs you don't assign to a product count as shared overhead: they reduce the portfolio's profit, not any single product's.

A shared cost can instead be split evenly across your products. Each day, the cost is divided by the products active that day, and each product's share shows in its fixed costs and profit. If you pause or archive a product, its shares move to the shared (Unallocated) row, and later days split among the products still active. On a day with no active product, the whole cost stays on the shared row, so nothing is lost. “Keep as overhead”, the default, keeps the whole cost on the shared row.

Ad spend you haven't entered counts as zero, and we flag the days with no entry, for example “No ad spend entered for 12 days in September 2026”, so a profit that looks too good has a visible reason.

Under the P&L, a product's revenue is broken down as Sales − Refunds − Fees and tax = Revenue. Sales are what customers paid; fees and tax are the store and payment fees, plus any VAT or sales tax the store kept before paying you. When some of those fees are estimated, for example Lemon Squeezy's fee or Google Play before its monthly earnings report, the line is marked “estimated”. If some revenue in the period has no sales figure behind it, the breakdown isn't shown, because it wouldn't add up.

If you set a percentage in Settings (1 to 60%), Plask shows that share of each period's profit as Set aside for tax. It's off until you set it. It is a reminder, not a cost: it is never deducted from profit, it shows 0 when there is no profit, and it is private, never on the board or your profile. It is an estimate, not tax advice.

One revenue source per product

RevenueCat can ingest your Stripe web purchases, so a product connected to both could count the same sale twice. Each product therefore has a revenue authority: Stripe, RevenueCat, or both added together.

• When a product has both, we drop RevenueCat's rows for Stripe and RevenueCat Web Billing sales (the stripe and rc_billing stores), because that money is already in the Stripe numbers.
• When both are connected, we ask once: “Does RevenueCat already include your Stripe sales?” Until you answer, a product whose RevenueCat data can't be split by store counts RevenueCat only. You can also force a single source for any product. That choice never hides App Store Connect or Google Play revenue: a store connection always counts unless RevenueCat covers the same store.
• Stripe products you haven't mapped to a product sit in an Unallocated row. If a RevenueCat product already carries Stripe sales while some Stripe products are unmapped, the portfolio total can count that money twice, so the app shows “Map your Stripe products” until you do. We don't silently drop the rows, because that would hide money from Stripe accounts we can't see.

Payment providers

Lemon Squeezy, Polar and Creem are in beta and connectable now, for your private P&L only: they are not on the public board yet. Each one is checked against a real account, by comparing a full sync with the provider's own dashboard totals, before it can be. Gross is before tax, in the original currency; net is gross minus fees and refunds; MRR comes from subscription prices. We backfill up to two years and refresh about every six hours.

Lemon Squeezy doesn't report its fee to other apps, so Plask estimates it at Lemon Squeezy's published 5% + 50¢ per order, plus its published surcharges, and labels the source “Lemon Squeezy (fee estimated)”. Where the estimate has to guess, for example a buyer's country, it errs high, so net is never overstated. Creem doesn't report its fee per payment either, so Plask estimates it at Creem's published 3.9% + 40¢ per successful transaction and labels the source “Creem (fee estimated)”. Polar reports its fees, so those are exact. Refunds land on the day the provider records them: the refund day for Lemon Squeezy, and the approval day for Polar. Creem doesn't report refund dates, so Plask books a refund on the day of the original sale, and totals for past days can go down when one comes in. Refunds more than 180 days after the sale aren't counted.

Coming soon, not connectable yet:

• Paddle, pending a check against a real dashboard. Paddle reports its fees, so they will be exact, and refunds land on the day Paddle approves them. When you connect Paddle, RevenueCat's Paddle sales will be left out, so they aren't counted twice.
• Dodo Payments. Dodo Payments doesn't report its fee per payment, so Plask will estimate it from its published fees and label the source “(fee estimated)”, so net revenue is approximate. Dodo Payments disputes aren't counted yet. When a period has one, the P&L says so.

Payment providers add up with Stripe and RevenueCat.

RevenueCat and the stores

RevenueCat already reads the App Store and Google Play for the apps it covers. When a product has RevenueCat and a store connection for the same platform, RevenueCat wins and the store's revenue for that platform is left out, so the same sale isn't counted twice. A store connection still counts for platforms RevenueCat doesn't cover, for example an Android app you sell without RevenueCat. A GA4 estimate is only used when none of these sources exist for the product. Stripe and a store connection add up, because they cover different sales: the web and the app store.

Currency

Every amount is stored in its original currency and converted to USD with the European Central Bank's euro reference rates, published around 16:00 CET on working days. Each day converts at that day's rate; weekends and holidays use the last published rate. Each currency's decimal places are handled individually, so yen and other zero-decimal currencies aren't divided by 100. These are reference rates for analytics, not accounting, so your payout bank's rate will differ slightly. If you view the app in another currency, it converts from USD with the same rates.

How Focus cards are chosen

Focus cards are rules first. Every Monday, for Pro accounts, each product is checked against these rules, and the thresholds are printed on the card so you can check them:

• Revenue vs traffic: revenue down 15% or more over 28 days while visitors held (down 5% or less).
• Leaking funnel: visitors up 20% or more week over week while trials or new paid were flat or down.
• Attention mismatch: a product earns at least three times its share of traffic and nothing shipped in 45 days, or gets 30% or more of the traffic while earning a quarter of its share or less.
• Falling trend: a Theil–Sen slope over eight weekly points, significant at p < 0.1 (Mann–Kendall), projecting a fall of 15% or more over four weeks in revenue, MRR or trials (visitors, for a product with no revenue source).
• Traffic drop: for a product with no revenue source, the last 7 days of visitors at least 30% under the median of the 4 weeks before.
• Sunset candidate: three losing months in a row with no traffic growth.
• Silence: revenue or traffic went to zero, or a connection is stale or needs a new key.
• Did it work: a marker's 14-day window closed this week.

Matches are ranked by likely impact times confidence. You get at most one card per product and three a week, and cards you already answered count toward the three. “Not now” quiets that rule for that product, and each “Wrong” halves the rule's weight for you.

The AI (Anthropic's Claude Haiku) writes only the one-line explanation, from the card's own evidence. If its sentence contains any number that isn't in the evidence, it is thrown away and the rule's plain sentence is used instead. The numbers are computed, not generated.

How “Did it work?” decides

A marker is a release, a campaign or a price change. Campaign markers are suggested when a new utm_campaign shows up in GA4, and created when you enter ad spend for a date range.

Release markers are added on their own, dated the day a new app version is first seen: its first download or update in App Store Connect, or the first day GA4 shows it with at least 3 users and 10% of that platform's users, so testers don't count. A version must be newer than every one seen before, and one already live when your history starts is not marked. If the store and GA4 disagree by more than 3 days, the store date wins. Delete one and it stays deleted.

• We compare the 14 days before the marker with the 14 days from it. Two whole weeks each side means every weekday appears twice in both windows.
• Each side is net revenue minus the ad spend you entered for it. The result is the change in that net over the 14 days.
• The normal swing is how much 14-day net usually moves, measured over the eight weeks before the marker.

Alerts

Alerts watch each product's net revenue and MRR every day, against a median and median absolute deviation over the previous 28 days. Moves smaller than 20% are ignored however unusual they are, and email is capped at three alerts a day. Days marked as estimates (a GA4 estimate, or Google Play before its earnings report) are skipped, so an alert is never raised on an estimated figure. Traffic is not alerted on: a drop in visitors shows up as a Focus card (revenue vs traffic, falling trend or traffic drop) instead.

What the board publishes

Nothing is public until you choose to list a product. When you add a product you pick one of three: list it, list it anonymously, or keep it private, and nothing is pre-selected. You can change it at any time under Settings, Public profile. “List all my products” first shows the products it would list (your current, unpaused products) and asks whether to list them by name or anonymously, with no default; products you add later get their own choice. “Unlist all” makes every product private and turns your profile off in one step. A listed product's numbers are shown exactly. The board shows a labelled sample and is kept out of search engines until 25 makers are listed.

The board ranks by revenue by default, and by growth or profitable streak if you switch the sort. MRR and the profitable streak are the same whichever period you pick. A named maker's row adds up only the products they list under their name and haven't paused; anonymous and paused products never count, and a maker whose only listed products are anonymous shows no maker figures.

Names, links and anonymity. A named product shows its name, tagline, up to three categories, its platforms (taken from your connected sources; you can untick one) and any X, Bluesky or website links you add, with your handle, and has its own page with a Visit button and a Share menu. App Store and Google Play buttons appear only if you turn on “Show store links on the board” and only from a verified store connection; there is no field to type a store link. An anonymous product shows only “Anonymous product”, its platforms, its numbers and verified badges: no name, tagline, categories, description, links or icon, and it never appears on a maker page. If you stay anonymous as a maker, the board shows no name, handle or links for you: you appear as “Anonymous maker”, with no profile page or share card, and every product you list is shown as an anonymous product. Anonymity hides names and links, not numbers. Website links must be https, and every link opens with rel="nofollow ugc".

The board never publishes:

• Profit as an amount. Profit only ever appears as a streak of months.
• Anything from GA4, Google Search Console, Apple Search Ads or Meta, including traffic, search clicks and impressions, GA4 revenue estimates, cost per install or return on ad spend.
• Any ad spend. A month where Apple Search Ads was your only paid channel isn't judged for the streak, because even a yes or no there could reveal Apple Search Ads results, which Apple's terms don't allow.
• Customer names, emails or any customer-level data. We don't store it in the first place.
• Units, downloads or analytics from any store.
• Anonymous products in a maker's totals. They never count toward a named maker.

Public pages read from a published snapshot, not your live data. Changing a setting rebuilds it straight away. Leaving the board or switching to anonymous takes effect right away. Cached copies of the board, the Markdown pages and share cards can take a few minutes to update. The snapshot also refreshes every night. Opting in means accepting the opt-in terms; we record which version you accepted and when, and if the wording changes your profile stops publishing until you accept the new text. After “Unlist all” or turning your profile off, listing anything again asks for your consent again. If your first listing is anonymous, no public profile page is created.

Connections are read-only, and keys and tokens are encrypted at rest (AES-256-GCM). We never pool or publish GA4, Meta or Apple Search Ads data, and there are no cross-customer benchmarks. See privacy for the rest.