Privacy Policy

Last updated 21 October 2026

The short version

You can draw and animate a play on Playmaker without an account, without giving us your name, and without your play ever reaching our servers — an unsaved play lives in the address bar of your own browser.

If you make an account we store the plays you save, your email address, and a record of how you use the product. We ask before we set the cookie that tells a returning visitor from a new one, and declining costs you nothing — the product is identical either way. We take payments through Stripe and never see your card number. We send you email you can turn off in one click, apart from the few messages your account cannot work without.

The rest of this page is the detail, and it is written from what the software actually does rather than from a template.

Who we are, and how to reach us

Playmaker is a play designer for sports coaches, at playmaker.click, operated by OK200.

For anything on this page — a question, a correction, a copy of your data, a request to delete something — use the support page or email paul+playmaker@ok200.net. A person reads it.

What you can do without an account

Everything on the canvas. Placing players, drawing runs, animating, switching sport, loading a formation template and exporting a PNG all happen in your browser.

An unsaved play is held in the page's URL fragment (the part after #), compressed. Browsers never send a fragment to a server, so a play you have not deliberately saved or shared is not something we hold.

Two things are still true while you are signed out:

If you accepted the cookie banner, we set the analytics cookie described below and record what you do in the product (which sport, which tool, whether a play got animated) against it. If you declined, we count the same actions without any identifier attached.
If you press Copy share link, that specific play is uploaded, because a link somebody else can open has to be readable by a server. See Share links below.

What we collect

Information you give us

Account: your email address, your name if you supply one, and either a password (stored only as a bcrypt hash — we cannot read it) or the fact that you signed in with Google. If you sign in with Google we receive your Google account's email address, name and profile picture URL. We never receive your Google password.
Two-factor authentication, if you turn it on: a secret and a set of recovery codes, stored encrypted.
The two-question survey we may show once, asking what kind of coach you are and what level you coach. Both answers are optional and both are stored on your account, because they are what tells us which coaches the product is actually for.
Support messages: whatever you write in the form on the support page, plus the email address you give us so we can reply.

Plays you save

A saved play is stored on our servers: its name, its sport, the positions and paths you drew, when you created and last changed it, and a small thumbnail image we render so your playbook has pictures in it. Thumbnails are kept on private storage and are served only to the account that owns them.

Share links

Pressing Copy share link uploads a snapshot of that play and gives you a URL of the form playmaker.click/p/xxxxxxxxxx. We also generate a preview image of the play so the link unfurls in a messaging app, and we count how many times the page has been viewed.

A share link is unlisted, not secret. It is not in our sitemap and not linked from anywhere, but anyone who has the URL can open it without signing in, and anything you put in a play's name is visible to them.

Share links you created while signed in are taken down when you delete your account, and can be deleted with the play. We do not expire them.
Share links you created while signed out are not attached to any account. Instead, the browser you made one on is given a random secret for it, and that secret is the only proof that the link is yours. It is kept in that browser's storage (see Stored in your browser below); we keep only a scrambled fingerprint of it that cannot be turned back into the secret. The links, each with Delete, are listed at Your links on that browser.
Deleting a link takes its page and its preview image down at once — anyone who opens it afterwards is told it has been taken down, and nothing about the play is shown — and it is destroyed for good 30 days later.
The proof lives in one browser only. Clear that browser's data, use a private window, or switch phone, and the list is gone: we have no other way to tell that it was you who made those links. Email support with the code from the URL and we will remove one for you. The same goes for links made before September 2026, when this arrived, and for the codes made when you print a play signed out: those are not listed on Your links, because a printed code is meant to keep working.
A link you have already sent also carries its own copy of the play, inside the part of the URL after #. That part never reaches us, so deleting the link cannot delete that copy: whoever holds the link can still open the play from it in their own browser.

Until September 2026 this section said there was no way to delete a link you had made while signed out. That was true, and it is why this changed.

A share link that nobody ever opens does not last forever. If a link you made while signed out has never once been opened — by you or by anybody else — we take it down 12 months after you created it, and delete it for good 30 days later. A link that has been opened at least once is not expired by age at all, however old it gets, because people are clearly still using it.

