Markerra Privacy Policy

Controller and deployment-specific roles

For markerra.app and the public demo, the controller is Przemysław Wiśniewski Digital (“PWD”, “we”), a sole proprietorship registered in CEIDG, Polish tax ID/NIP: 5243019522, REGON: 529876286, address: ul. Turmoncka 22/1103, 03-254 Warsaw, Poland.

Games published in Markerra Studio. For games an organizer builds and publishes themselves in the Markerra Studio panel, PWD is the sole controller of organizer data (account, payments) and player data (account, progress, rule acceptances). The organizer receives no access to players' personal data: they see only aggregate counts for their own game, with no way to identify individuals — with one exception, the leaderboard, described in the next paragraph. The organizer decides the content, rules, and reward of their game, but not how personal data is processed in the app and backend, and is therefore, apart from the leaderboard, neither a controller nor a joint controller in that respect. The rules players of such games accept are the Participation rules for Markerra Studio games.

Leaderboard in a Studio game. If an organizer turns on a leaderboard in their game — an optional list of the nicknames, places and times of players who finished the game and chose to appear on the list themselves — PWD and the organizer are joint controllers for that leaderboard (Article 26 GDPR); in all other respects PWD remains the sole controller of player data. The essence of the arrangement is this: PWD runs the leaderboard technically, collects players' consents, handles their rights and informs them, among other things through this document; the organizer decides whether to turn the leaderboard on and passes to PWD every player's request concerning it. Regardless of the arrangement you can exercise your rights against each of the joint controllers (Article 26(3) GDPR); the simplest way is to write to us. If the organizer is a natural person acting solely in the course of a purely personal or household activity (for example a birthday game), the GDPR does not apply to their own processing, and PWD, as the provider of the means of processing, is then the sole controller of the leaderboard. An organizer who uses the list outside the panel — for example to announce results or give prizes for a place — does so under their own rules and responsibility, as a separate controller of that use; PWD does not verify the leaderboard's results and takes no part in prizes.

Tailor-made deployments. A different allocation of roles can arise only in a tailor-made deployment launched outside the panel. Where the client in such a deployment determines purposes, participant groups, rules, content, rewards, or how data is used, the client may be a controller, a joint controller with PWD, or a separate controller; PWD may act as processor. Before launch we determine roles from the actual decisions, conclude an Article 28 GDPR processing agreement or Article 26 arrangement as appropriate, and identify the proper controller to participants in the deployment-specific notice. A deployment is not opened to real participants without that role allocation, the required agreement, and a published participant notice. The current demo is governed by the Technical Demo Participation Rules.

Privacy and support contact: kontakt@markerra.app.

Providers and recipients

