Privacy Policy

1. Roles

The owner of a Minecraft network decides to connect it and is the data controller for the player data from that network. MCAnalytics processes that data on the owner behalf as the processor. The terms of that arrangement are in the Data Processing Addendum.

For dashboard accounts, product usage, billing records, and Community access requests, MCAnalytics is the controller.

2. Data from a connected network

The connector plugin on your Velocity proxy and your Paper backends sends MCAnalytics the following:

• The player username and Minecraft UUID: the Mojang UUID for premium Java accounts, and the UUID the server assigns for other Java accounts. Bedrock players are identified by the Floodgate XUID.
• The hostname the player used to connect, which becomes their acquisition source.
• Join time, the time a login plugin confirmed the player, leave time, session length, and the backend server name.
• The Minecraft version the player connected with, or the server's own version on a Paper server with no proxy, and the client brand their game reports, such as vanilla or fabric.
• Confirmed cheat bans reported by GrimAC or Polar through the Paper connector, with the check that fired and its violation level.
• Server heartbeats: online player count, TPS, MSPT, memory use, how many times the server list pinged the server, and the connector version.
• Lag events, only while the network owner has switched lag profiling on: when a Paper server stayed under 18 TPS or over 50 MSPT for 30 seconds, the start and end, the lowest TPS, the highest MSPT, how many players were online, and the Spark link.
• Player events: what a player did inside one session. The commands they ran, by name only; how long their chat messages were; deaths, with the damage cause; kills, with the victim and the item held; advancements; moves between worlds and game modes; teleports, by destination world; respawns; kicks, with the message your server showed, cut to 128 characters; switches between backend servers; the language and view distance the client reported at login; and the counts for the whole session. The connector holds them in memory and sends them once, when the player quits.
• Heat, from Paper servers on the Network plan and up: once a minute, for each 16 by 16 block chunk players stood in, how many times the server looked and found a player there, and how many different players it has seen there that day. It names no player and carries no block position. With WorldGuard, the chunk bounds of the regions the server owner drew.
• Votes, when a voting site reaches Votifier or NuVotifier on your server: the name of the voting site, the username the site sent, the time the server received the vote, and the server. A vote is tied to a player by premium UUID or Bedrock XUID only, never by the username.
• Custom events, when a plugin on your server calls the connector API, or your own code posts to the events API with a key from Settings: the event name, up to 20 flat properties of at most 1 KB that you choose, the time, and the player's UUID or XUID if you send one. We hold them as you send them, so do not put chat, addresses or other private text in a property.
• The chunk a player was in when they left a Paper server, and on Velocity the backend servers a session went through, in order, with the seconds since the session opened. Both are kept 35 days and then deleted; what outlives them are daily counts per chunk and per server to server move that name no player.

We never receive block coordinates of a player. The finest position we receive about a player is a chunk, and the only chunk tied to a player is the one they left a server in. We never receive inventories: a kill names the item in the killer's hand and nothing else. We receive chat messages and full command lines only while the network owner has switched text collection on, which is off until they do. Passwords and private messages are never received at all. Section 3 says how that works.

Lag profiling is another setting that belongs to the network owner. It is off until they turn it on, and it needs the Network plan or up. While it is on, a Paper server that stays below the lag thresholds asks Spark to profile itself, and Spark uploads the report to spark.lucko.me as an unlisted link. Anyone who has the link can open the report, and a report can list your plugins and some of your server settings. spark.lucko.me is run by the Spark project, not by MCAnalytics. We store the link, never the report, and we cannot delete a report from that site.

World map

Only if the network owner turns it on. The owner of a network on the Network plan or up can turn on Render a world map (experimental) in Settings. It is off until they do. While it is on, each Paper server renders the terrain around spawn and around the chunks where players spent time, and sends us the rendered picture tiles, from above and in 3D. A tile shows what the ground and the builds in that area look like, so it can show what players built. Tiles never name or show a player, and we do not receive the world files, chunk data, signs or containers. Tiles are stored on our own server, in a folder for that network, up to 500 MB, and are shown only to signed in members of that network on the dashboard, never publicly.

Turning the map off stops rendering, and each server deletes its own map folder. Delete map data in Settings deletes every tile we hold for the network at once. Deleting the network deletes them too. To draw the textures, the first render downloads the Minecraft client for the server's version straight from Mojang to that server; nothing about the server is sent to us for it.

Anonymous case studies

