privacy
What MRR Planet reads, what it keeps, who else touches it, and how to make it stop.
last updated 1 October 2026
jump to a section
the short version
MRR Planet reads your payments account so it can draw your customers as a world. To do that it holds three things: the email address you signed in with, the key you connected, and a copy of what that key returned. A fourth is optional and only there if you asked for it — a read-only grant to your own Search Console or Google Analytics, and the visit counts it returns.
None of it is sold, and none of it is handed to an advertiser. The public copy of your planet is written without your customers’ names, email addresses or payment history in it — not filtered on the way out, but built from a table that never contained them.
what signing in gives us
You sign in with Google or GitHub, and what comes back is a verified email address. There is no password here to lose, and an identity that cannot be reduced to a verified address is refused before an account exists.
That address is your account: it is how your planets are yours, where a receipt goes, and where the Monday email goes if you have asked for one. Your display name and avatar, if the provider offers them, are shown to you and to nobody else.
the key you connect
Connecting Stripe, Paddle, Polar, Lemon Squeezy, Dodo Payments or RevenueCat means giving this app an API key. Use the narrowest one your provider offers — enough to read customers, subscriptions and what they have paid, and nothing that can move money.
The key is encrypted against your planet and held on the server. It is never sent to your browser, never written into a page, and never included in a snapshot. Disconnecting destroys it: the secret is deleted rather than deactivated, and no copy is kept.
the google account you connect for traffic
A planet can also show where its visitors came from, and that means connecting either Search Console or Google Analytics. It is optional, nothing else in the app depends on it, and every permission asked for is a read-only one: https://www.googleapis.com/auth/webmasters.readonly, to read the search performance of sites you have already verified; https://www.googleapis.com/auth/analytics.readonly, to read the reports on a GA4 property you already own; and openid and email, so the settings card can tell you which Google account is connected rather than leaving you to guess. Nothing granted here can change, publish or delete anything at your end.
That permission is used for one thing: drawing your planet’s traffic. The app asks the Search Console API and the Analytics Data API for daily totals — clicks or sessions, impressions and average position where the source has them — the same totals broken down by country, and the few hundred busiest queries, pages or channels. Those numbers become the map in the atlas, the search tab, and the forecast that puts visits next to revenue. They are not used for advertising, they are not used to build a profile of you, they are not used to train any machine-learning or AI model, and they are not used for any purpose beyond the features just named.
On a Pro planet one more thing is done with the queries, and only with them. The few hundred busiest that are not the planet’s own name are sent back to Google — to the Google Ads API’s Keyword Planner, under this product’s own Google Ads account rather than yours — to ask how many people searched for each one in the countries your visitors come from, every month for the last four years, and which other searches are worded like them. Only the search strings and the countries are sent: no figure from your property, not the property’s name, and nothing that identifies you or the planet. What comes back are market-wide monthly counts for those searches, which become the season cards on the search tab and the season in your forecast. The list of searches asked about is kept under the same owner-only policy as the query report; the counts themselves are Google’s figures about a country rather than about you, are shared between planets that rank for the same search, and each is deleted as soon as no connected planet’s list names it. A free planet is never looked up; its search tab can show the shape of a year only where the counts for its searches were already fetched for a Pro planet that shares them, and it is shown that shape and nothing else.
What is kept is that answer and the key to it. The refresh token is held encrypted in the database’s vault, is never sent to your browser and never written into a page; alongside it sit the address of the Google account, the property you picked and the scopes you granted, so the card can show you what is connected. What is stored from the APIs is aggregated and not raw: totals per day, per country and per query, page or channel. Neither API discloses an individual visitor to this app, nothing here asks at a level where one could be identified, and no raw event stream or per-visitor record is requested, received or retained.
How it is protected. Every call to Google and every page of this app travels over TLS. The refresh token lives in Supabase Vault, encrypted at rest, addressed elsewhere by id only, readable by one server-side function that is granted to nothing a browser can reach and never returned in any response. The figures sit in tables with row-level security switched on and a single policy each — the owner reads their own, the sync job writes, and there is deliberately no policy for an anonymous or signed-out reader, so a leaked address buys nothing. Access is limited to the people who run this product, for the three cases named above, on the same principle.
Data read from Google is never sold, traded, or shared, transferred or disclosed to any third party. The one place any of it goes is back to Google itself — the query strings a Pro planet sends to Keyword Planner, as described above. No advertiser, data broker, analytics vendor or AI provider receives it. The only companies that ever hold it are the two running this product’s own infrastructure — Vercel, which serves the pages, and Supabase, which is the database and the vault the token sits in — and they hold it as processors under contract, for no purpose of their own. No human here reads it either, except in the three narrow cases: with your explicit permission, where it is necessary to investigate abuse or a security incident, or where the law requires it.
MRR Planet’s use of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements: https://developers.google.com/terms/api-services-user-data-policy
How long it is kept, and how it goes. Retention here is the life of the connection and no longer: the figures are held while the planet is connected, each read replacing the window it covers, and there is no archive behind them. You can end it whenever you like. Disconnect on the planet’s settings page and the token is deleted rather than deactivated — removed from the vault, not marked inactive — together with every figure derived from it, the days, the countries and the terms going in the same statement, along with the list of searches looked up in Keyword Planner and every count no other planet still asks for. Deleting the planet does the same, and closing the account takes the planets with it. Nothing is retained after that, and there is no backup copy to ask for. You can also withdraw the grant from Google’s side at https://myaccount.google.com/permissions, which stops the next read; the copy stored here goes when you disconnect or delete.
the posthog project you connect
A planet can also read a PostHog project, and unlike the Google sources above this one is about people rather than totals, so it is worth saying exactly what that means. It is optional and read-only: you paste a personal API key that you created and scoped yourself in PostHog — Query: read and Project: read are the two it needs — and nothing it is used for can change, publish or delete anything in your project. Only PostHog Cloud is supported, at us.posthog.com or eu.posthog.com, and no other address is ever sent your key.
What is asked for, once a day. Visits by day, by country, by the page people landed on and by the channel they arrived through — the same kind of totals the Google sources give. How many people were seen for the first time each week, and how many of them later identified. And, for the people in your project who have an email address on them, when they were first identified, how they first arrived — the referring site, the campaign tags, the first page, the device, browser, operating system and country PostHog recorded — and how many days they were active in the last two months.
How a person is matched to a customer, without either email being kept. When your payment provider is read, each customer’s email is turned into a keyed fingerprint (an HMAC under a secret that belongs to your planet and never leaves the server), and only the fingerprint is stored — and only while PostHog is connected. When PostHog is read, each person’s email is turned into the same fingerprint the moment it arrives and the email is discarded. Where two fingerprints agree, what PostHog said about that person is stored against your customer’s id. No email address, from either side, is written anywhere, and nothing about a person PostHog has who is not your customer is kept at all — only the weekly counts they are part of.
What it is used for, and nothing else: the funnel that follows a week’s visitors through to paying, which channels and pages your paying customers came through, which paying customers have stopped using your product, and the panel on a customer’s own page saying where they came from. It is shown only to you, on Pro. It is not used for advertising, not used to contact anybody, not used to train any model, and not shared with anyone; the only companies that ever hold it are Vercel and Supabase, as processors, as for everything else.
The key is held exactly as a payment key is — encrypted in the database’s vault, read only by the server, never sent to your browser. Disconnect PostHog on the planet’s settings page and the key, the visits, the weekly counts, everything stored against your customers and every fingerprint are deleted in one statement. Deleting the planet does the same. You can also revoke the key from PostHog’s side at any time, which stops the next read.
what we read from your provider, and keep
A read pulls your customers and their billing history: name and email address where your provider has them, country, currency, what each one pays, what they have paid, when they started and whether they are still here. That is your customers’ personal data, and you are the one who decided to put it in a payments system — here, we are processing it on your instructions.
It is stored as one private snapshot per planet, replaced whole every time the world is refreshed rather than edited row by row, plus the monthly and per-country totals the charts are drawn from. Only you can read your snapshot; the refresh job is the only thing that writes one.
what a visitor to your planet sees
A shared planet is not a filtered view of a private one. The public copy is written once, at snapshot time, into a different table — so the page a stranger loads reads a row that never contained a name, an email address or a provider id in the first place.
What survives is the crowd: every customer as a pet, in the right country, of the right species, the right size, well or ill or gone. Revenue is the one thing you decide — hidden, rounded into bands, or exact — and a world can be public, unlisted or private.
Two things are worth knowing before you publish. A planet’s address is a link other people can hold, and on the free tier a world that has been read stays up: taking one down is part of the paid plan. And a crowd is still information about your business, even without a name on it.
email we send you
Three kinds, and two of them you asked for. The weekly log is opt-in and every one of them carries a way out. Billing email — a receipt, a card about to expire, a trial ending — comes with paying for something and stops when you stop.
The third kind is the rare one: something about your account that you would want to be told, such as a read that has been failing for a week.
who else touches it
This is a small product built on other people’s infrastructure, and pretending otherwise would be the dishonest part. Data read from a connected Google account is the exception to the list rather than an entry in it: only Vercel and Supabase ever hold it, nobody else does, and the section above says so in full.
For everything else, the list is short and it is the whole list:
- Vercel — runs the site, and sees the requests that reach it.
- Supabase — the database, the sessions, and the vault the connected key is encrypted in.
- Stripe — takes the payment for a plan. Card details go to Stripe and never reach this app, which is also true when Stripe is the provider you have connected.
- Resend — delivers the email above.
- Google and GitHub — the sign-in you chose, which is where the verified address comes from.
- Google Analytics — counts visits to the public site, as above.
- The payments provider you connected — not a third party at all, but yours. We read it; we do not write to it.
- Google Search Console and Google Analytics, if you connected one — a source rather than a recipient, and yours as well. We read it; we do not write to it.
- PostHog, if you connected a project — a source too, and yours. We read it; we do not write to it, and nothing read from your payment provider is sent to it.
how long any of it is kept
A snapshot lives until the next read replaces it. Delete a planet and everything hanging off it goes with it — the snapshot, the public copy, the totals, the diary — in the same instant, and there is no archived copy to ask for later.
Ask us to close your account and the account row goes too. What outlives it is what somebody else is required to keep: a payment Stripe processed is a record Stripe has to hold, and the billing history against your customer there is theirs to keep, not ours to delete.
what you can ask for
You can ask what is held about you, ask for a copy, ask for it to be corrected, and ask for it to be deleted. Most of that is a button in the app already, and the rest is an email.
Write to hello@mrrplanet.com. If you are in the UK or the EU and you think this has been handled badly, you can also complain to your data protection authority.
about your customers, specifically
Your customers never signed up here, and their data is in this app because you connected an account that contains it. For that data you are the controller and we are the processor: we read it to draw your world, we keep it while you keep the planet, and we act on your instructions rather than on our own ideas about it.
If one of them asks you to erase them, deleting the planet or disconnecting the key removes the copy here; a customer removed at your provider stops appearing on the next read. We do not contact your customers, ever.
children
This is a tool for somebody running a business, and it is not for children. Accounts are for adults, and nothing here is aimed at anybody under 16.
when this changes
The date at the top is the day these words last changed, and it is set by hand — a deployment that moves a button does not move it. If something material changes about what is collected or who touches it, the account gets an email as well, because a quiet edit to a page nobody has open is not telling anybody.