• Appwrite Cloud acts as processor for app data and B2B inquiries; the project's primary region is Frankfurt in the EEA, while further subprocessors are covered by the DPA, SCCs, or an applicable adequacy decision.
• Cloudflare provides website hosting and Turnstile. Form protection receives data including IP address, user agent, TLS characteristics, sitekey/origin, and a verification token.
• Google provides login, Maps, code scanning, and — only after consent — website Google Analytics and Google Ads (Google Ireland Limited), which receives an aggregate form-submission conversion event without form content or email address. Apple provides login and iOS system services.
• A bug report sent through the email link reaches Gmail/Google with the text selected by the user and the included diagnostics.
• Depending on the platform, the app may use Apple, Google, and system map services.
• The deployment client receives only an aggregated functional and technical report, without users' personal data.
• Stripe handles payments for game publication in Markerra Studio — one-off and by subscription — and invoicing. This concerns the Paid Publication, that is, the time after the free period; during the free period we pass no data to Stripe. You provide card and payment-method details only to Stripe — they never pass through our backend; we receive the payment status, amount, currency, e-mail, billing address, VAT ID if provided for an invoice, and the country of the issuer of the card used to pay or, for a Link payment, the country of its funding source — a card or a bank account (a two-letter country code, if Stripe provides it). For a BLIK payment Stripe gives no country — we then take Poland as the country of the bank the payment came from and record only the name of the method (BLIK); we record no other account data. Before a subscription payment we create a customer in Stripe: we pass on the address of our billing mailbox (not your account e-mail address — we send the subscription messages, and to a private buyer also the link to the invoice, ourselves, through Brevo, to the account address), the account and game identifiers, the buyer type and the language of messages. For a payment session, one-off or subscription, we also pass on to Stripe the game name (it also appears in the item name on the invoice), the plan, the country chosen in the panel (in the US, also the state), the language, the Terms version and the statements made at checkout, with the time they were made and their wording versions. For a subscription this also includes the billing period and the consent to automatic renewal, and for a one-off payment the e-mail address of your account, which we use to pre-fill the payment form. Stripe keeps this data with the payment and the subscription, and we read it back when a payment is confirmed and at every renewal. The messages Stripe sends to a subscription customer (invoices, payment and refund confirmations, notices of a failed payment) reach that mailbox, kept with Google, through Cloudflare Email Routing. For a subscription, Stripe stores the card for the following charges and we never receive it; we receive the subscription identifier and status, the plan, the billing period, renewal dates, information about the ending (with date and time) and about payments that failed or need confirmation. Changing the card and, for a private buyer, the invoice history are handled by a Stripe page (customer portal). A company or institution ordering a subscription first saves a card in the Stripe window (where it also gives its name, address and tax number, if it has one), and we charge the first fee to that card straight afterwards; where the bank requires that payment to be confirmed, the buyer confirms it on a Stripe payment page. Where no contract for such a subscription is concluded (for example, the first payment does not go through), we detach the saved card (unless it is the card of another running subscription) and remove the name, address and tax number from the customer data in Stripe (unless the same customer has another running subscription or a newer order in Stripe that needs those data); if we had already tried to charge the fee, the voided payment document with those data stays in Stripe. The payment record (organizer, game, plan, amount, period, checkout consents — for a subscription also the consent to automatic renewal) is kept as accounting documentation for the period required by tax law — 5 years from the end of the year in which the tax payment deadline passed, and subscription payment records, together with the evidence of the consent to automatic renewal, for at least 6 years from the end of the year in which the subscription ended (section “Data retention”); this data is not removed on account deletion.
• Brevo (Sendinblue SAS, an EU provider) delivers Markerra Studio transactional e-mails. During the free period these are: the confirmation of the Free Publication contract, sent before the game is made available to players — Brevo then receives the e-mail address of the organizer's account, the game name, the end of the publication period, the game's limits, whether the organizer publishes as a private individual or as a business or institution, the country stated, the date and time of the confirmation, the contract identifier, the withdrawal deadline, the link to the withdrawal function in the panel, the text of the declarations made before publication (including the declaration under §10 of the Markerra Studio Terms) and the Terms in the accepted version as an attachment — and the acknowledgement of a statement of withdrawal from such a contract made with the function in the panel (the same data as for the withdrawal described further in this item). When an organizer states Ukraine, we send to our own operator address (through Cloudflare Email Routing to a Google-hosted mailbox) a notification that the request is waiting for a person's assessment — with the contract identifier, the game name and identifier, the account identifier and e-mail address, the publisher type, the country, the time of the request and the end of the period. The other messages described in this item concern the Paid Publication, that is, the time after the free period. For the confirmation of the publication agreement together with the withdrawal notice, Brevo receives the organizer's e-mail address and the confirmation content: game name, plan, amount, payment date, and the end of the publication period; where we have put the payment on hold for a country check, the confirmation says so and gives the general reason for the hold (for example no state in a US billing address, a country chosen in the panel that does not match the address country, or too little data to establish the country). For a subscription, Brevo also delivers the confirmation of the contract (with the billing period, the next renewal date and the text of the statements made), the confirmation of each renewal (or, where we have put the fee charged for the next period on hold for a country check or a sanctions check, or it was charged in a currency other than the zloty, a message about the hold instead, with the amount, the period and the general reason for the hold; for a sanctions check the reason is general, without naming a country: checking where the service is provided), reminders before a renewal, notices of a price change, messages about a payment that failed or needs confirmation, the confirmation of ending and of resuming, the message that the subscription has ended and the message about a refund; it then receives the organizer's e-mail address, the game name, the plan, the amount, the period, the payment, renewal and ending dates, for a refund — the amount and the reason for the refund, and a link to the panel, to the Stripe payment or invoice page or to the invoice PDF (a private buyer receives the link to the invoice for each period from us, because Stripe sends its messages to our billing mailbox). Brevo also delivers the acknowledgement of receipt of a withdrawal statement made with the function in the Markerra Studio panel — it then receives the address for the confirmation, the name, the text of the statement with the contract chosen (game name, type of contract, date of conclusion) and the date and time of submission — and the messages about a subscription ordered by a business that needs the payment to be confirmed (with a link to the Stripe payment page and the time by which it can be confirmed) or was not completed (with the general reason); it then receives the account e-mail address, the game name, the plan, the billing period and the amount. For the message about refunding a second payment for the same game, Brevo receives the buyer's e-mail address, the game name, the amount and the reason for the refund; the same applies to the message on the outcome of the sanctions check under §3 of the Studio Terms if we send it through Brevo — it then also carries the country established from the payment details. For an order marked as a business purchase we additionally send — to our own operator address — a notice about the invoice to be issued outside Stripe (for a subscription — at the first payment and at every renewal, also with the period from–to and the Stripe subscription, invoice and charge identifiers); the buyer's name, e-mail address, tax number (for example a Polish NIP), full billing address, buyer type, the country chosen in the panel, the plan, amount, payment date and payment session identifier then also pass through Brevo, and where the countries of the panel, the address and the tax number differ — also the country of the card issuer or bank. When a payment is put on hold for a manual country check (a possible link to a sanctioned country, person or entity, or too little country data), the operator notification gives — whether the buyer is a private individual or a business — their name, e-mail address and billing address, the country chosen in the panel, the billing-address country and the country of the card issuer or bank (for BLIK — the name of the method), the game name, plan, amount, payment date and payment session identifier; where the held payment is a second payment for a game already paid for — also the identifier, status and paid-until date of the first payment, and where the buyer's country is established and only the US state is missing — whether the Stripe invoice will need correcting once the payment is restored, with the buyer's country established from the payment details. For a hold on sanctions grounds the notification also gives the buyer type, the check signals — the type of tax number with the country of that number (without the number itself) and the region in the billing address with the name of the field in which it was recognised — the buyer's country established from the payment details with the name of the rule, whether the Stripe invoice will need correcting once the assessment ends, and for a second payment for the same game — the identifier, status and paid-until date of the first payment. For a second payment for the same game when automatic refunds are switched off or the first payment for that game is on hold, the notification gives the buyer's name and e-mail address, the game name, the plan, amount and date of that payment, the payment session identifier, and the status, identifier, plan and paid-until date of the first payment. A shorter operator notification — without the buyer's name or address, with their e-mail address, the payment session identifier, the game name, the amount and the payment date — is sent when we refund a second payment automatically (then also with the plan, the buyer type and the identifier and paid-until date of the first payment), when an invoice issued by Stripe needs correcting because the tax charged on it does not match the VAT system of the buyer's country established from the payment details (then also with the amount of that tax), and when the address or card points to a territory of an EU country that is outside the EU VAT area (for example the Canary Islands) — in the last two cases also with the country chosen in the panel, the billing-address country and the country of the card issuer or bank (for BLIK — the name of the method) and, for a territory, its code. In the message with a corrective invoice — a Stripe credit note after a refund of a second payment or after a manual correction of the invoice, which we send to the buyer instead of Stripe — Brevo receives the buyer's e-mail address and the credit note as a PDF attachment: first name and surname or company name, billing address, invoice and credit note numbers and amounts, that is, the same data the buyer already has on the Stripe invoice. Notifications about a card dispute or a failed refund contain only the identifiers of the payment, the game and the dispute or refund, and the amount. When a subscription ends for a reason that needs our assessment (a sanctions or country check, a currency or amount mismatch, account deletion or a card dispute), the operator notification gives the reason for the ending, the Stripe subscription identifier, the game name and identifier, the buyer type, the billing period (monthly or yearly), the time of the ending and the refund amount for the unused days with their number — without the buyer's name or e-mail address. When a buyer withdraws with the function in the panel, the operator notification gives the account identifier and e-mail address, the name and the address for the confirmation, the text of the statement with the date and time of submission, the contract chosen (identifier, type, plan, game name and identifier, date of conclusion, amount and buyer type), the Stripe payment, invoice and subscription identifiers and a preliminary calculation of the refund amount. Operator notes about the start of a subscription ordered by a business contain only the payment session identifier and the reason code or an error description from which we remove e-mail addresses. Operator messages reach a Google-hosted mailbox through Cloudflare Email Routing. Brevo replaces the links in these messages with redirect addresses on its own server and records opens and clicks without linking them to the recipient (anonymous tracking); the service does not let us turn this off. We do not use these statistics.
• The European Commission runs the VIES system, in which we check the validity of the EU VAT number of a buyer that is a business from another EU country. The buyer's EU VAT number goes into the system (a qualified query also carries our own EU VAT number as the requester); we record the result, the time of the check and the consultation number as tax documentation — details in the row “Payments and invoices” in “Data we process”.
• We issue VAT invoices to business buyers ourselves (for a one-off payment; for a subscription, for the first payment and every renewal) in mOrganizer, the invoicing tool available in mBank S.A.'s business banking; the service is provided by CashDirector S.A. (Warsaw), which processes the invoice data on our behalf. We submit the invoices to the National e-Invoice System (KSeF), which the Polish VAT Act places with the Head of the National Revenue Administration (the finance ministry); tax authorities have access to them there. An invoice contains the buyer's name (for a sole trader, their full name), tax number and address, a description of the service, the period, the amounts and the date. We also pass invoice data and payment summaries to the accounting service that keeps our books.
• The map in the Markerra Studio panel, where an organizer places route points, uses OpenStreetMap tiles (OpenStreetMap Foundation, United Kingdom). Fetching a tile discloses the organizer browser IP address and the viewed map area to that provider. No account or game data is sent there.
• The address search in the Markerra Studio map window uses the Nominatim service run by the OpenStreetMap Foundation (United Kingdom). A query is sent only after pressing "Search" or the Enter key. Our server sends it, not the browser: the foundation receives the typed text and the result language, without the organizer browser IP address, account identifier or game data. The purpose is to show the requested place on the map — a chosen result only moves the view, and the organizer places the point themselves. We do not store query text in logs; places found (name and coordinates) are kept in the server cache for up to 7 days, without any link to an account. Do not type anything other than an address or place name into the search. The foundation's practices are described in its privacy policy.
• The walking route in the Android app uses routing data files from the brouter.de service of the BRouter project (Germany). When the phone does not yet have routing data for the area, after you tap “Walking route to destination” — and, while the walking route is on, whenever it is calculated again, for example after “Refresh walking route”, after a change of destination (including one that happens by itself when you collect a point) or after a change of the app language — the app first checks the size of the files needed with that service, then shows a window with the download size and information about brouter.de, and downloads the files only after you confirm in that window. Already when the size is checked, and then when the files are downloaded, the service receives the phone's IP address, the app and routing engine identifier in the request header (User-Agent) and the names of the files for map regions 5 degrees on each side (each several hundred kilometres across) covering your position, the destination and the area between them — not your precise position, account identifier or game data. The purpose is to calculate the walking route you ask for; the legal basis is Article 6(1)(b) GDPR. The downloaded files stay on the phone, excluded from backups, and the app calculates the route on the phone; you can remove them on the map, in the “Offline routing data” section, with “Remove downloaded routing data”. When the files for the area are already on the phone, the app does not connect to brouter.de. The iOS app calculates walking routes with Apple's map service (MapKit) and does not use brouter.de: after you tap “Walking route to destination” — and, while the route is on, after it is refreshed or the destination changes — Apple receives your current position and the coordinates of the destination; we do not pass it your account identifier or game data. The brouter.de service's rules are described in its privacy policy.
• The organizer of a game created in Markerra Studio does not receive any personal data of players through the platform, except for the leaderboard list described in the next item — any statistics are aggregated only.
• The leaderboard list in a Studio game (the nickname, place and time of a player who chose to appear on it) is visible to the players of that game who finished it, and to the organizer in the Markerra Studio panel — until the end of the game's current publication period, and each entry only for 120 days from the player's start. We delete the entry's row at our next monthly data housekeeping, that is up to about a month after those 120 days (section “Data retention”); until then the list and the organizer's panel no longer show it, and the app tells the player that we do not have their time for this game. In a subscription the publication period lasts until the subscription ends, so the list then shows the results of players who started the game within the last 120 days. The list is not part of aggregate reports or of the organizer's data export. Using the list outside the panel is the organizer's own business (section “Controller and deployment-specific roles”).