Only if the network owner opts in. The owner of a network can turn on Share an anonymous case study in Settings. It is off until they do, and every plan can use it. While it is on, a nightly job builds one study from the network's own numbers, once it has 4 weeks of data and enough players. A study holds growth, Day 7 return and revenue as indexes, week numbers counted since the network joined, a size band such as 50 to 200 peak, and events from a short fixed list. It never holds the network name or slug, a hostname, a player name or UUID, or an exact amount. A study is public only after an operator approves it, at /case-studies.

We log when the owner switched it on or off, who did, and the Terms version then current. Switching it off deletes the study at once. The log stays while the network exists. Someone who knows a network well may still recognise the shape of its curves, and the owner is told so before opting in.

3. Chat and command text

Collect chat and command text is a setting in dashboard Settings. It belongs to the network owner and it is off until they turn it on.

While it is off, a chat message reaches us as a length bucket (short, medium, or long) and a character count, and a command reaches us as its label alone, such as spawn or kit. No words a player typed leave your server.

While it is on, we receive the chat message and the full command line, each cut to 256 characters.

Some commands never send their arguments, whatever the setting says. That list is built into the connector and cannot be switched off: login, l, register, reg, changepassword, changepass, cpw, unregister, 2fa, totp, email, password, pass, msg, tell, w, whisper, r, reply, pm, and mail. That covers passwords and private messages between players.

The connector reads the setting from the answer to its heartbeat, so a change takes effect within one heartbeat and needs no restart. A connector that has not had an answer yet collects no text at all.

4. Player IP addresses

The Velocity connector sends each player's IP address with the session, so the country can be read from it (section 5). The Paper connector sends it only when track-ip-address is set to true; it ships set to false. A Paper server behind Velocity does not need it, because the proxy already records the session.

When a session does carry an IP address, MCAnalytics replaces it with a keyed HMAC-SHA256 hash before anything is written. The key belongs to your network alone, the raw address is discarded, and the hash is used to spot duplicate sessions and abuse inside your network. It is not an anonymous value and it is never treated as a player identity or shared between networks.

The connector keeps the address in memory only: the copy of a report it saves to disk while it waits to send has no address. A cleanup that runs once a day clears the hash from every session 30 days after the join.

5. Player country

While the address is still in memory, and before it is hashed and dropped, we read one thing from it: the country, as a two letter ISO 3166-1 code. That country is stored on the session and on the player. The address it came from is not stored, in any form other than the keyed hash described above.

We store the country and nothing finer. No region, no city, no postcode, no coordinates. A network owner uses it to see which countries their players come from.

The lookup runs against a country database file held on our own server. IP geolocation by DB-IP, whose free DB-IP Country Lite database is the file we install. That is where the file comes from and nothing more: no player address is sent to DB-IP or to anyone else, and the lookup makes no network request at all.

A session that carries no address gets no country. Sessions recorded before this shipped have no country either, and never will, because the addresses they came from were already discarded. The dashboard shows both as Unknown.

6. Store purchases

If you connect a Tebex store, Tebex delivers each event to a webhook address that belongs to your network only, and we check the signature on every delivery before we read it. From each event we keep the transaction id, the amount paid and the list price, the currency, the package names, the creator code and coupon codes used, and the premium UUID of the buyer. We do not keep the buyer's name, email address, or IP address.

We use that UUID only to match the purchase to a player already on your network. Usernames are never used to match a purchase. A purchase we cannot match stays in an explicit unmatched bucket.

7. Dashboard accounts

There are three ways to sign in, and you pick one:

• Google, through Google OAuth.
• Discord, through Discord OAuth.
• An email magic link, delivered by Resend.

We store your email address, the name and avatar the OAuth provider returns, and the networks your account belongs to. With each sign-in session we store the IP address and the browser user agent, in the auth_sessions table, so a sign-in you do not recognise can be traced. The dashboard does not list them.

Product usage

Only if you opt in. The sign in page has a box, unticked, that reads Share how I use the dashboard to help improve MCAnalytics. Nothing in this part is recorded for your account unless you tick it, or turn on Share how I use the dashboard on the Account page later. Accounts that signed in before we asked are not recorded until they turn it on.

While it is on, the dashboard records which of its pages and features you use. Each record holds:

• A page key or a feature key from a fixed list, such as revenue or api-key.create. A record may carry one more value from a fixed list: the chart range, such as 30d, or the page a keyboard shortcut opened, such as players. Never the address of the page, and never anything shown on it or typed into it.
• How long you were active on a page: time while the tab was in front and you had clicked, typed, or scrolled within the last minute.
• The network that was open, your account, and the time.