A link printed as a QR code never expires. If you put a play card, wristband insert or playbook booklet on paper, the code printed on it is kept indefinitely, whether or not anyone has scanned it. We cannot reach the paper to tell you a code has stopped working, so we do not let it stop working.

Plays embedded on other websites

A shared play can be put on another website — a blog, a club site, a forum post — where it animates in a frame. The share dialog gives the coach who shared it an embed code, a published play's page offers one to anybody, and many sites (WordPress among them) build the frame by themselves when the play's link is pasted into them. The frame is never in search results, and anyone with the link could already open the play, so an embed shows nothing the link did not.

When somebody watches an embedded play on another website:

It counts as a view of that play, by the same rules as opening the link: machines are not counted, and the same person is counted once in a 30-minute window. To tell the same person apart we use their IP address, which every web request carries: a scrambled form of it is kept for those 30 minutes and then forgotten, and it is never stored with the view.
We record the name of the website, and nothing more about it — clubsite.example, never the address of the page the play was on. The embed code asks the visitor's browser to send us only the site's name, and if a browser sends more we throw the rest away before anything is written to our analytics.
Nothing identifies the viewer. The embed does not show our cookie banner, does not set playmaker_aid, and sends no analytics events of its own. Our sign-in cookies are marked SameSite=Lax, which browsers do not store or send inside another website's page.