Providers may process data outside the EEA. Appwrite uses its DPA, subprocessor list, and Standard Contractual Clauses; Cloudflare and Google identify the EU–US Data Privacy Framework or SCCs depending on the recipient and transfer; Stripe Payments Europe Limited (Ireland) transfers billing data to Stripe, LLC in the United States under the EU–US Data Privacy Framework, in which Stripe, LLC is certified, with Standard Contractual Clauses as a fallback (Stripe's Data Transfers Addendum, part of its data processing agreement); Stripe processes card and payment-method data, and data it uses for its own purposes (such as fraud prevention and regulatory obligations), as a separate controller — see its privacy policy; for EEA users Apple generally acts through Apple Distribution International in Ireland and uses SCCs where needed; OpenStreetMap tiles are fetched from the United Kingdom, which is covered by a European Commission adequacy decision. Address search queries from the Markerra Studio panel (Nominatim) go to the same country. Information about the applicable mechanism and a copy of relevant safeguards can be requested from the controller's contact address.

Where we process data and how we protect it against access by foreign authorities

This section carries out the information duty in Article 28 of Regulation (EU) 2023/2854 (the Data Act), which applies to Markerra Studio as a data processing service provided to organizers. The provision reads: "Providers of data processing services shall make available on their websites, and keep up to date, the following information: (a) the jurisdiction to which the ICT infrastructure used for data processing for each of their respective services is subject; (b) a general description of the technical, organisational and contractual measures adopted by the provider of data processing services in order to prevent international governmental access to or transfer of non‑personal data held in the Union where such access or transfer would create a conflict with Union law or the national law of the relevant Member State" (Article 28(1)). §15 of the Markerra Studio Terms links to this page, as required by Article 28(2) of that Regulation.

ICT infrastructure jurisdiction, provider by provider:

• Appwrite Cloud (backend, accounts, database, functions) — the project runs in the Frankfurt, Germany region, in the European Union; primary data (database, accounts, functions) stays within that region. According to the provider, database backups are stored in the European Union, in a location separate from its main data centre in Frankfurt, for about 7 days; the provider does not name the country.
• Cloudflare (Pages and Workers functions — website and panel hosting, Turnstile) — our contracting party is Cloudflare, Inc., United States; processing may involve infrastructure outside the European Union.
• Stripe (payments for publishing games in Markerra Studio) — our counterparty is Stripe Payments Europe Limited, Ireland, in the European Union; billing data may also reach Stripe, LLC, United States (EU–US Data Privacy Framework, with Standard Contractual Clauses as a fallback), to the extent needed to process payments.
• Brevo (Markerra Studio transactional e-mail) — Sendinblue SAS, France, in the European Union; no transfer outside the European Economic Area.
• Administrator's backup copy — an encrypted copy of the database and user accounts (with password hashes, without sign-in tokens and without secret values), made daily and kept for 14 days from its creation (the latest valid copy — until a new one exists) on the administrator's computer in Poland, in the European Union; it does not go to the cloud.

Measures against unauthorized access to or transfer of non-personal data:

• encryption in transit and at rest at each of the providers listed above;
• choosing a processing region in the European Union wherever the provider allows it — Appwrite in Frankfurt, Brevo in France, Stripe with our Irish counterparty;
• data processing agreements and, for transfers outside the European Economic Area, Standard Contractual Clauses or certification under the EU–US Data Privacy Framework, depending on the provider and recipient; we provide details of a given provider's mechanism on request;
• data minimization — beyond the organizer's game configuration (names, descriptions, route points, content and finale settings) and aggregated results, Markerra Studio holds no commercially sensitive non-personal data;
• a commitment that, faced with a request for access to non-personal data or its transfer by the government administration of a third country, we will assess its legal basis and — where Union law or the national law of a Member State requires it — refuse or challenge that request through the legal remedies available, and inform the client whose data is concerned, where applicable law allows it.

A purchase from outside the Union creates no transfer of data out of the Union. We also sell Publications to buyers outside the Union — on the terms of §3 of the Markerra Studio Terms. The direction here is the opposite of what intuition suggests: it is the buyer's data that reaches a controller in the Union, not the other way round — the infrastructure and the data stay where they were, so the purchase itself gives rise to no new transfer within the meaning of Chapter V of the GDPR. Nor is sending a confirmation or an invoice to your e-mail address a transfer, because you are its recipient. The rights under Articles 15–22 of the GDPR belong to a buyer outside the Union exactly as they do to a buyer in Poland: we apply the GDPR because our establishment is in the Union (Article 3(1)), not because of where the buyer lives. The law of your country may give you additional rights, including the right to complain to your own data protection authority — you enjoy them alongside your GDPR rights. The recipients listed above and the transfer mechanisms that apply to them do not change on this account in any respect.

We keep this information up to date, as Article 28(1) of Regulation (EU) 2023/2854 requires. Questions about a specific provider's transfer mechanism go to kontakt@markerra.app. This is not formal legal advice.

Data we process

Automatically collected Google service data on Android

The Android app uses the Google Maps SDK for Android and the ML Kit barcode-recognition library (recognition on the device; the scanner itself — camera preview and frame — is ours). These components may automatically transmit technical data to Google for diagnostics, usage analytics, and maintaining and improving the services:

• Google Maps SDK: device and request metadata (for example OS version, model, brand and form factor, SDK version, and number of results), an Internal Usage Attribution Identifier, IP address, stack traces and crash metrics, and a Maps SDK-specific pseudonymous identifier. Depending on how the map is used, the SDK may also collect interactions such as panning and zooming.
• ML Kit (barcode recognition): device and app information, a device identifier or per-installation identifiers, performance metrics such as latency, API configuration, input and output size, feature version and usage, event types, and error codes. The app does not use Google Code Scanner or auto-zoom, so no scanning-session identifier and no predicted code-area coordinates are generated (until 6 September 2026 this paragraph wrongly listed them).

Transmission of this data to Google services is encrypted; the ML Kit documentation specifies HTTPS encryption and states that ML Kit does not transfer the listed data to third parties. Code images and scan results are processed on the device and never leave it. Markerra does not use data automatically collected by these SDKs for advertising, advertising profiling, or its own tracking of users across apps.

The detailed and current scope is described in Google's official documentation: Maps SDK for Android data disclosure, and ML Kit data disclosure.

Legal bases

Player age

One age floor: 18. From 28 August 2026, only people aged 18 or over take part in Markerra Studio games and in the public technical demo, on their own account. There is no game variant that admits younger players and no path opened by a parent's or legal guardian's agreement. The same floor is set out in the Participation rules for Markerra Studio games.

What this changes in the legal bases. The account, progress, area check, rules-acceptance evidence, and issuing the finale rely on Article 6(1)(b), (c), and (f) GDPR, not on consent — that has not changed. What changed is that Article 8 GDPR no longer applies to our service: the provision covers information society services offered directly to a child, and a service with an age floor of 18, with no variant for minors and with an “Ages 18 and over” store declaration, is not offered that way. The reasoning about limited capacity to perform legal acts (Articles 15, 17, and 18 § 1 of the Polish Civil Code) also falls away: a person who has turned 18 has full capacity (Article 11 in conjunction with Article 10 § 1 of that Code).

Optional app-usage analytics. Every player may give this consent and may withdraw it at any time in the app settings. The block that applied to the 13–15 path until 28 August 2026 no longer has anyone to apply to, but it has not been removed from the apps: it stays in the code of both apps as a safeguard in case a guardian-consent path ever returns. Refusing costs the player nothing — signing in, scanning points, progress, and the finale work exactly the same.

What the player declares in the app. The app asks for the player's date of birth once — at sign-in. The date is checked only on the player's device and is not stored — neither on the phone nor on our server. Only the result of that check goes into the acceptance evidence: the configured minimum age, the confirmation that the condition is met, the value of the ageBracket field (“own statement”), the source of the confirmation (the ageSource field), and the evidence-format version. For the rules of a further game, a signed-in player does not enter the date again if their account already has an earlier acceptance with a confirmed age of at least 18. The server checks that acceptance itself, and the new evidence records that an earlier acceptance confirmed the age. When this cannot be checked, for example without internet, the app asks for the date of birth again and does not store it. The app versions offered in the stores before version 2.1.0 do not ask for the date of birth: the latest of them — 2.0.11 on Android and 2.0.13 on iOS — instead ask the player to tick a box stating that they are at least 18, and older ones ask the same or do not ask about age at all. The server does not accept rules acceptances from any of these versions — to play, the app has to be updated. Acceptance evidence recorded from the versions with the tick box before the server stopped accepting them contains the configured minimum age and the confirmation that the condition is met. Evidence collected before 28 August 2026 may carry the value “guardian's consent” and remains readable — we neither delete nor rewrite it, because evidence must show what the player actually declared.

What this mechanism does not do. The age statement improves our accountability — it lets us reconstruct what we asked a specific person and what they answered. It is not verification: the question about age and the answer come from the same person, the player. We do not check age against a document and do not estimate it from a face or a voice, because each of those measures would mean collecting further data against the minimisation principle and would be disproportionate in a free service that does not profile, does not advertise, and serves no adult content. We therefore do not promise verification that we do not perform. The honest consequence: a minor who obtains a join code and makes a false declaration will get into the game. If we learn that this has happened, we delete the account and the data attached to it; you can report it to kontakt@markerra.app.

The role of a parent or legal guardian. With an age floor of 18 the guardian has no role to play in this service: their agreement opens nothing, because the player must be an adult. The organizer of a Studio game is responsible for not aiming the game at minors and not passing them the join code (§9 of the Markerra Studio Terms). If a guardian believes their child's data nevertheless reached the app, they may write to kontakt@markerra.app requesting access, rectification, restriction of processing, objection, or erasure of the account — we handle such requests exactly like a request from the player themselves.

How a player withdraws consent and requests erasure. Consent to the optional app-usage analytics can be switched off at any time in the app settings; this stops further measurement. The player's account can be deleted from within the app, or a request can be made without the app following the instructions on the Delete account page. Withdrawing consent does not affect the lawfulness of processing carried out before the withdrawal.

How we confirm the identity of the person making a request. A request sent from the e-mail address attached to the player's account is handled exactly like a request from the player. For a request from another address we ask for the account's e-mail address or identifier and the name of the game or the join code. Where there are reasonable doubts about identity we may ask for further information necessary to confirm it (Article 12(6) GDPR) or confirm the request by a message sent to the account's e-mail address. We do not ask for a scan of an identity document — that would be collecting more data, not protecting it. If we still cannot establish whose data a request concerns, we say so and may refuse to act on it (Article 12(2) GDPR).

This section states the controller's position based on the provisions cited above and on the principle of proportionality. It is not a formal legal opinion and has not been confirmed by a supervisory authority.

Location

Location is used for marker scanning or the map so the app can check whether the user is within the configured area. The app does not continuously track users in the background or refresh location merely because it launches. In a game with a leaderboard, location at the moment of a scan is also used to check that the player is at the point — including for a QR code and an NFC tag; we still use it only at the moment of a scan or when the map is open. When you tap “Walking route to destination” on the map (and, while the walking route is on, whenever it is calculated again), the app gets your current position to calculate the route to the selected destination. That position does not reach our server; what the brouter.de service (Android) or Apple (iOS) receives is described in “Providers and recipients”.

New progress records do not store the user's raw phone location. For compatibility with the existing data structure, some technical fields may store the configured deployment circle center or an approximate distance bucket, not the precise phone position.

Website cookies and analytics

Google Analytics runs only after the user clicks “Accept” in the analytics banner. We measure basic website events: page views, page scrolling and section visibility, navigation and footer link clicks, contact-button use, language selection, store links, and the technical status of form submission.

We do not send form content, email addresses, client names, reward descriptions, or message text to Google Analytics.

The Markerra Studio panel has its own analytics banner. After you click “Accept”, Google Analytics receives one purchase event from the panel once a publication is paid: a technical order identifier (a hash, not the payment-session identifier), the plan, the amount and the currency — no e-mail address, game name or join code. The choice made in the panel banner is stored in the panel's browser storage (markerraStudioAnalyticsConsent, markerraStudioAnalyticsConsentDate, markerraStudioPurchaseSent:*) and can be changed with the “Analytics” button in the panel header. Consent is voluntary, expires after 12 months, and can be withdrawn earlier through “Analytics settings” in the footer. Withdrawal stops future measurement and removes available _ga cookies from the website domain. Declining consent in the panel banner does the same, also when you change an earlier choice with the “Analytics” button: measurement stops at once, and the _ga and _ga_* cookies are removed, including the cookie shared with the website, which is set on the .markerra.app domain. The website will set it again only if you also give consent on the website — consent in the panel and consent on the website are separate.

Under the same consent we also report an aggregate conversion event to Google Ads indicating that the contact form was submitted. The measurement runs in consent mode without advertising cookies — ad_storage, ad_user_data, and ad_personalization remain denied, so we do not profile users, run remarketing, or build audience lists, and no form content or email address is sent to Google Ads.

Functional and technical reports for clients

The deployment client receives an aggregated functional and technical report, such as the number of users, collected markers, completed flows, reward displays, and final-link opens. The client does not receive emails, user IDs, raw location, raw Appwrite exports, reward codes assigned to people, individual participant paths, advertising segments, or audience exports to advertising platforms. A leaderboard in a Studio game is not a report: the list is not part of aggregate reports or of any export of the organizer's data.

The client must not attempt to reidentify participants. Report breakdowns are shown only when they include at least 5 users. Smaller cells are marked as <5 or described qualitatively.

Data retention

Technical payment-start reservations (server timestamps, a session identifier and, for a subscription, also the Stripe customer identifier; without names or email addresses) are retained for up to 120 days. Together with them, also for up to 120 days, we keep the start log of a subscription ordered by a business: the payment session identifier, Stripe identifiers — of the customer, the card, the saved tax numbers (identifiers, not the numbers themselves), the subscription and the invoice — the outcome of the order with a reason code, the times of the individual steps and markers of the messages sent, also without names, addresses or email addresses; it serves to complete the order, to remove the customer data in Stripe when no contract was concluded and to make sure the same message is not sent twice. The Stripe customer we create before a subscription payment (account and game identifiers, buyer type, language and our billing mailbox address) is deleted in our annual review if the order was not paid, but not earlier than 120 days after it was created. Where no contract for a subscription ordered by a business is concluded, we remove the card, name, address and tax number from the data of such a customer as soon as we establish that the contract was not concluded, subject to the exceptions described in section “Providers and recipients”. Technical payment notices to the operator are retained for up to 30 days after successful delivery; undelivered notices remain pending until handled. They serve only to prevent duplicate payments and fulfil the order; this does not change the retention period for accounting records.

Account deletion

A user can delete the account in the app or send a deletion request without the app. Instructions are available on the Delete account page. Account deletion removes the app account and the app data linked to that account, including progress, scan attempts, rewards, analytics events, and the nickname, result and nickname reports in game leaderboards, except data that we must keep for a limited time for security, complaint handling, or accountability. In particular, we may keep a pseudonymous reward claim to prevent one person from receiving multiple codes in the same deployment by deleting and recreating an account. Deleting an organizer account also ends active Markerra Studio subscriptions — with no further charges (§15 of the Markerra Studio Terms sets out the settlement); subscription and payment records remain for the period stated in “Data retention”. Deleting an organizer account also ends that organizer's Free Publications and deletes the records of those contracts, together with the declarations and confirmations. Data deleted from the database may remain in backups for a short time — the periods are listed in “Data retention”.

User rights

Users may request access, rectification, erasure, restriction of processing, data portability, objection to processing based on legitimate interest, and may lodge a complaint with the President of the Polish Personal Data Protection Office.

App analytics consent can be withdrawn in the app, while website Google Analytics consent can be withdrawn through the footer link. Withdrawal does not affect earlier lawful processing. Data required for the account, progress, and reward is voluntary, but those functions cannot operate without it; analytics consent is not required. For an order in Markerra Studio, giving the country, your name or company name and the billing address is a condition for concluding the contract — without them we cannot accept the order; some of these data are also needed for the invoice and to determine the buyer's country for VAT, as tax law requires. A business or institution gives its tax number if it has one. You give these data when ordering a Paid Publication, that is, after the free period. For a Free Publication, the conditions for concluding the contract are a confirmed account e-mail address, stating whether you publish as a private individual or as a business or institution, stating your country and making the declarations required before publication, including the declaration under §10 of the Studio Terms — without them we do not publish the game free of charge. Data comes from the user, device, login provider, and deployment configuration supplied by the client, and for a Markerra Studio order also from the payment operator Stripe (the country of the card issuer or funding source, payment and subscription status) and from the European Commission's VIES system (the result of checking an EU VAT number).

Geofencing, duplicate checks, and reward unlocking follow predetermined rules. We do not use advertising profiling. A rejected scan or reward can be challenged in a complaint reviewed by a person.

We do not take decisions that produce legal effects concerning you or similarly significantly affect you solely by automated means — with the exceptions described below.

Free Publication. During the free period the Markerra Studio panel and server do not conclude a Free Publication contract if the country you state is subject to sanctions (listed in §3 of the Studio Terms) or is Syria or Cuba, where we do not offer the Markerra Studio service (§3a(6) of the Studio Terms): the publication is refused before the contract is concluded, and the message gives the reason. This refusal is made automatically on the basis of the country you state, because without it the contract cannot be concluded or sanctions law prohibits it (Article 22(2)(a) and (b) GDPR). When you state Ukraine, an automated rule only holds the publication: we do not make the game available to players or send the confirmation until a person has assessed the request (usually within 2 working days); a person decides on clearing or refusing it, and we send the result by e-mail. A possible link with a person or entity subject to sanctions is checked by a person. You may ask for any of these matters to be reviewed by a person, express your point of view and contest the outcome — write to kontakt@markerra.app.

Paid Publication (after the free period). The Markerra Studio panel and server do not accept an order if the country chosen in the panel is listed in §3 of the Studio Terms (a country subject to sanctions or a country from which the payment operator does not handle payments) or if we have paused orders from that country: the order is refused before payment, nothing is charged and the message gives the reason. This refusal is made automatically on the basis of the country you choose, because without it the contract cannot be concluded or sanctions law prohibits it (Article 22(2)(a) and (b) GDPR). After payment, an automated rule can only put the publication and any refund on hold: when the country chosen in the panel, the billing-address country, the card issuer's country (for a Link payment — the country of its funding source; for BLIK we take Poland as the bank's country), the country of the tax number or the region in the billing address points to a country or territory subject to sanctions, to Syria, to Cuba or to Ukraine, or when an earlier payment for the same game is on hold for that reason, and also when these data do not allow the buyer's country to be established (for example a US address without a state) or point to a country to which we have paused sales. When the order data indicate a possible link to a sanctioned person or entity, a person puts the order on hold during the manual check. A person then decides on concluding or refusing the agreement, on publication, a refund or freezing funds (§3 of the Studio Terms). We order the refund of a second payment for a game that is already paid for automatically, and where the automatic order is switched off or fails, a person orders it within the same time limit; the service continues from the first payment, and if the second payment was the first fee of a new subscription, that subscription ends at once. For a Markerra Studio subscription the following contract rules also run automatically (§3, §6a and §15 of the Studio Terms); those that are unfavourable to you rest on Article 22(2)(a) GDPR (performance of the contract) and, for sanctions, also on (b):

