Privacy Policy

Version 2026-09-06 · effective 6 September 2026. Applies to developerpact.com and to the developerpact SDK inside participating apps. The previous version was dated 2 September 2026; what changed is listed at the end.

Developer Pact measures one thing: whether a tester still opens an app each day. This page lists everything the platform holds to do that, in plain words, for testers and for developers.

Who is responsible

Developer Pact is run by an individual developer, reachable at multi.app.software@gmail.com. For the exchange ledger — accounts, apps, testings, installs, days and the e-mails about them — Developer Pact is the controller: it decides what is collected and why, and it uses the data for its own purpose, which is showing every member who is actually there.

Developer Pact is not a service provider of the app you are testing. The app's developer is a separate controller for their own app, with their own privacy policy. The SDK reports to Developer Pact, not to them, and they see only what the ledger shows (below).

What the platform stores

Account: The e-mail address and display name your Google sign-in gives us; the Play Store address you enter when it differs, and when you confirmed it; the time zone your browser reports; which digest e-mails you switched off; the version of the terms you accepted and when; and your reliability counters (tests completed, drops received, links ended early, not reciprocating, owner-choice drops, never listed, days delivered / owed in the last 30). We do not receive your Google password, and we request no access to Gmail, Drive, Calendar or contacts.
Apps you register: Name, Android package name, roster mode and, if you use one, the Google Group URL; the seats you ask for and the rules you set; your Play Console checklist ticks; the opted-in count you type in from Play Console; the app's state and the timestamps of its transitions.
Links and testings: Which two members are linked, and for each app on the link one testing: its state, when you were invited, listed, clicked the install link, paired, were last seen and last active; the two boxes you tick yourself ("joined the group", "opted in"); a "not on the list" report and when it was cleared; the term end; how it ended and why; and flags the platform derives (never installed, sideloaded, reinstalled, suspicious, minimal pattern, version lag, co-located, blocked reported, owner choice).
Install tokens: A random 22-character token per testing, when it was created, expires, was clicked, used and revoked. It is a bearer credential for one seat and carries no data inside it.
Installs: A random install id the SDK generates (UUID), a per-install secret stored only as a SHA-256 hash, how the install was paired (referrer or deep link), the installer package names Android reports, the SDK version, the Android API level, the app's version code, when it was created and last heard from, and whether it has been told to stop.
Days: One record per install per local calendar day: the day, your time-zone offset, the cumulative foreground seconds, the number of sessions, the app version code, the installer, the first and last heartbeat times, the heartbeat count, whether the day counted as active, and any heartbeats the server rejected and why.
E-mails: Every e-mail the platform sends you — address, subject, plain-text body, when it was due and sent, and delivery errors — is kept as a record of what you were told and when.
Wishes: Text you type into a wishlist box, with your account id and the page it came from.
Events: An append-only audit trail: what happened (a join, a listing, a drop, a terms acceptance, an address change), when, and which account did it.

What the SDK sends

The SDK does nothing, and makes no network request, unless the install was paired through a Developer Pact testing link or pairing link. An ordinary user of the app generates no traffic to us at all. A paired install sends two kinds of request, each a fixed set of fields:

Pairing, once

the protocol version, the app's package name, the install token from the link;
the random install id the SDK just generated;
how pairing happened (Install Referrer or deep link);
the installing and initiating installer package names Android reports — this is how "installed from Google Play" is told from a sideload;
the app's version code, the SDK version, the Android API level.

Heartbeat, on opening the app and when the day's threshold is crossed

the protocol version, the package name, the install id;
the local calendar day and your time-zone offset in minutes;
the cumulative foreground seconds for that day and the number of sessions;
the app's version code, the SDK version, the Android API level, the installer package name, and the time the request was sent.

"Foreground" means the app's window is on screen. The SDK counts seconds; it does not know which screen you were on.

What the SDK does not send

No device model, manufacturer, locale, language or screen size.
No advertising ID, App Set ID, Android ID, IMEI or any device identifier — only the random install id the SDK made up.
No location of any precision, and no IP-based location.
No account information from the device — the platform already knows who you are from your sign-in, and the token ties the install to that.
No screens visited, buttons pressed, in-app content, crash data, contacts, photos or files.
Nothing the host app's developer could add: the SDK has no track(), setUser() or any function that accepts data from the app. You can verify this by reading it; the source is public and the exact request bodies are documented at developerpact.com/sdk/api.

Requests are sent over TLS. Like any web server, ours sees the IP address the request came from; it is written to an access log together with the request's path and headers, minus the query string and the install token in the Referer header, and the log is rotated and deleted within seven days of rotation. It is not stored with your account or your days.

This website

Signing in sets the cookies needed to keep you signed in and to protect the sign-in form — nothing else. There are no analytics, no advertising cookies, no trackers and no third-party embeds. The public pages (this one, the terms, the front page, the SDK documentation) set no cookies at all.

What other members see

A pact only works if the other side can see you keeping it, so:

