Privacy policy

Two very different audiences are concerned, and they need separating before anything else. If you operate a server, you are our customer: you have an account, you entrust data to us, and most of this document concerns you directly. If you play on a server that uses Minealyze, you have no account with us and you are not our customer: we process data about you on behalf of that server's operator, and it is that operator you should approach first.

For the game and revenue data ingested from your server, the server operator is the data controller and Minealyze acts as processor: we process that data on their instructions, within the scope of the service. For the operator's own account data (identity, email, session, billing) and for the audience measurement of our own site, Minealyze is the controller.

Opening and using an account produces the following data, which is ours to protect.

• Name, email address, an email verification flag, and a profile image if you set one.
• Password, stored as a hash by the authentication library, never in clear text.
• Web sessions: session identifier, expiry date, IP ADDRESS and browser user agent, active organization. The last two serve to recognise a session and protect the account.
• Organization membership and the role held within it.
• Billing: Stripe customer and subscription identifiers, plan, status, period dates. No card data.
• Server API keys, stored as a hash, with their first characters in clear text so you can recognise them on screen.

The plugin emits events by category, each of which can be switched off individually in its config file. Here is the actual list of categories.

• Sessions: join, leave, duration, active time excluding idling, world.
• Onboarding milestones: a new player's first times (first chat, first milestone, and so on).
• Blocks: placing and breaking, AGGREGATED into per-material counters over an interval, not event by event.
• Chat metadata: message LENGTH and number of mentions, only.
• Deaths: cause of death, and the killer when it is a player.
• Progression: native game advancements, with recipes filtered out.
• Economy: sampled balance via Vault, if that plugin is present.
• Ranks: sampled rank via LuckPerms, if that plugin is present.
• Social proximity: co-presence edges between players, sampled within a radius, never transmitting a raw position.
• Votes received on server lists.
• Heartbeat and server health: the machine, not the players.

The list of absences is worth as much as the list of presences, and this one is verifiable in the plugin's code.

• No message content. The message is flattened to text just long enough to measure its length and count at-signs, then discarded without ever leaving your server.
• No sign text, book text, player-written command, or private message.
• No player IP address. The plugin emits none, and we derive no geolocation from any.
• No username. The plugin transmits only the Minecraft UUID, never the nickname.
• No raw position coordinates: proximity is reduced to pairs of players present together.
• No file from your server, no world save, no configuration of your other plugins.

The Minecraft UUID sent by the plugin reaches us encrypted in transit, then is immediately replaced, at ingestion, by an HMAC-SHA256 hash computed with a salt specific to your organization. The raw UUID is never written to the database. Because the salt derives from your organization identifier, the same player's hash is DIFFERENT from one customer to another: two operators cannot cross-reference their databases to reconstruct one person's path.

A player record may carry a nickname, but it never arrives through the plugin. It exists only if you imported a pre-existing Plan database, from which we take the username without overwriting a value already known. Outside that case, a player record holds only a hash, counters, and dates. Be aware that this nickname, where it exists, is sent to the language model when a risk card narrative is drafted: that is detailed below.

Beyond events, we keep an aggregated state per player and per server: UUID hash, nickname where applicable, acquisition source, first and last seen, session count, total and active playtime, payer status and total amount spent, an opted-out-of-nudges flag, and a Discord identifier if the player linked their own account. Computed scores are added: recency, frequency and monetary segmentation, and a churn risk score.

If you connect a shop, we receive its payments so revenue can be tied to play behaviour. With Tebex, your shop sends us a signed webhook that we verify with the secret you supplied. With Azuriom, which emits no webhook, we are the ones periodically querying your site's API with the read-only token you entrusted to us. In both cases we record the transaction, amount, currency, item, recurrence, and dates, attached to a UUID hash. We receive no buyer name, address, or email, and no card data at all.

You can upload the SQLite database of the Plan plugin to bring over your history. We read its players, their sessions, and their playtime. The nickname and geolocation tables present in that file are read in order to be COUNTED in the import report, then ignored: their content is not kept. This is the only path by which a nickname enters the product.

Each processing activity has a purpose, and we pursue no other.

• Giving you back your server's activity: audience, retention, cohorts, economy.
• Detecting anomalies and players slipping away, through a deterministic computation.
• Letting you run win-back campaigns and measure their real effect against a holdout group.
• Drafting summaries and proposed messages, when you use the assisted features.
• Operating and securing the service: authentication, rate limiting, audit log, billing.
• Understanding usage of our own site, when audience measurement is enabled.

The only model provider wired in is Anthropic, and it is called only if a key is configured. Risk prediction, segmentation, and effect measurement are entirely deterministic: no model computes them. The model only steps in for WRITING, from figures already computed. Here is what actually leaves.

• Aggregates and already-computed figures, plus a non-identifying server context.
• The player's NICKNAME, where one exists, when drafting the narrative of their risk card.
• The tone examples you supply yourself for drafting win-back messages.
• Never the raw UUID, never the UUID hash, never any chat content, never any account data.

Anything originating from a player or from your configuration is treated as hostile input: it is wrapped in a separate data channel, stripped of control characters, bounded in length, and the authority channel explicitly states that such content is never an instruction. The model's output is constrained to a schema, and it triggers no action by itself: every action goes through a deterministic allowlist and through your confirmation. Scheduled calls use Anthropic's batch processing API.