• the subscription ends by itself when the fee for the next period has not arrived within 3 days of its start;
• we do not charge the fee for the next period, and the subscription ends, when at a renewal the payment data point to a country or territory subject to sanctions (the country code of Ukraine alone is not decisive), Syria, Cuba or a country to which we have paused sales, or when the fee would be in a currency or amount other than the subscription price;
• if we charged a subscription fee before the payment data pointed to a country with paused sales, we order its refund in full automatically and the subscription ends at once; where a fee was charged in a currency other than the Polish zloty, the subscription ends at once, the publication is held and a person decides on the refund;
• a fee charged after the subscription ended or after account deletion is refunded in full, and when an account or a game with a yearly subscription is deleted we refund the part of the price for the full unused days — we order these refunds automatically, and where the automatic order is switched off or fails, a person orders them within the same time limit; the exception: where the fee for the current period is held for the assessment (§3 of the Studio Terms) or is the subject of a payment complaint with the bank, we do not order the refund for the unused days automatically — a person orders it after the assessment is finished or the complaint is resolved, within the time limit counted from that day (§6a(10) of the Studio Terms).

We order the refunds on the list above and the refund of a second payment automatically; where the automatic order is switched off or fails, a person orders them within the same time limit, and the rules and time limits of the refund do not change. Where, after a subscription fee is charged, the payment data point to Ukraine alone or do not allow the country to be established (for example a US address without a state), the automated process can only hold the publication for that period and set the subscription to end at the end of the period. A possible link with a person or entity subject to sanctions is checked, and the case held, by a person. A person decides how such a case continues — restoring the publication and renewals, or a refund. You may ask for any of these matters to be reviewed by a person, express your point of view and contest the outcome — write to kontakt@markerra.app.

