FANDEMiQ · Data protection brief
A plain-English account of what we collect from your fans, what we do with it, where it goes, and what we can and cannot yet do when someone asks for their data back or deleted.
You are the controller. We are the processor. You decide what the activation asks fans for, what the terms say, who sees the results and how long you need them. We provide the platform and act on your written instructions.
That split matters in practice: several answers below end in “that depends on how you configure it”, and those are marked so you can see immediately which decisions are yours.
Your privacy notice needs to cover what your activation actually collects — not the platform’s maximum. An anonymous photo wall and a prize draw that collects email, phone and date of birth are very different processing operations built on the same product.
Everything below is optional except the content itself and a random identifier for the browser.
The photo, video or written message the fan chooses to send. Written messages are screened before they are accepted — against a profanity list you control, and where configured against hate, sexual, violent and self-harm categories. Text that fails is rejected rather than stored. Images are scored for adult content so unsuitable material can be filtered before anything is published.
An email address and/or phone number, only if your activation asks for one. This is how a fan’s finished content reaches them. If you don’t ask, we don’t hold it.
Only if the fan’s browser grants permission. For video we record a time-coded track of position, compass heading and motion; for photos, a single snapshot. This is what makes “where in the stadium was this taken” possible.
When a device gives no satellite fix, the app currently asks a third-party service to estimate an approximate location from the fan’s IP address — and that fallback also runs when the fan has actively refused the location permission. We regard that as wrong and are changing it so a refusal means no location lookup of any kind.
Not a device fingerprint. It’s a random number the app generates the first time a fan opens it and stores in their own browser. It tells us nothing about them, and clearing their browser data destroys it. It exists so the platform can group a fan’s uploads within one session and let them see the analysis of their own content — and nobody else’s.
Browser type and language, stored alongside a consent record as supporting evidence of what was agreed and when.
We do not ask for names, addresses or payment details. Fans never create an account and never set a password with us.
UK GDPR asks you to demonstrate that a fan consented. Until recently the honest answer across most platforms of this kind — ours included — was that consent was checked in the app and then forgotten. That is no longer the case here.
Every consent a fan gives is written to an append-only record: what they agreed to, when, in what language, and from what kind of device. Records are never edited or overwritten. A withdrawal doesn’t erase the original agreement — it sits alongside it, so the history stays truthful in both directions.
Each acceptance also stores a fingerprint of the exact terms text the fan saw on screen at the moment they ticked the box. If you update your wording mid-season, that fingerprint shows which version any given fan actually agreed to. Every piece of content is linked to the consent that was active when it was submitted.
A campaign link can pre-fill a fan’s email address to save them typing. It cannot pre-accept your terms, and it cannot pre-tick the marketing box. Both were previously possible through URL parameters and have been removed — a pre-ticked box is not consent.
A marketing question that was never shown to a fan is recorded as “not asked”, never as “no”. This sounds pedantic and isn’t: without it, a fan who opted in at one event would have that opt-in silently overturned by uploading at a second event that had no marketing question configured.
Anonymous participation and demonstrable consent are mutually exclusive. Where no contact details are collected there is no fan record to attach a consent record to, so none is written. If you need demonstrable consent, your activation has to collect a contact detail.
This is the section most data protection officers turn to first, so we’ll be precise.
The platform finds that a face is present in a picture and estimates an age range and a gender for it. That’s the whole of it. Concretely: we create no facial templates or faceprints, we never match a face against any database, and we never compare two faces to see whether they are the same person.
This is the distinction that carries the legal weight. Special-category biometric data arises where processing is used to uniquely identify someone, and nothing in this platform does that. We state the technical facts rather than the legal conclusion, and we will answer any question your DPO needs to reach their own.
Aggregate audience reporting — how a crowd broke down by age band and gender — and content selection, where a campaign can target the content it uses. The estimates are stored against the piece of content they came from. Where your activation also collects contact details, that content, and therefore the estimates attached to it, is linked to that fan’s record. We create no separate face-based identifier and nothing about a face is used to look a fan up.
The platform estimates the emotional tone of faces in a picture — how positive the crowd looked — which feeds the audience sentiment reporting and the sponsor exposure valuations. This is inference from a photograph, not a physiological measurement, and it is aggregate: it answers “how did this crowd feel”, not “how did this person feel”.
Emotion inference is a processing purpose in its own right. It belongs in your record of processing activities and should be visible in your privacy notice. If you would rather not run it, tell us and we will turn it off for your account.
Our face analysis previously requested every attribute the provider offered — whether someone was smiling, whether their eyes were open, whether they wore glasses or had a beard, which way they were looking. None of it was ever stored or used. We now request only what we actually consume, so that inference no longer happens at all.
One optional feature sends a cut-out of the fan and your campaign backdrop to a generative AI provider to produce a composited image. It is off unless you switch it on per campaign, and it is the only path on which fan imagery leaves our own infrastructure to a generative provider. No name, email or contact detail is ever sent with it. Left off, the equivalent composite is produced entirely within our own environment.
If a fan’s face is obscured, the generated result is unusable, so the platform skips generation rather than spending on output nobody wants. It only does this when the photo contains no usable subject at all — a group shot where one person is covered still produces content for the others.
The application runs in Microsoft Azure’s UK South region and fan media is stored there. The databases holding fan records sit in Azure’s North Europe region in Ireland. Face analysis runs in London.
So fan content is stored and analysed inside the UK and the EEA. Three flows do reach US providers, and all three should be reflected in your privacy notice and your transfer assessment.
| Provider | What it receives | Region | When |
|---|---|---|---|
| Amazon Web Services | Submitted images and video stills, for face detection | London, UK | Core |
| Microsoft Azure AI | Submitted images, for descriptive tags, sponsor logo detection and adult-content screening | EU | Core |
| Resend | A fan's email address and the message delivering their content | United States | Core — unless you supply your own mail server |
| OpenAI | (a) Generative enhancement: the fan's cut-out and your backdrop. (b) Smart Films: written descriptions of clips, which can include snippets of what fans said on camera. (c) Analytics assistant: aggregate account data only | United States | Optional — each off until enabled |
| IP geolocation service | The fan's IP address, to approximate location when the device gives no fix | United States | Core — see the limitation above |
| Plausible | Cookieless usage counts. No fan identifiers | EU | Optional |
| Self-hosted cut-out service | Fan photos, for background removal | UK South | Core — runs inside our own environment, not a third party |
Sub-processors that receive fan-derived data. Anything marked optional is off until you enable it.
Fans’ browsers also load fonts and, on map views, mapping tiles directly from Google. That is a request the browser makes, not data we send, but it does make the fan’s IP address visible to Google in the ordinary way of any web page using a font CDN.
Client accounts are separated logically, not physically: they share a database, and every query is scoped to the accounts a signed-in user belongs to. The only route by which one organisation’s data reaches another is the league-to-club hierarchy described below, which is off unless a fan opts in.
Requests come to you as controller. You pass them to us and we action them. Here is what that actually involves — including where it is manual.
Erasure means erasure, not hiding. For video we destroy the file itself, every still taken from it, and all of the analysis derived from it — the detected faces, the estimated ages, the tags — in a single operation. Deleted files remain recoverable by us for 7 days as protection against accidental loss, and are unrecoverable after that.
Photo and contact-record deletion is done by hand by our team today rather than by tooling, and a video already used in a published film or fan wall needs that output removed or re-rendered first. This is why erasure runs as an assisted process rather than a button in your dashboard, and why consolidating one fan across several events takes us rather than you. If you expect a high volume of erasure requests, tell us at onboarding and we will agree turnaround commitments in the contract.
We can produce what is held against a fan’s contact details. Today that is assembled by our team from per-event exports rather than produced by a single button, so allow us working days rather than minutes inside your statutory month.
A fan who unticks the marketing box on a later upload has that withdrawal recorded immediately and permanently.
There is no fan-facing preference centre and no unsubscribe link in delivery emails — those emails are transactional, delivering content the fan asked for, and there is no marketing send engine in the platform. A withdrawal that doesn’t come through a later upload has to reach us and we action it directly.
Passing a fan’s contact details from a league down to an individual club is off by default. The platform blocks the share for any fan not marked as consenting, and a recorded withdrawal blocks it even if that marker says otherwise.
There is not yet a checkbox in the fan-facing app for a fan to give this consent, so in practice no new fan can currently grant it. And fans who took part before this change retain the previous default of “shareable” without ever having been asked. Talk to us before running a league-to-club activation and we will agree how to handle both.
A fan’s finished content is delivered by a link that opens without a login — that’s what makes it shareable. Those links now carry a cryptographic signature, so they cannot be guessed or enumerated by anyone working through possible addresses. Links issued before August 2026 predate the signature and remain openable by anyone holding them until the content ages out on the schedule below. Possession of a link still grants access, by design — treat one like a shared document link.
Assume 90 days for all fan media. Everything the platform writes — raw uploads and finished films, fan walls and personalised images alike — currently lives under a single storage rule that deletes a file 90 days after it was last written. Separate, longer retention for finished output is designed but not yet in force.
If you expect a season’s films to remain available for longer than three months, raise it with us before your first event rather than after. This is the retention question clients are most often surprised by.
Database records — a fan’s contact details, their consent history, the analysis derived from their content — do not currently expire automatically. The platform has the necessary fields to enforce a retention deadline, but nothing acts on them yet.
Automatic, policy-driven expiry of database records is not yet implemented. Until it is, deleting fan records at the end of a retention period is a request you make and we action. We would rather say so than imply an automated timetable that doesn’t exist.
Consent records are deliberately kept when the content they relate to is deleted. They are the evidence that the content was lawfully collected in the first place, and destroying them along with the content would defeat the purpose of keeping them.
Two things a thorough security questionnaire will ask about and we do not yet have: a web application firewall in front of the platform, and an audit log recording which staff member viewed or exported which fan data. Both are on the roadmap. Access is restricted by role today, but it is not independently logged.
On becoming aware of a personal data breach we notify you without undue delay, with what we know and what we are doing, so that you can meet your own 72-hour obligation. We do not notify your fans directly — that is your decision as controller.
By default the platform does not ask a fan’s age and applies no age check. It cannot tell whether a participant is a child.
There is one exception you configure yourself: an activation step can ask for a date of birth and can be set to require a minimum age. Where you enable it, the date the fan enters is stored with their submission and you should treat it as personal data in your own record of processing. Note that this check runs in the fan’s browser — it is a usability prompt, not an enforced control.
Live sport has a lot of children in the crowd. Since we cannot tell you whether a participant is one, the age-appropriate design assessment is yours, and it should be made before the event rather than after. The strongest mitigation available in the product is to run the activation anonymously: no contact details collected means no contact details held for anyone, child or adult.
We do not knowingly build profiles of children, and nothing in the platform targets advertising at fans of any age. The aggregate audience reporting includes an under-18 band so you can see whether young people were present.
Everything on this list is a known gap named elsewhere in this document. It is here so you can see we know about it and plan around it.
The statutory particulars, kept short. Our privacy policy covers data we collect about you as a visitor or client contact, as distinct from the fan data described above.
FANDEMiQ Ltd, registered in England and Wales, company number 17177298. Registered office: Totnes, Devon, TQ9 5HR. We are the controller for data collected through this website and through platform administration. When we operate fan engagement activations for a client, that client is the controller and we are the processor — as set out at the top of this document.
Where personal data reaches a provider outside the UK or EEA — the three US flows named in the table above — we rely on adequacy decisions, the UK International Data Transfer Addendum, or Standard Contractual Clauses approved by the Information Commissioner’s Office, as applicable to each provider.
Data protection queries, rights requests and security questionnaires: hello@fandemiq.net, or write to us at the registered office above. We respond to rights requests within one calendar month.
If you are not satisfied with our response, you have the right to complain to the Information Commissioner’s Office, the UK supervisory authority for data protection, at ico.org.uk or on 0303 123 1113.
Send us your security questionnaire or DPIA and we will answer it against this document.