GDPR

For game and revenue data, the server operator is the controller and Minealyze is the processor: we process on their instructions and give them the tools to honour their players' requests. For the operator's account data and our site's audience measurement, Minealyze is the controller. One and the same server can therefore fall under both regimes depending on the data at hand, and that is why the distinction opens this document.

Processing on behalf of a controller must be framed by a written agreement setting out the subject matter, duration, instructions, confidentiality, security, use of further processors, and the fate of the data at the end of the contract. We make such an agreement available on written request. Its final drafting is a matter for a lawyer and is not fixed by this page.

The legal basis depends on the purpose, and it is not the same for you and for your players.

• Descriptive server analytics: the operator's legitimate interest in understanding and sustaining their community.
• Churn risk detection: the same legitimate interest, over data already collected, with no new data.
• Win-back messaging to identifiable players: depending on jurisdiction and channel, consent may be required. The operator is responsible for it.
• Operator account and billing: performance of the contract, and legal obligation for whatever accounting requires.
• Service security, audit log, rate limiting: legitimate interest in protecting the service and its users.
• Cross-server comparison: voluntary activation by the organization, revocable.

Three sources feed the product, and only one concerns players. The plugin installed on your server emits game events attached to a UUID hash. Your connected shop supplies transactions attached to the same hash. An optional import of a Plan database brings history, and that is the only path by which a nickname enters the product. The exhaustive detail of what is collected, and of what never is, sits in the privacy policy.

The Minecraft UUID is replaced at ingestion by an HMAC-SHA256 hash salted per organization, and is never written in clear text. Because the salt is tenant-specific, the same person carries a different hash at two customers: cross-referencing databases is structurally impossible. Player-written content is never collected: the plugin measures only a message's length and its mention count, then discards the text on your server.

No decision, score, or measurement is produced by a model: all of that is deterministic. The model only writes, from figures already computed. A player's nickname, where one exists, is sent to the model when drafting the narrative of their risk card, in an isolated data channel. Content originating from a player is never treated as an instruction and can trigger no action: the model's output is constrained to a schema, and every action goes through an allowlist and your confirmation.

Minecraft communities include many minors, and the product knows nobody's age: it collects no date of birth, no identity, no address. That is the deeper reason for the minimization described above. The GDPR sets an age threshold for children's consent to information society services, which each member state may lower within a range running from sixteen down to thirteen. As the controller, it falls to you to apply the threshold of your community's jurisdiction and to obtain the consent required.

Hosting of the application and the database is located in the United States, as is the language model provider when it is called. Audience measurement uses European hosting by default. These transfers outside the European Union must rest on a recognised mechanism, typically standard contractual clauses. The exact state of those commitments per provider is being formalised: we prefer to write it this way rather than assert a compliance we cannot yet document.

Over your own account data you have rights of access, rectification, erasure, restriction, portability, and objection. Those requests are handled in writing at our contact address. You should know that no self-service account deletion route exists in the product today: closing an account is requested and carried out by hand on our side.

A player has no account with us and cannot be identified to us: we hold only a salted hash. Their request must therefore go to the server operator, the only party able to link a person to their hash. The operator has the tools in the product to actually carry it out, described below. We assist the operator in that execution, but we cannot stand in their place.

The product exposes traced GDPR requests, reserved to members holding an administration role, and each leaves an auditable record of its execution.

• EXPORT request targeting a player: produces a JSON file containing all of their rows, profile, sessions, events, attached payments, milestones, scores, watchlists, and targeting entries.
• DELETION request targeting a player: deletes the player record, which cascades to everything attached to it, and keeps a per-table count as proof of execution.
• EXPORT request targeting the organization: produces a JSON summary of servers and per-table counts.
• DELETION request targeting the organization: deletes all of its servers and, by cascade, the game data collected.
• Each request keeps the subject's hash, copied at filing time, so that the record of execution SURVIVES the erasure of the person.
• The files produced are downloadable for a limited time, then purged automatically.

An honest policy must say where erasure stops. Deleting a player severs the link between them and their payments, but the accounting row remains unattached, because a transaction received must remain justifiable. Organization-level deletion erases the servers and their game data, but deletes neither the account, nor its members, nor the billing history, nor the audit log: those are operator data, not game data, and they are handled by a separate request.

A player record carries an opted-out-of-nudges flag. A flagged player is excluded from campaign targeting. It is the most direct way to honour an objection without erasing the history of a player who keeps playing, and it falls to the operator to set it as soon as a player asks.

The retention period for event detail is set per organization, within a maximum bound determined by the plan, and changing that setting is reserved to the organization owner. An automatic purge runs regularly, deletes event detail and economy snapshots older than the chosen window, purges expired export files, and records its own pass in the audit log as counts. A plan downgrade lowers the bound and therefore triggers a purge on the next pass.

The GDPR requires a controller to answer a request within a bounded period, extendable depending on complexity. One point must be clear: no timer, no alert, and no deadline are implemented in the product to enforce that period. Follow-up therefore remains a human discipline, on the operator's side for their players' data, and on ours for account data.

The technical measures are detailed in the privacy policy: authenticated encryption of customer secrets at rest with a master key held outside the database, hashes for API keys and passwords, strict isolation per organization and per server with role checks, player hashes salted per tenant, rate limiting, and an append-only audit log whose details contain neither secrets nor raw personal data.

In the event of a personal data breach affecting data processed on your behalf, we undertake to inform you without undue delay and to provide the elements you need so that you can, as the controller, meet your own notification obligation towards your supervisory authority and, where applicable, towards the data subjects.

Every data subject retains the right to lodge a complaint with the competent supervisory authority, in principle that of their place of residence or work. We invite you to write to us first, but that remedy does not depend on our agreement and need not be preceded by an exchange with us.

Data protection questions, requests to exercise rights over account data, and requests for a data processing agreement can be sent to contact@minealyze.com. No data protection officer has been appointed to date.