Leaderboard. You can withdraw your consent to showing your nickname, place and time on the list at any time with the “Remove me from the list” button in the app; the entry disappears from the list at once, and withdrawal does not affect the lawfulness of processing before it. The right to data portability covers your entry (nickname, times, consent), which we hand over in a copy of your data on request. Some leaderboard measures work automatically: the nickname filter, the hiding of a nickname after three reports from different players, and the speed check, which is a one-off check of whether the moves between points were possible — its only result is whether your result goes on the list; it is an automated assessment (profiling within the meaning of the GDPR), for which we store no movement patterns. A place on the list does not by itself create rights or obligations towards you, and Markerra awards no prizes for it. However, because the organizer may use the list in their own way, for example to give prizes, as a precaution we treat keeping a result off the list as if it could significantly affect you, and we ensure that on your request a person reviews each of these matters and that you can express your point of view and challenge the outcome — write to kontakt@markerra.app. We tell you in the app, with a reason code, when your nickname or result is hidden. You can appeal against the hiding with a message to kontakt@markerra.app — a person decides on it. Independently of an appeal, you can also take your rights to court and, if you are a consumer, use out-of-court consumer dispute resolution, which the Markerra Studio Terms describe in §14 (the register of bodies is kept by the President of the Polish Office of Competition and Consumer Protection). We have not undertaken to take part in such proceedings, and a refusal closes no court route.