The owner of an app you test sees your display name, the address they must put on their Play list (your Play address, or your sign-in e-mail if you did not set one), your testing's state and timestamps, which days were active and with how many seconds, whether the install came from Google Play, the app version code you last reported, and the flags above. They see this only for their own app and only while the testing and its records exist.
A tester of your app sees your display name, your app's name and package name, its rules, and whether you are testing their app back.
Members choosing whom to invite — the board and the replacement candidates an owner is offered — see display names and the reliability counters listed under "Account", as raw counts with their denominators, never a score.
Google, when an owner applies for production, gets the summary the platform prepares: testers appear as "Tester 1", "Tester 2" and so on, with active-day counts. No names, no addresses.

Nobody sees the roster of an app they are not part of, and nobody sees your e-mail address except the owners whose Play list it has to be on.

Who processes it

Google Cloud Firestore (Google LLC, United States, nam5 multi-region) stores all of the data above. Google LLC is certified under the EU-US Data Privacy Framework, its UK extension and the Swiss-US DPF, which is the legal basis for the transfer if you are in the EU, the UK or Switzerland.
Resend (Resend, Inc., United States) delivers the platform's e-mail and therefore handles your address and the text of each message.
Google also provides sign-in: when you sign in with Google, Google's own privacy policy applies to that step.
Hetzner Online GmbH (Germany) hosts the web server that runs the site and receives SDK requests.

That is the whole list. Nothing is sold, nothing is shared for advertising, nothing goes to data brokers, and nothing is disclosed to anyone else unless the law compels it.

Why we are allowed to hold it

The account, the apps, the testings, the installs and the days are needed to perform the arrangement you asked to join — an exchange cannot run without knowing who is in it and whether they are still there (contract). The flags, the reliability counters, the events and the access log exist to keep the exchange honest and the service secure (legitimate interest). Sign-in with Google and the wishlist box are consent, withdrawn by deleting the account or simply not typing.

How long it is kept

Days are kept for 90 days after the link they belong to ends — long enough for a dispute over a drop or a second "insufficient engagement" round with Google — then deleted.
Installs are kept for 30 days after the link ends, so the SDK on the phone has heard that it should stop, then deleted.
Install tokens are deleted 7 days after they expire.
Testings, links, apps, e-mails, wishes and events are kept while the account exists.
Web server access logs are rotated and deleted within 7 days of rotation.

Deleting your account (from developerpact.com/me) ends every testing you hold, on both sides, as "account deleted" — no penalty to anyone; partners are told and offered replacements. Your account record is anonymised — your name, e-mail address, Play address, time zone and mail preferences are erased — and your installs, days, install tokens and e-mail records are deleted; the one e-mail that tells you the account is gone is stripped of your address and name once it has been sent. An app of yours that is still open has testers of its own, so deletion asks you to close it first (from the app's settings page, which releases its testers without penalty) rather than closing it as a side effect.

What is not erased: the account identifier. It is derived from the address you signed in with (for example ada@example.com becomes ada-example-com), and it remains in the audit trail, which keeps the fact that an account was deleted and aggregate counts, and in the testing records of the owners you tested for, whose own ledgers keep the shape of what happened — a seat was held, then released — because that is their fourteen days, not yours. Those owners see "deleted account" in place of your name and address. A keyed hash of the old address is kept in the deletion record so that we can verify the cascade left no e-mail behind; it cannot be turned back into the address without the server's key.

Play Integrity (planned, not active)

A later version of the SDK is planned to attach a Google Play Integrity verdict to heartbeats, so that "this came from a genuine install on a real device" is something Google attests rather than something the platform infers. If that ships, the platform will store only the verdict strings Google returns (for example MEETS_DEVICE_INTEGRITY) — no device fingerprint, no hardware identifiers, nothing that could identify a device across apps. It is not enabled today, no such data is collected today, and this policy will be updated before it is, with the version changed at the top.

Your rights, and where the buttons are

Export everything held about you as JSON from developerpact.com/me.
Delete your account from the same page; the cascade is described above.
Correct your Play address and preferences on that page yourself; for anything else, write to us.
Object to processing based on legitimate interest, or ask a question, by e-mail to multi.app.software@gmail.com from the address on the account.
If you are in the EU, the UK or Switzerland you also have the right to complain to your data-protection authority.

Children

Developer Pact is for people publishing apps on Google Play and is not directed at anyone under 16. We do not knowingly hold data about them; tell us if we do and it will be deleted.

Changes

When this policy changes, the version and date at the top change with it. If a change means collecting something materially new, members are told by e-mail before it takes effect and asked to accept the new terms the next time they join or register an app.

What changed in this version

Rewritten for the bilateral exchange: cohorts, credit and the evidence ladder are gone; the ledger records only what the SDK measures.
The full list of stored fields, per collection.
Processors named: Google Cloud Firestore under the EU-US Data Privacy Framework, Resend, Hetzner.
Retention spans stated: 90 days for days, 30 for installs, 7 after expiry for tokens; the deletion cascade described.
Play Integrity described as planned and verdict-only rather than as present.
Export and deletion moved to /me.

Not affiliated with Google

Developer Pact is independent and is not endorsed by, sponsored by or affiliated with Google LLC. Google Play, Play Console and Play Integrity are Google's services, named here only to describe what this platform does.

Contact: multi.app.software@gmail.com · Version 2026-09-06