We use it for two things:

• Deciding what to improve in the dashboard: which pages and features get used, and which nobody touches.
• Seeing which customer networks actively use MCAnalytics. Our operator console lists networks by name with their recent activity, and we use it, for example, to get in touch with a paying network that has gone quiet.

Our legal basis is your consent (Article 6(1)(a) GDPR). The records are written to our own database and nowhere else. No third party receives them, they are never combined with the player data of your network, and only MCAnalytics platform operators can see them. Saying no, or saying nothing, changes nothing else about your account.

You can withdraw your consent at any time with the same switch on the Account page. Turning it off stops recording at once and deletes the records we hold for your account. It also deletes the daily totals of every network where you are the only member, because those describe you alone. Daily totals of networks with other members carry no account id and stay until their 400 days are up (section 12). A deleted record can remain in a nightly backup for up to 14 days.

We never record platform operators, and a browser that sends Global Privacy Control records nothing, whatever the switch says.

8. Billing

Paid plans run through Stripe Checkout and the Stripe customer portal. Card details are entered on pages Stripe controls and never reach MCAnalytics. We keep the Stripe customer id, the subscription or payment id, the plan, the term, and the status, which is what the Billing page reads.

9. Community access requests

Community access is granted by an operator, not by a form. When you ask for it we store the email address or Discord handle you give us, your network name, the player scale you pick, and any notes. Requests are rate limited by connection, and the address used for that limit is not stored.

10. Cookies and browser storage

MCAnalytics uses cookies only to sign you in, and browser storage only to remember a few interface choices. There is no advertising cookie and no tracking cookie, which is why the notice on the site is a notice and not a consent wall.

We count clicks on our short links, such as /discord/modrinth, anonymously: only a daily total per link and where it was posted, with no IP address, device, cookie, or account.

Product usage (section 7) uses no cookie and no browser storage while you use the dashboard. The visit it belongs to is an id held in the memory of the open tab, and it is gone when the tab closes or reloads. The one cookie it needs is on the sign in page: if you tick the box, a short lived cookie carries that answer through the Google, Discord, or email sign in, and it is deleted as soon as you are signed in.

• Session cookie. In production the name is __Secure-better-auth.session_token, in local development it is better-auth.session_token. It is HttpOnly, SameSite Lax, and Secure in production.
• Short lived OAuth state cookies, set while a Google or Discord sign-in is in progress: __Secure-better-auth.state in production and better-auth.state in development. They expire in minutes.
• Short lived product usage answer, set only when you tick the box on the sign in page: __Secure-better-auth.usage_consent in production and better-auth.usage_consent in development. It is HttpOnly and SameSite Lax, holds nothing but the yes, is deleted once you are signed in, and expires in 10 minutes otherwise.
• Local storage key mca.sidebar remembers whether the dashboard sidebar is a rail or open.
• Local storage key mca.cookie-notice remembers that you dismissed the cookie notice.

11. Hosting and processors

MCAnalytics runs on a single server we operate ourselves. Public traffic reaches it through a Cloudflare Tunnel, so the machine opens no inbound port to the internet. These are the services that can see data:

These providers operate in and outside the European Economic Area. Where they process data outside it, they do so under their own published transfer terms.

12. Retention

Player sessions, player events, sources, purchases, lag events, and the country stored on a session stay while your network is connected, because return rates and revenue history are built from them. There are two exceptions. The keyed IP hash is cleared from a session 30 days after the join (section 4), and the text inside a player event is blanked at 30 days (section 3). A cleanup that runs once a day does both. We do not apply a shorter window to any of the rest, and we would rather say that than invent a schedule the code does not keep.

Server heartbeats are kept as sent for 7 days. After that the same daily cleanup keeps one per server per minute, and after 90 days one per server per 10 minutes, until the network is deleted. The heartbeat it keeps holds the highest player count of its minute or 10 minutes, the average TPS, MSPT and memory, and the number of heartbeats it replaces, so peaks and uptime read the same. A heartbeat carries no player data.

Product usage records (section 7) are deleted 90 days after we receive them. What outlives them is a daily count per network, page, and feature, with no account id in it, which is kept for 400 days. The record of your consent, which says when you gave it and whether on the sign in page or in Account, is kept while your consent stands and deleted when you withdraw it or when your account is deleted.