For privacy requests, contact: kontakt@markerra.app. We respond without undue delay and generally no later than one month after receiving the request. For complex requests, this period may be extended by two additional months; we will inform the user within the first month and explain the reason for the extension.

Change history

Previous version: 2026-10-22; on markerra.app version 2026-10-22 applied until 24 October 2026. The 24 October 2026 change adds the Markerra Studio free period (§3a of the Markerra Studio Terms, version 2.7): during this period we publish games free of charge (Free Publication) and do not accept orders or payments for publication. Sentences at the beginning of the document now say that the free period runs from the day the panel is made available and that the descriptions of orders, payments, invoices, Stripe and the sanctions check on orders concern the Paid Publication and apply only after the free period; in the same way we marked the descriptions of Stripe and Brevo in the section “Providers and recipients”, the rows “Payments and invoices” and “Sanctions check for a Markerra Studio order” in the data table, the rows “Payments, invoices and tax records” and “Sanctions check for a Markerra Studio order” in the legal bases table, and the sentence on the data required for an order and the paragraph on automated decisions for orders in the section “User rights”. The section “In short” has a new sentence on the Free Publication and the sanctions check based on the country stated. The row “Markerra Studio organizer account” in the data table lists the Free Publication data — the publisher type, the country stated, the acceptance of the Terms, the declaration under §10 of the Terms and the other declarations before publication, the e-mail confirmation, the contract status, the hold for Ukraine and withdrawal — and their purpose, and the row “Studio game configuration” the limits of the Free Publication and the organizer data visible to players (§5 of the Markerra Studio Terms: whether the organizer is a private individual or a business or institution, the name and the e-mail address for questions and complaints and, for a business or institution, also the full legal name, tax ID or equivalent and address) and the purpose for which players see them. Rows “Sanctions check for a Free Publication” were added to the data and legal bases tables: the check based on the declared country, the automated refusal for a country subject to sanctions and for Syria and Cuba, where we do not offer the service, and the hold for Ukraine until a person's assessment before publication. The row “Organizer account and game publication” in the legal bases table gives the bases for the Free Publication. The description of Brevo lists the confirmation of the Free Publication contract with the Terms attached, the acknowledgement of a withdrawal from such a contract and the operator notification about a request from Ukraine; the sentence about redirected links and recorded opens and clicks now says that Brevo does not link them to the recipient (anonymous tracking) and that the service does not let us turn this off. The section “Data retention” now says that we keep the record of a Free Publication contract and the result of the sanctions check for it until the organizer account is deleted and delete them together with the account, the section “Account deletion” that deleting an organizer account ends that organizer's Free Publications and deletes the records of those contracts, and the section “User rights” the data required to conclude a Free Publication contract and a separate paragraph on the automated refusal for the Free Publication (Article 22(2)(a) and (b) GDPR) and a person's assessment for Ukraine. Apart from these changes, the version date and this change history, no sentence changed its wording.

