Privacy Policy
This policy explains how we handle information across everything we run for game developers:
- This site,
developer.yes2games.com. - The Yes2Games dashboard,
dashboard.yes2games.com, where studios sign up, upload builds, run QA, and read reporting. - The hosted Yes2SDK MCP endpoint,
mcp.yes2games.com, which serves our SDK documentation to AI assistants.
We've kept it plain. If anything is unclear, email us and we'll explain.
Who we are
The data controller is Yes2Games Pte. Ltd. (UEN 202331267M), 160 Robinson Road, Singapore 068906. When this policy says “we”, “us”, or “Yes2Games”, that is who we mean, and it applies to all three surfaces listed above. You can reach us any time at [email protected].
What we collect and why
Each surface collects different things, and none of them collects more than it needs. We don't track you across the web, we don't buy data about you, and we don't use any of this for advertising or profiling.
This site
This site has no forms and no sign in. Its “Get Started” and “Sign up” buttons are plain links to the dashboard, so anything you give us when you sign up is collected by the dashboard, described below.
Signing up
You sign up for the dashboard with your Google account. Google tells us your name, email address, Google account id, and profile picture, and that is what your account is created from. We use your email address to send you account emails: a welcome email, the outcome of an account review, updates on requests you send us, and invitations.
Signing up also means accepting the Developer Agreement, and we keep a record of that acceptance (see the table below).
The Yes2Games dashboard
The dashboard is the signed-in product. If you have an account there, we hold:
| What we hold | Why we hold it |
|---|---|
| Your account: name, email address, Google account id, profile picture, and which studio team you belong to | To sign you in and to decide what you are allowed to see |
| Terms and Conditions acceptance: the version of the Developer Agreement you accepted, the time you accepted it, and the IP address and browser user agent the acceptance came from | To keep a record that you agreed to the terms, and which version. Our admins can see this record when they review your account |
| Account review status: whether your account is a preview account or verified, when and by whom it was verified, any note you send with a review request, and the feedback our admins give you | New accounts start as preview accounts with usage limits until we review them (Section 3 of the Developer Agreement). This is how we run that review and tell you the outcome |
| Porting requests: the game's name, genre and engine, whether we would get the source code, links to where it is live today, the audience numbers you choose to give (daily and monthly active users, total players, average session length), how it makes money, your notes, and an optional analytics screenshot | To decide whether we can port a game that is not on the web yet, and to show you the status of your request. The screenshot is private: only you and our admins can open it |
| Studio requests: the studio name, your notes, a snapshot of the games attached to the request (their names, build counts, QA and review state), and our decision | To review a request to set up a studio, and to move the attached games into the studio if we approve it |
| Team invitations and game transfers: the email address a studio member invited, who invited them, the role offered, and the invitation's status. If the person invited reports “I don't know this person”, we also keep that report and any note they add. When an invitee brings their own games into a studio, we keep the transfer request (which game, which studio, and whether it was accepted) | So an invitation is only an offer the invitee can accept or decline, and so games move into a studio only when the studio agrees. A report goes to our admins only; the person who sent the invitation just sees it as declined |
| Game builds you upload, and the bundles we generate from them | To run QA on a build and package it for the platforms you target |
| QA and Inspector session results: the findings, logs, and event data captured while testing a build | So you can read the report for a build, and so we can help you when something fails |
| Reporting we receive from stores and platforms, including Android Vitals crash and performance data | To show you how your published games are performing and earning |
| Access tokens for the third-party platform accounts you connect | So the dashboard can publish builds and read reporting on your behalf, without you re-authorising every time |
| Your AI assistant conversations: the messages you send the integration assistant and the replies it gives | So a conversation survives a page reload, and so we can diagnose the assistant when it answers badly |
A few of those deserve to be said plainly rather than buried in a table.
If someone invites you to a studio, we hold your email address before you have an account. It is the address the studio member typed in. We use it to send you the invitation, and to match the invitation to your account if you sign up with it.
We store access tokens that belong to your third-party platform accounts. That is what lets the dashboard upload a build or pull reporting for you. It also means a token you grant us sits on our servers until you ask us to remove it. We use each token only against the platform that issued it, and only for the actions the connection is for.
We store your AI assistant conversations, including the text of your messages. Treat the assistant as a place whose contents we can see. Don't paste secrets, credentials, or anything you would not want stored into it.
One more thing belongs here, because it affects your players rather than you. A bundle we build for Yandex can carry Yandex Metrica. If you set a Yandex Metrica counter ID on a game, the bundle we generate for the Yandex platform includes Yandex's Metrica tag, which collects analytics about the people who play that game. That is your analytics account and your relationship with your players; we insert the tag you asked for and nothing more, and no tag is inserted unless you set a counter ID.
Pitches sent before the dashboard sign up
This site used to have a form for sending us a pitch. It has been replaced by dashboard sign up. Pitches already sent through it (your name, email address, studio name, game links, porting questions, notes, and your consent) are kept and handled as before, under the retention rule below.
Reviews we import from game platforms
Where a studio has connected a platform, the dashboard imports the reviews left on that studio's games. A review record holds the review text, the rating, and the reviewer name exactly as the platform publishes it. We keep it so a studio can read and reply to its reviews in one place, and we run it through a classifier that labels sentiment and flags reviews that need attention. That step sends the review text to our model provider. We collect nothing about a reviewer beyond what the platform already publishes, we don't join a review to any other record, and we don't use reviews to build a profile of anyone. If you left a review and want our copy removed, email us and we will delete it.
The hosted MCP endpoint
mcp.yes2games.com serves our SDK documentation, API reference, and platform-compliance rules to AI assistants over the Model Context Protocol. There is no account on it and nothing to sign in to. When your assistant calls a tool there:
- The request travels over HTTPS and carries whatever your assistant sent: normally a tool name and its arguments, such as a platform name, an SDK module name, or a path from your project.
- The endpoint is stateless. It holds no account, keeps no session, and writes nothing to a database. It answers from fixed documentation data and retains nothing about your request.
- Our web server keeps a standard access log line: the connecting IP address, the forwarded-for header, any HTTP auth user, timestamp, request method and path, response status and size, referrer, and user agent. The endpoint sits behind Cloudflare, so the connecting address is normally Cloudflare's and your own address is the one carried in the forwarded-for header. Request bodies are not logged, so the arguments your assistant sends (including anything quoted from your project) do not land in our logs.
- We do not use this traffic to train any model.
Who we share it with
We do not sell your data. We don't rent, trade, or hand it to third parties for their own use. Your dashboard data is seen by the people on your team and by the Yes2Games staff who operate the service, review accounts and requests, and support you. Pitches and porting requests are read by the Yes2Games team who assess new games.
We rely on service providers to run the service: hosting, storage, email delivery, Google for sign in, Cloudflare as the network and CDN layer that every request to these surfaces passes through, and Anthropic as the model provider behind the AI assistant. They act on our instructions and only to the extent needed to run the service. Where you have connected a third-party game platform, we exchange data with that platform to do what you asked (upload a build, read its reporting); what that platform then does is covered by its own policy, not this one.
How long we keep it
- Dashboard data: kept while your account is open, because it is the product: your builds, reports, and history are what you came for. Ask us to delete your account or any part of it and we will.
- Terms and Conditions acceptance records: kept for as long as your account exists, because they are our record that you agreed. Accepting a new version adds a new record rather than replacing the old one. The records are deleted together with your account.
- Account reviews, porting requests, studio requests, and game transfer requests: kept while your account exists, as the history of what you asked and what we decided, and deleted together with your account.
- Team invitations: kept as part of the studio's invitation history while the studio exists. If you were invited and delete your account, invitations linked to your account are deleted with it.
- Pitches sent through the old form on this site: we keep a pitch until we've reviewed and responded to it, then for a reasonable period in case the conversation continues. After that we delete it.
- Platform access tokens: kept while the connection is in place. Email us and we will delete the token for any platform you have linked.
- Web server access logs: the access-log line described above. It is written for every web surface we run, not the MCP endpoint alone, rotated daily and kept for up to 15 days, then deleted. Operational service logs, which contain no request content, are kept for up to 30 days. Cloudflare sits in front of these surfaces and keeps its own logs under its own retention, which we do not control.
Your choices
You can ask us to show you the information we hold about you, correct it, or delete it. Email [email protected] and we'll take care of it. Please write from the email address on your account, or on the pitch you sent, or tell us enough for us to find your record.
The same address covers the rest: ask us to delete our copy of the access token for a platform you have linked, to delete an assistant conversation, or to close your account entirely, and we will do it. If you have games distributed under the Developer Agreement, ending that arrangement follows its Sections 7 and 18.
Changes to this policy
If we change how any of these surfaces handles your information, we'll update this page and revise the effective date at the top.
Contact
Questions, requests, or concerns about your data? [email protected], or write to Yes2Games Pte. Ltd., 160 Robinson Road, Singapore 068906.
The terms that apply when you use these surfaces are set out separately in our Terms of Service and, for studios with a dashboard account, the Developer Agreement.