You can register your own Anthropic key. It is encrypted at rest, tested with a minimal call, and only its last four characters can be displayed. From then on, your organization's calls go OUT ON YOUR KEY: the contractual relationship with Anthropic becomes yours, your terms and your retention settings apply, and usage is billed to you. This does not change the nature of what is sent, described in the previous section.

If you configure a Discord webhook for a server, we publish there the content you asked for: daily brief, weekly briefing, anomaly alerts. The webhook URL is a bearer secret, and we keep it encrypted. What we publish then goes to Discord, under its own terms, and becomes visible to anyone with access to the channel you chose. That destination is your choice, not ours.

An optional feature lets you situate yourself against other servers. It is strictly opt-in at organization level: without explicit activation, your servers contribute to no aggregate and you read none. The aggregates produced carry NO column identifying a customer: only the metric, the period, the number of contributing servers, and percentiles. A value is served only above a minimum number of contributors, failing which the product answers "not enough data" rather than letting anyone guess who is behind the figure.

These are the third parties that may receive data, and the exact condition of their involvement. No other is wired in.

• Railway Corporation (United States): hosting of the site, the API, and the database. All stored data resides there.
• Anthropic (United States): assisted writing. Only if a model key is configured, yours or ours.
• Stripe: subscription payment. Only on paid plans. Card data is entered at Stripe and does not pass through us.
• Resend: sending of transactional email. Only if a sending key is configured; otherwise sending is a no-op.
• PostHog (European hosting by default): audience measurement of our site. Only if a measurement key is configured.
• Cloudflare: the Turnstile anti-bot widget on the sign-in and sign-up forms. Only if a site key is configured.
• Discord, Tebex, Azuriom: solely for the integrations YOU connect, with the secrets you supply.

Hosting and several sub-processors are located outside the European Union, mainly in the United States. Such transfers must be framed by a recognised mechanism, typically standard contractual clauses. The exact state of those commitments for each provider is being formalised and will be stated here rather than presumed.

Retention of event detail is set per organization, within a maximum bound fixed by the plan, and an automatic purge runs regularly to delete whatever falls outside the window.

• Event detail and economy snapshots: the period you choose, capped by your plan (twelve months on entry plans, longer on higher ones). Whatever exceeds it is deleted by the purge, and the purge itself is logged.
• Player records, game sessions, scores, and payments: kept as long as the server exists, then deleted with it.
• Export files: automatically purged after a short delay, on the order of a day for product exports and a few days for GDPR exports.
• Account and billing data: kept as long as the account exists, and beyond that for whatever accounting obligations require keeping.
• Audit log: kept for traceability. No automatic purge is applied to that log today.

A deletion request targeting a player erases their record and, by cascade, their sessions, events, scores, milestones, and targeting entries, and a per-table count is kept as proof of execution. The link to their payments is severed, but the anonymous accounting row remains, because revenue received cannot be erased. A request targeting the organization deletes all its servers and the collected data depending on them. The account itself, its members, its billing, and the audit log are not carried away by that operation: to have the account closed, write to us.

The deletions described above apply to the production database. We claim no propagation delay to any backups, because that mechanism is not described in our code and a privacy policy should not promise what it cannot prove. This point will be stated once the hosting backup policy has been settled and documented.

The following measures are in place, and they are in the code.

• AES-256-GCM authenticated encryption of the secrets you entrust to us (shops, Discord webhook, model key), with a master key held outside the database and version handling for rotation. In production, the absence of that key makes the operation fail rather than encrypt with a known key.
• API keys and passwords stored as hashes, never in clear text, never logged.
• Strict isolation per organization and per server across all data tables, with a role check on every sensitive route.
• Player UUID hashes salted per organization, which makes databases incomparable between customers.
• Rate limiting per IP address, and stricter limiting on authentication routes.
• An append-only audit log whose details are pseudonymized and contain neither secrets nor raw personal data.
• Immediate and permanent revocation of a compromised API key.

The churn risk score is computed automatically at regular intervals from observed activity. It ranks players and feeds the targeting of your campaigns. That score produces no legal effect by itself and deprives no one of a service: at most it leads to a cosmetic or social message being sent, and only after your confirmation. A player can be flagged as opted out of nudges, and that flag exists precisely to be respected.

Minecraft communities include many minors, and we have no way of knowing a player's age: we collect no date of birth and no identity. This is why collection is minimal by construction and why player-written content is never transmitted. The service is not aimed at minors as users: it addresses server operators. As the controller, it falls to you to inform your community and to obtain the consent required by the law applicable to it.

Depending on the law applicable to you, you may have rights of access, rectification, erasure, restriction, portability, and objection. For account data, write to us directly. For a player's data, the request must go through the operator of the server concerned, who is the controller for it and who has the export and deletion tools in the product to carry it out. The GDPR page describes the mechanics in detail.

If you believe the processing of your data is not compliant, write to us first: it is the shortest path. You retain in any case the right to lodge a complaint with the competent supervisory authority of your place of residence.

Our site sets a session cookie for authentication, a language preference cookie, and, where audience measurement is enabled, PostHog's cookies. Cloudflare's anti-bot widget may also set its own cookies on the sign-in pages. No advertising trackers. The detail is on the Cookies page.

This policy evolves with the product. The date at the top of the page indicates the version in force. A material change to purposes, sub-processors, or retention periods will be announced before it takes effect.

Questions about this policy and about data protection can be sent to contact@minealyze.com.