Votes and custom events are kept while the network exists, and go with it when the network is deleted. When a single player is removed, the UUID, the XUID and the vote username on their rows are cleared and the counts stay.

World map tiles are kept until the owner deletes them, turns the map off and deletes them, or deletes the network. A tile no map uses any more is deleted within a day of the next update.

Heat per chunk is kept for 90 days. The chunk a player left a server in and the route of each session are deleted after 35 days, and the daily route counts built from them, which name no player, are kept for 400 days.

Database backups are taken nightly and kept for 14 days, then deleted.

13. Export and deletion

A network owner can disconnect a Tebex store or revoke a connector at any time from Settings, which stops new data at once.

The owner can export every row the network holds as one JSON file from Settings, Data and privacy. Secrets, token digests and IP hashes are left out of it. The owner can delete the network from Settings, Danger zone: the subscription is cancelled first, then every row goes at once. Copies inside backups go when those backups are deleted, after 14 days.

The same data is available over the export API: players, sessions, purchases from every store, votes and custom events, as JSON or CSV, with a key from Settings, API keys on the Network plan and up. It carries no IP data and nothing a player typed.

If you add a Discord channel webhook in Settings, we post the alerts you pick to it: new purchases with the package, amount and store, and the player's username when the buyer matched by UUID, lag spikes, player cap phases, and a daily summary. The webhook address is stored encrypted. A log of what was posted, with a short summary and the result, is kept for 30 days.

To remove a single player, write to [email protected] from the owner account. There is no button for one player yet: we run it for you and answer within 30 days. We replace the player's username with an anonymous label and remove their UUIDs, IP hashes, chat text and command lines, and the UUID on their purchases. The counts stay.

14. Site analytics and server logs

We measure how our public pages are read: this site's home page, features, documentation, setup guide, comparisons, guides and legal pages. The dashboard, sign in, the live demo and support transcripts are not part of it. The measuring is done by a small script from our own server, and what it sends goes to our own database and nowhere else.

For each page you open, it records:

• The page's path, such as /docs/quickstart, never the query string. On the first page of a visit, the host name of the site you came from, such as google.com, never the full address of that page. The one exception to the query string is a link name: if you arrive by a link we shared that ends in ?ref=oa (or ?utm_source=oa), the short name after it, such as oa, is recorded when it is only lowercase letters, digits and dashes and at most 32 characters long, and anything else in the query string is ignored. We then remove ?ref= from the address bar.
• Which parts of the page were on screen for about a second (at least half of the part, or half the screen for a long one), how far down you scrolled in quarter steps, which of our buttons and links you clicked (by a name we gave the button or by where the link goes), whether the intro video started, passed a quarter, half and three quarters, and reached its end, which part of the page was most on screen and how far down you were when you left or switched to another tab, and for how many seconds the page was visible, up to 30 minutes.
• The country, as a two letter code, from the header Cloudflare adds to each request, or from our local country database (section 5) when that header is missing.
• A visit id: a random value held in the memory of the open tab, gone when the tab closes or reloads.
• A visitor key: a keyed HMAC-SHA256 hash of your IP address, your browser's user agent and the date (UTC), cut to 12 characters. It lets us count one person once per day. The date is part of the hash, so the key changes every day and cannot follow you from one day to the next.

It uses no cookie, no local storage or other browser storage, and no fingerprinting. Your IP address and user agent are read to make the visitor key and to tell bots from people, and are not stored. To rate limit the script, a separate keyed hash of the IP address is counted per minute and deleted within a day. Nothing you type on a page is recorded.

A browser that sends Global Privacy Control or Do Not Track is not measured at all: the script is not loaded, and our server drops anything that arrives with either signal.

Our legal basis is our legitimate interest (Article 6(1)(f) GDPR) in knowing which parts of our site help people decide and which they skip. Only MCAnalytics platform operators see the numbers.

Separately, the web server in front of the site (nginx) writes a log line for every request, to the site and to the API: the IP address, the time, the requested address including any query string, the response status and size, the referrer, the user agent, and timings. We use these logs to investigate errors and abuse. While a server container runs, its log is kept by that container. When we deploy a new version, the old container's log is saved to a file on our server, readable by the administrator account only, and saved files are deleted after 14 days. A log line is therefore kept until 14 days after the deploy that follows it.

15. Changes and contact

If this page changes in a way that matters, the date at the top changes with it. Questions go to [email protected]. Product questions are answered on the FAQ and in the documentation.