Copying an embed code is recorded as an ordinary event (embed_code_copied, with the play's code and sport), under the same consent as everything else in How you use the product below. The website that shows the frame has its own privacy policy, and what it records about its visitors is up to it.

Sharing a whole playbook

Pressing Share playbook on a playbook does the same thing, for everything in it at once. It uploads a snapshot of every play in that playbook — the same upload that Copy share link makes, once per play — plus the playbook's name and its description, and gives you a URL of the form playmaker.click/b/xxxxxxxxxx. Ticking "Link back to the animated play" when you print a booklet does the same thing, because the code on the cover has to open something.

Three things worth knowing about it, because they are not obvious:

It is a snapshot, not a window. The page shows the playbook as it was at the moment you pressed the button. Adding, removing or renaming a play afterwards does not change a link you have already sent, and does not change a QR code you have already printed. Sharing again after a change gives you a new link; sharing again with nothing changed gives you back the same one.
Every play in it gets its own share link too, listed on the page, exactly as if you had pressed Copy share link on each of them. If a play was already shared, that link is reused rather than a second one being made.
It is unlisted, not secret, on the same terms as a play's link above: not in our sitemap, not linked from anywhere, and openable by anyone who has the URL.

You can stop a playbook link resolving from the playbook page. Doing so does not delete the individual plays' links, which may be on paper or in somebody's messages. Deleting your account takes down the playbook links you made, as it does the plays'.

We also delete the generated preview image of any link nothing has opened for 90 days. That does not affect the link itself; we just draw the picture again if it is needed later.

Teams, and what coaches can see

If you are on a team, the team's coaches can see which of the team’s plays you have opened, and when: the first time and the most recent time you opened each one. This is so a coach can tell, before a game, whether the squad has looked at the plays, instead of asking in a group chat. It is shown to the team's coaches and owner, and to nobody else — not to other players, and not outside the team.

What counts as opening a play is the play itself being shown to you, signed in: opening it from the team, or stopping on it in sideline mode. Seeing its name in a list does not count.
A coach can send one reminder email to the players who have not opened a play. Each player gets at most one such reminder a day, whichever coach sends it and however many plays it is about. It comes from us, not from the coach's own address, and it has a one-click link that turns these reminders off and nothing else. You can also turn them off under Settings → Profile, and unsubscribing from all our email stops them too. The coach is told how many players were not emailed, never who or why.
When you leave a team, or are removed, you stop appearing in its coaches' counts at once. Deleting your account removes the record of what you opened.

Coaches' own views are recorded the same way, but are not counted as anybody having "seen" a play: the count is of players.

Comments on a team's plays are seen by everyone on that team — its coaches and its players — and by nobody outside it. A comment shows your name and role, and, if you pinned it to a moment, that moment of the play. You can edit or delete your own comments; the team's coaches can remove any comment on the team's plays. A deleted comment is hidden at once (if people had replied to it, the thread shows "Comment removed"). Deleting your account removes your comments. We record when you last read each play's comments, only to show you which ones are new.

How you use the product

We run our own analytics rather than handing your behaviour to an advertising network. None of it starts until you have said yes. It works like this:

The first time you visit we ask, in a banner at the bottom of the page, with an Accept and a Decline that are the same size and take the same one click.
If you accept, we set a cookie called playmaker_aid holding a random identifier (a UUID). It is not linked to you as a person until you make an account.
The cookie lasts two years, and the two years restart each time you visit.
Against that identifier we record events: the name of the thing that happened (play_created, share_link_copied, paywall_viewed and so on), a small set of properties describing it (which sport, which mode, how many plays you have saved), the path of the page it happened on, the page's referrer, and a per-tab session identifier.
Events also record your account ID once you have one, which means the history recorded before you signed up is joined onto your account when you sign up. That is deliberate: it is how we can tell what made someone decide the product was worth an account.

We do not record the contents of your plays as analytics, and we do not put anything free-text into an event.

If you decline

Declining means no identifier, and that is the whole of what it means:

No playmaker_aid cookie, no attribution cookie, no per-tab session identifier, and Google Analytics is never loaded at all. If you had accepted before and change your mind, the cookies you already have are expired on the spot.
We do still count the visit. The events described above are recorded with the identifier fields empty, so they add up to "one page view" and nothing else — two visits by you are indistinguishable from two visits by two different people, and there is no way to work back from them to you or to your browser.

We think that is the honest arrangement: nothing is stored on your device or read from it, nobody is singled out, and we still know how many people used the thing. It is done on the basis of our legitimate interest in knowing whether the product works. If you would rather we did not even count you that way, email support.

Before you answer

If you have not answered the banner yet, nothing is set on your device and nothing is sent to us — unless you press Copy share link while signed out, which keeps that link's deletion secret in your browser (see Stored in your browser). Events are held in your browser's memory while the question is on screen. If you then accept, they are sent; if you decline, they are sent without any identifier; if you close the tab without answering, they go with the page and we never see them.

Where you came from

If you accept, we read the utm_* parameters on the URL, the referring site and the page you landed on, and we keep them in a two-year cookie. Because we are not allowed to record that before you answer, your browser holds the page you arrived on in memory and hands it back if you accept later in the visit — so accepting on the third page still credits the search result or the link that actually brought you.

If you go on to create an account, that first-touch information is copied onto the account and kept for as long as the account exists — it is how we know which of the things we do actually bring coaches in.

Payments

Pro subscriptions are taken through Stripe. Your card details are entered on Stripe's own checkout page and are never sent to, or stored by, us. What we store is what Stripe tells us: a customer identifier, a subscription identifier, the plan and its status, the card's brand and last four digits, and when the current period ends. Invoices and receipts come from Stripe's records, which is also where you manage or cancel the subscription.

Email we send, and whether you opened it

We record which of our emails were sent to you and when, so that nobody gets the same message twice. Links inside our email go through a signed redirect on our own domain before landing where they say they will, which lets us count clicks and attribute a signup to the message that caused it. We do not use tracking pixels to record opens.

We also keep a copy of the product email we send — the welcome message, the onboarding sequence, win-back and product updates — in our own mailbox, so we can see what actually arrived and fix it when it looks wrong. Verification and password-reset emails are never copied: they contain links that act on your account, and nobody but you should hold them.

Diagnostics when something breaks

When the application throws an error we send a report to Flare, an error-tracking service, so it gets fixed. The report is configured to strip credentials, tokens, two-factor secrets, Stripe payment details and email addresses, and to withhold the IP address of the person who hit the error. It still contains the URL, the stack trace and the shape of the request, and that can incidentally include an account ID.

Google Analytics

Alongside our own analytics we send Google Analytics 4 a copy of four events — account created, signed in, checkout started, purchase completed — so that Search Console and Google Ads have something to attribute traffic against. Google sets its own cookies to do this, and its use of that data is governed by Google's privacy policy, not ours. IP anonymisation is Google's default for GA4.

Google Analytics is only loaded if you accept. Not loaded-but-disabled: the script is not fetched from Google at all until you have said yes, so before that there is no request to Google from this site and nothing for it to set a cookie with.

This is the one place a third party gets behavioural data about you. If you use an ad blocker or tracking protection it is very likely already blocked, and nothing in Playmaker breaks when it is.

Cookies we set

Only the first row is set without asking, and it is the row that records your answer.

Cookie	Why	Set when	How long
`playmaker_consent`	Remembers whether you accepted or declined, so we do not ask again on every page. Holds one of two words and nothing else — it cannot be used to recognise you.	When you answer	1 year
`playmaker_aid`	The anonymous analytics identifier described above. Readable by the page's own JavaScript, which is how events are tagged.	Only if you accept	2 years, refreshed on each visit
`playmaker_ft`	The first-touch attribution described above: where you came from.	Only if you accept	2 years
Google Analytics cookies	Set by Google, for the conversion mirror above.	Only if you accept	Google's durations
Session cookie	Keeps you signed in and carries the CSRF protection on forms. Encrypted.	Always	Until the session ends
`playmaker_seen_playbook`	Remembers that you have already been shown the sample play and the first-visit tour, so you are not shown them again.	Always	1 year
`sidebar_state`	Remembers whether you collapsed the sidebar.	Always	1 year
Stripe cookies	Set by Stripe on its own checkout and billing pages, including for fraud prevention.	On Stripe's pages	Stripe's durations

The four "always" entries are there to make the product work — staying signed in, not re-running a tour you have already seen, keeping your sidebar the way you left it. None of them measures anything and none of them follows you anywhere.

Stored in your browser

One thing is kept in your browser's own storage rather than in a cookie, and it is set whether or not you accepted the banner:

Key	Why	Set when	How long
`playmaker_owned_shares`	The share links you made on this browser while signed out, each with the secret that lets you delete it. Sent only to us, and only to list or delete those same links — never with anything else you do.	When you press Copy share link while signed out	Until you clear it or delete the link

It is not behind the banner because the banner is about identifiers — things that tell one visit from another — and this is not one. It is not sent with page views, events or anything else, it cannot tell us who you are or what else you do, and it exists only because you asked for a link and are entitled to take it down again. That makes it strictly necessary for the thing you asked for, which is the test for storing something without asking. Deleting every link on Your links, or clearing this site's data, removes it.

Changing your mind. Clear this site's cookies and you will be asked again on your next visit; declining then expires the analytics cookies you already have. Or email support and we will delete the events recorded against your identifier.

This section used to say something else. Until August 2026 it said, accurately, that we showed no cookie banner and set the analytics cookie on your first visit whether you liked it or not. We said it plainly rather than implying a consent step that did not exist — and then we built the consent step. This paragraph stays here because a privacy policy that quietly rewrites its own history is worth less than one that tells you what changed.

Why we use any of it

To run the product: sign you in, store and show your plays, generate thumbnails and share previews, enforce the free plan's limit.
To take and manage payments, and to stop billing when you cancel.
To send the email described in the next section.
To decide what to build. This is what the analytics is for: which sports get used, where people give up, whether a change made the product better. Those questions are answered from aggregate counts.
To keep the service up and secure: rate limiting, abuse prevention, error diagnostics.
To meet obligations we have, such as keeping records of payments.

We do not sell your personal information. We do not share it with advertisers. We do not use your plays to train machine-learning models.

Email, and how to stop it

There are two kinds.

Transactional — email verification, password resets, payment receipts and security notices. These are part of having an account and cannot be switched off while the account exists.

Everything else — the welcome message, the short onboarding sequence over your first couple of weeks, a win-back message if you disappear, product update announcements, and a team coach's reminder to watch a play you haven't opened yet (see Teams, and what coaches can see above). Every one of these carries an unsubscribe link that works without signing in, and the List-Unsubscribe headers that make your mail client's own one-click unsubscribe button work (RFC 8058). Product updates are opt-in and can be toggled separately in your profile settings. Unsubscribe links do not expire — one in a two-year-old email still works.

Who else handles your data

We use a small number of providers to run the service. Each gets only what it needs:

Stripe — payments and subscription billing.
Amazon Web Services (SES) — sending email.
Google — Sign in with Google, if you use it; Google Analytics 4, as described above.
Flare (Spatie) — error diagnostics.
The OK200 platform — our own company's reporting across the products we run. When you sign up, sign in or make a payment, it receives a SHA-1 hash of your email address, which kind of event it was and, for a payment, the amount and Stripe's invoice number. It does not receive your name, your plays or the email address itself.
Our hosting and database provider — where the application and its data run.

Some of these operate outside Australia, including in the United States and the European Union, so using Playmaker involves your information being transferred and stored overseas.

How long we keep things

Your account and your plays — for as long as the account exists. See deletion below.
Raw analytics events — pruned after 12 months. The daily aggregate counts derived from them are kept indefinitely; those are totals, not rows about you.
First-touch attribution on an account — for the life of the account.
The record of emails we sent you — kept, so that a suppression or a "send-once" guarantee survives.
Payment records — as long as we are required to keep them.
Anonymous share links — kept for as long as people are still opening them. A link nobody has ever opened is taken down 12 months after it was created, and deleted for good 30 days after that. A link that has been opened at least once is kept indefinitely, until you delete it from Your links or somebody asks us to remove one. A link whose QR code has been printed on a play card, wristband insert or booklet is also kept indefinitely, scanned or not. A link you delete yourself is taken down at once and destroyed for good 30 days later, whether or not it was ever opened or printed.
Playbook links, and the play links a playbook link makes — kept until you remove them or delete your account. Sharing a playbook requires an account, so none of these is anonymous and none of them expires by age.
The preview image we generate for a share link — deleted once nothing has opened that link for 90 days. This does not affect the link, which keeps working; we simply draw the picture again if it is ever needed.

Deleting your account

You can delete your account yourself, from Settings → Profile, including if you only ever signed in with Google. When you do:

your plays, the share links you made while signed in, and any playbook links you made stop resolving;
your email address is released, so you could sign up again with it later;
your password, remembered-login and API tokens are revoked;
any Pro subscription is cancelled and you are not billed again.

Be aware of what deletion does not currently do: the underlying account record is retained rather than erased, so that a deletion can be reversed if it was a mistake and so that we keep the payment history we are obliged to keep. Analytics events already recorded are not removed by the deletion, and neither are share links you created while signed out — delete those from Your links on the browser you made them on.

If you want the record itself erased rather than closed, email support and ask — we will do it, and we will tell you what could not be erased and why.

Your choices and your rights

Depending on where you live you may have rights to access, correct, delete or receive a copy of your personal information, to object to some processing, or to complain to a regulator. Australian privacy law and the GDPR both cover most of this.

In practice:

Access and correction — your account details are editable in Settings; your plays are visible in My Plays.
A copy of your data — Settings → Your data → Download everything gives you a ZIP of every play, playbook, practice session and tag in your account, with a page you can open on any computer. The download is kept for 24 hours and then deleted.
Deletion — as above.
Opting out of analytics — decline the cookie banner, or clear this site's cookies to be asked again and decline then. Either way you can also ask support to delete what has already been recorded against your identifier.

If you are in the EU or UK, our lawful bases are: performing our contract with you (running your account, taking payment), our legitimate interests (product analytics, security, error diagnostics), your consent (product update emails, the persona survey), and legal obligation (payment records).

If you think we have got something wrong, tell us first — paul+playmaker@ok200.net. If we cannot sort it out, you can complain to the Office of the Australian Information Commissioner, or to your local data protection authority.

Children

Playmaker is built for coaches and is not directed at children. Do not create an account if you are under 16 unless a parent or guardian agrees to these terms on your behalf. If you believe a child has given us personal information, email support and we will delete it.

Security

Everything is served over HTTPS. Passwords are bcrypt-hashed. Two-factor authentication is available and we recommend it. Play thumbnails are on private storage and served only to their owner. Share codes are long enough, and the routes that read them rate-limited hard enough, that guessing one is impractical. Session cookies are encrypted and are invalidated when a password changes.

No system is perfectly secure. If you find a vulnerability, please email paul+playmaker@ok200.net before disclosing it publicly.

Changes to this policy

If we change how any of this works we will change this page and move the date at the top of it. If a change materially affects you we will say so in the product or by email rather than hoping you re-read the page.