Versions 2026-08-22 to 2026-09-23 were prepared in the test environment; on markerra.app version 2026-07-29 applied until 22 October 2026, except for an accidental publication on 3 September 2026, reverted the same day. Previous version: 2026-09-23. The 22 October 2026 change adds, next to the controller's full name in the section “Controller and deployment-specific roles”, that the rest of the document refers to the controller as PWD or “we”. Previously PWD appeared without explanation. It is the same controller as before. The same change aligns the name of the rules in the paragraph “What the player declares in the app”: the English version now says “participation rules” instead of “participant rules”, and the Polish version “zasad uczestnictwa” instead of “zasad uczestnika” — the name used by the rules themselves and by the Studio Terms. A third change concerns the paragraph “A purchase from outside the Union creates no transfer of data out of the Union”: it no longer lists countries outside the Union and refers to §3 of the Markerra Studio Terms instead (details — the seventh change). A fourth change adds to the row “Markerra Studio organizer account” the data of a phone connection for writing NFC tags in the Markerra app (game identifier, connection times, platform and app version, tag write status) and the purpose of that connection, and adds two rows to the retention table: the phone connection and the tag write status, each saying when and how we delete the data. A fifth change concerns age: the app asks for the date of birth once, at sign-in, and for the rules of a further game it relies on an earlier acceptance on the same account. That is why the paragraph “What the player declares in the app” and the row “Evidence of organizer-rules acceptance” now describe the source of the age confirmation. We still do not store the date of birth. A sixth change concerns payments in Markerra Studio: the data we receive from Stripe now include the card issuer's country or, for a Link payment, the funding-source country (a two-letter country code); for BLIK and Przelewy24, for which Stripe gives no country, we take Poland as the bank's country and record the name of the method. Together with the country chosen in the panel and the billing-address country it is used to determine the buyer's country. That is why the descriptions of Stripe and Brevo in “Providers and recipients”, the row “Payments and invoices” in the data table and the row “Payments, invoices and tax records” in the legal-bases table changed. A seventh change concerns selling Markerra Studio to private persons and businesses worldwide, except for countries, territories, persons and entities subject to sanctions, and Syria and Cuba (§3 of the Markerra Studio Terms, version 2.3). The paragraph “A purchase from outside the Union creates no transfer of data out of the Union” refers to §3 of the Studio Terms instead of naming Norway, Iceland and the United States, and adds that sending a confirmation or an invoice to the buyer's address is not a transfer and that the law of the buyer's country may give them additional rights. The row “Payments and invoices” says that the countries from the payment details are also used for the sanctions check, and the data, legal-bases and retention tables have new rows on the sanctions check. The description of Brevo gives the full scope of data in the operator notifications — including the method name for BLIK and Przelewy24, a second payment while the first one is on hold, the review of territories outside the EU VAT area and an invoice with countries to check — and no longer mentions a notification about a confirmation without the attachment, which we do not send. In the section “User rights”, the sentence saying that we do not use solely automated decisions producing legal effects stands in a separate paragraph: the only automated decision is refusing an order before payment from a country listed in §3 of the Studio Terms or from a country with paused sales, after payment an automated rule can only put an order on hold where there may be a link to sanctions, a person decides on a refusal, and the only automatic refund is that of a second payment for a game already paid for. An eighth change concerns backups: the Appwrite item in “Where we process data…” says that primary data stays in Frankfurt and that the provider keeps database backups in the European Union for about 7 days, without naming the country; an item on the administrator's local, encrypted backup copy, a “Backups” row in the retention table and a sentence on backups in “Account deletion” were added. A ninth change concerns the leaderboard in Studio games — an optional list of the nicknames, places and times of players who chose to appear on it, visible to the players who finished the game and to the organizer (participation rules studio-2026-10-10-v11, Markerra Studio Terms version 2.4). We count the player's time from the player's confirmation of the start when joining the game or from the first point completed — as the organizer sets — to the last required point, and we store the moment of the start confirmation in the player's entry. The sections “In short”, “Controller and deployment-specific roles” (joint control for the leaderboard, the personal or household activity exception, use of the list outside the panel by the organizer as a separate controller), “Providers and recipients”, “Location”, “Functional and technical reports for clients”, “Data retention”, “Account deletion” and “User rights” (withdrawal of consent, automated measures, the speed check, review by a person) changed, and rows were added to the data, legal-bases and retention tables. The sentence saying that the organizer receives no personal data of players has an exception for the leaderboard from this version. The same change makes two additions unrelated to the leaderboard: the result of checking a buyer-business's EU VAT number in the European Commission's VIES system (number, result, time of the check, consultation number) as tax documentation — the rows “Payments and invoices” and “Payments, invoices and tax records”, a new recipient and a sentence in the retention periods — and the description of Brevo extended with the message carrying a corrective invoice, whose attachment is the credit note PDF. A tenth change concerns subscriptions in Markerra Studio and the means of payment (Markerra Studio Terms version 2.6): subscription data passed on by Stripe, including creating the customer in Stripe before a subscription payment, subscription messages sent through Brevo, the limit of new players in each month of a subscription, the publication period of a game in a subscription, the legal bases and retention of subscription records, ending subscriptions on account deletion, drafts of games covered by a subscription and the automated subscription rules in the section “User rights” (ending, not charging the fee, the hold where the country cannot be established and refunds ordered automatically — or, where the automatic order is switched off or fails, by a person within the same time limit), together with the sanctions check at a renewal in the rows “Payments and invoices” and “Sanctions check for a Markerra Studio order” of the data table. The same change makes additions that do not concern subscriptions alone: in “In short” and in the page description — payments and the sanctions check in Markerra Studio; in “Providers and recipients” — the data passed on to Stripe with an order, the transfer of data to Stripe, LLC in the United States (EU–US Data Privacy Framework, with Standard Contractual Clauses as a fallback) and Stripe's role as a separate controller, business invoices in the mOrganizer tool and in the National e-Invoice System, the accounting service, messages about a payment on hold for a country check, the operator notification about a subscription ending and how long leaderboard entries are visible; in the data table — signing in to Markerra Studio with an email address and password, the fuller scope of the subscription record, the purpose “establishing, pursuing or defending legal claims” for a subscription and how long leaderboard entries are visible; in the legal-bases table — Article 6(1)(f) GDPR for subscription records kept longer than tax law requires; in “Data retention” — the Stripe customer in the payment reservation, the deletion of Stripe customers from unpaid orders, and when we treat an organizer account in Studio as inactive, with a notice of at least 30 days (§5 of the Studio Terms); in “User rights” — the requirement to give data for a Markerra Studio order, the sources of data (Stripe, VIES) and the hold on a one-off payment where the country cannot be established or the data point to a country with paused sales. Przelewy24 is no longer a means of payment, so the sentences about it were removed; the mentions in the descriptions of the sixth and seventh changes stay as history. The same change makes three descriptions match how the service works: the message about a held fee for the next period (section “Providers and recipients”, the Brevo description) also covers the sanctions check and a payment in a currency other than the zloty, not only the country check; a leaderboard entry is shown for exactly 120 days from the player's start, not “roughly”, and disappears from the list, from the organizer's panel and from the player's view before the monthly housekeeping deletes its row — also where the player's first point comes from a previous publication period of the game, because the 120 days then run from that earlier point, so the entry may be invisible soon after the player finishes the game or straight away (section “Providers and recipients”, the data table and section “Data retention”); in “Cookies and website analytics” the sentence about the Markerra Studio panel now says plainly that declining or withdrawing consent in the panel also removes the _ga cookies, including the cookie shared with the website. The same change also adds when and to which app versions the description applies: at the start of the document — a sentence that processing related to the Markerra Studio panel (including the organizer account, games and drafts, orders, one-off and subscription payments, sanctions checks, the leaderboard in Studio games and connecting an organizer's phone to write NFC tags) takes place from the day the panel is made available, and in the paragraph “What the player declares in the app” — that the app versions offered in the stores before version 2.1.0 do not ask for the date of birth (the latest, 2.0.11 on Android and 2.0.13 on iOS, ask the player to tick a box stating that they are at least 18, and older ones ask the same or do not ask about age at all), that the server does not accept rules acceptances from them (the app has to be updated), and what evidence recorded earlier from the versions with the tick box contains. An eleventh change concerns the withdrawal function in the Markerra Studio panel and a subscription ordered by a business (§6a(1) and (2) and §7(1) of the Markerra Studio Terms): in “Providers and recipients” — saving a business's card before the first subscription fee and removing the card, name, address and tax number from the customer data in Stripe where no contract was concluded, the acknowledgement of receipt of a withdrawal statement and the messages about a subscription ordered by a business sent through Brevo, and the operator notifications about a withdrawal and about the start of such a subscription; in the data, legal-bases and retention tables — the data of a withdrawal statement made with the function in the panel (Article 6(1)(c) GDPR, kept with the payment record); in “Data retention” — the start log of a subscription ordered by a business (up to 120 days) and when we remove the data of such a customer in Stripe. A twelfth change concerns the walking route in the Android app: “Providers and recipients” gains an item about the brouter.de service of the BRouter project (Germany), with which the app, after “Walking route to destination” is tapped, checks the size of routing data files — before the window informing about the download — and from which it downloads them after confirmation in that window; the service receives the phone's IP address, the app identifier in the request header and the names of files for map regions 5 degrees on each side, not the precise position, account or game data; while the route is on, the check is repeated whenever the route is calculated again. The same item says that the iOS app calculates walking routes with Apple's map service, which then receives the current position and the coordinates of the destination; “Location” gains a sentence about getting the position for the walking route, and the “Legal bases” table a row “Walking route in the app” (Article 6(1)(b) GDPR). Apart from these twelve changes, the version date and this change history, no sentence changed its wording, and none changed its meaning. Version 2026-09-23 replaced version 2026-09-06. The 23 September 2026 change added the address search in the Markerra Studio map window (the OpenStreetMap Foundation's Nominatim service) to the list of providers and recipients and to the paragraph on transfers to the United Kingdom; no existing sentence changed its wording. Version 2026-09-06 replaced version 2026-09-04. The 6 September 2026 change corrected four descriptions so that they match the code: the code scanner in the Android app (our own scanner with on-device recognition, no Google Code Scanner and no auto-zoom session), operator notifications for a payment on hold (also for a private individual), the retention period of payment records (one wording throughout the document), purchase measurement in the Markerra Studio panel and — in the retention table — deletion of game drafts not edited for 2 years. The 4 September 2026 change added the section "Where we process data and how we protect it against access by foreign authorities" — the information required by Article 28 of Regulation (EU) 2023/2854 (the Data Act).

Previous wording of this section, kept for the record (version 2026-08-25): “A player who is at least 16 years old takes part on their own. A player aged 13–15 may take part only if their legal guardian has agreed. A person under 13 does not create their own account and can play only together with a guardian who uses their own account. The public technical demo remains restricted to people aged 18 and over.” The section then described three age bands, the block on optional analytics for the 13–15 path, and the legal guardian's role. With a uniform age floor of 18 all of those mechanisms lost their subject matter.

Previous wording of this paragraph, kept for the record (version 2026-08-28): “Before the first scan the app shows the participant-rules acceptance screen with a single statement: that the player is at least as old as the deployment requires.” That description matched the age gate as it stood before 29 August 2026. Since that date the app asks for a date of birth instead of a ticked threshold statement; the sentence “we do not store a date of birth” stays true and matters more in this mechanism than it did before.