FANDEMiQ · Data protection brief
A plain-English account of what we collect from your fans, what we do with it, where it goes, how the consent screen changes with where a fan is standing, 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.
Three narrow purposes are ours, not yours, and we say so rather than stretch the word “processor” to cover them: keeping the platform secure (access and error logs), improving it, and producing anonymised cross-client benchmarks — how an activation of a given kind typically performs. Benchmarks are built from de-identified aggregates only, never from a fan’s contact details or media, and we commit contractually not to re-identify anyone. For these purposes we rely on legitimate interests, and they are written into our data processing agreement as our own.
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 ticks the separate location box on the consent screen and their browser grants permission. For video we record a time-coded track of position, compass heading and motion; for photos, a single snapshot. Every upload records whether its coordinates came from the device with the fan’s permission, and only those are used in maps and reports. If the fan says no, no location of any kind is captured: we do not estimate one from their internet address.
We resolve the country — and for the United States, the state — a fan appears to be in when they take part, from their internet address. This is done by a database inside our own platform, so the address is not sent to anyone. It is a coarse jurisdiction signal used to choose the right consent screen and apply the right rules; it is never a location fix, and it tells nobody where a fan lives.
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.
Your fanbase is global, so the compliance model has to be. UK GDPR binds us for every fan everywhere because we are established here; that is the floor. On top of it, a small number of things change with where the fan is standing when they take part.
Each tick is recorded as its own ledger entry, stamped with which module produced it and the jurisdiction it was shown under. The wording of every module is editable and translatable by you, and every version ever shown is kept.
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, which screen module it came from, when, in what language, from what kind of device, and the country and state they were resolved to at the time. 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 entry references the exact wording the fan saw on screen, which is stored the moment the screen is composed, before the fan sees it. If you update your terms mid-season, we can still show precisely what any given fan agreed to. Every piece of content is linked to the consents that were active when it was submitted.
Where an activation collects no contact details, the fan’s acceptance of the terms is still recorded — keyed to the content they submitted rather than to a person. So a photo on a fan wall can always be traced to the terms it was uploaded under, even when we have no idea who uploaded it.
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 any 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.
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 under UK and EU GDPR arises where processing is used to uniquely identify someone, and nothing in this platform does that. The EU AI Act draws its lines differently: estimating age and gender from a face is “biometric categorisation” and carries a transparency duty, which the notice on the consent screen discharges. 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 can also estimate 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”.
Under the EU AI Act, inferring emotion from faces is an “emotion recognition system”: a high-risk use from December 2027 and already prohibited outright for employees and students. So the platform decides per upload whether it may run, and the answer is no — whatever your account setting says — for any fan in the EU or EEA, any event held there, any event whose audience is staff or students, and any upload whose location could not be resolved. It is on by default for your account elsewhere, you can switch it off per account or per event, and face analysis of any kind does not run for events in, or uploads from, China, Russia or Vietnam.
Mood 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 anywhere, switch it off in your account settings.
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 the rules above allow for that upload, 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. Where it is on, the consent screen tells the fan the result is AI-made. 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 and the consent ledger sit in Azure’s North Europe region in Ireland. Face analysis runs in London; image tagging runs in the Netherlands.
So fan content is stored and analysed inside the UK and the EU. Two flows do reach US providers, and both should be reflected in your privacy notice and your transfer assessment.
| Provider | What it receives | Region | When |
|---|---|---|---|
| Amazon Web Services (Rekognition) | Submitted images and video stills, for face detection and age, gender and — where enabled and permitted — mood estimation | London, UK | Core — off for events in, or uploads from, countries that forbid it |
| Microsoft Azure AI Vision | Submitted images, for descriptive tags, sponsor logo detection and adult-content screening | Netherlands (EU) | Core |
| Microsoft Azure Video Indexer | Submitted video, for scene, transcript and audio analysis | UK South | Core for video |
| Resend | A fan's email address and the message delivering their content. Resend stores message metadata in the United States whichever region sends it | 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 |
| 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. Our operational alerting (Slack) and telemetry (Azure Application Insights) carry error and performance signals, not fan content. The full sub-processor register names the transfer mechanism for each and carries a dated change log; changes are notified 30 days ahead with a right to object.
Fans’ browsers also load fonts directly from Google, which makes the fan’s IP address visible to Google in the ordinary way of any web page using a font CDN. Separately, when one of your own users opens a location heatmap in the dashboard, the consented GPS points are plotted through Google Maps from that user’s browser.
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 a photo or a 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.
Consolidating one fan across several events — every upload, every consent, every derived signal, keyed off their email address — is assembled by our team rather than by a button in your dashboard, and a video already used in a published film or fan wall needs that output removed or re-rendered first. 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 August 2026 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 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.
Your account has a retention period; 90 days is the default. An hourly job hard-deletes every clip and photo whose period has passed — the file, every still, every derived signal — and then forgets the contact details of any fan who no longer has content on the platform. The deadline is stamped on each upload the moment it arrives, so it cannot drift. The full retention schedule is published, category by category.
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.
Content that is still part of a rendered output — a fan wall or a finished film — is deferred rather than deleted from under it, and reported to us on every run so the decision is a deliberate one. Consent records are deliberately kept when the content they relate to is deleted: they are the evidence that the content was lawfully collected, and after a fan’s details are forgotten they point to an identity nobody can resolve.
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 — our contractual commitment is within 24 hours — 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.
The consent screen carries an age line — “I am 13 or over” — with the number set by the fan’s jurisdiction, and you can raise it for your account but never lower it. A fan under that age is offered anonymous participation instead of a dead end: no contact details, no marketing, their content still delivered on screen. This is a declaration, not verification; we do not attempt age verification and cannot tell you whether a participant is a child.
An activation step can additionally ask for a date of birth. 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.
Live sport has a lot of children in the crowd. 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. Precise location is off by default for everyone, which is what the UK Children’s Code expects.
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.
Since the first version of this brief we have closed: IP-address location guessing, automated retention, evidence for anonymous consent, the emotion-inference switch, and the jurisdiction-aware consent screen. Each is described above as it now works.
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, through platform administration, and for the three purposes named under “Who is responsible”. When we operate fan engagement activations for a client, that client is the controller and we are the processor.
Where personal data reaches a provider outside the UK or EEA — the two US flows named in the table above — we rely on the UK International Data Transfer Addendum or the EU Standard Contractual Clauses, and on the EU-US Data Privacy Framework and UK-US Data Bridge where the provider is certified. The sub-processor register names the mechanism for each.
Data protection queries, rights requests, complaints and security questionnaires: hello@fandemiq.net, or write to us at the registered office above. We acknowledge complaints within 30 days and 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.