fanping Privacy Policy

Operated by: Antrium GmbH (“Antrium”, “we”, “us”, “our”) Service: fanping (the “Service”) Version: 1.24 Effective Date: October 7, 2026

This Policy describes how the Service processes personal data as it operates at the date of publication.

1. Controller

The controller responsible for the processing of personal data under this Policy is:

Antrium GmbH, Hackhofergasse 1, 1190 Vienna, Austria; Commercial register: Handelsgericht Wien, FN 673398t; VAT ID (UID): ATU83090049

“fanping” is a brand and product name; the operating legal entity is Antrium GmbH.

Contact details for all privacy matters, and the competent supervisory authority, are set out in Section 16.

2. Scope, Roles and Definitions

fanping is a two-sided push-notification platform. Creators compose and send “pings” (push notifications) to Fans who follow them through public channels, QR codes or deep links.

“Personal data”, “processing”, “controller”, “processor”, “pseudonymisation” and “special categories of data” have the meanings given in the GDPR (Regulation (EU) 2016/679).

3. Personal Data We Collect

We collect only the data described below. Providing account data is necessary to create and operate an account; without it, the Service cannot be provided (Art. 13(2)(e) GDPR). Fans can use the Service anonymously, and optional features (for example camera-based QR scanning or dashboard analytics) can be declined without affecting core use. We do not operate third-party advertising, marketing or tracking technology, we do not sell personal data, and we do not buy or enrich personal data from data brokers.

3.1 Creator account data

Creators sign in exclusively through Google, Apple, Twitch, Kick or Discord OAuth. There is no creator email/password registration. From the OAuth provider we receive and store: the provider subject identifier, email address, optional name, and an “email verified” flag. For Sign in with Twitch we request only the openid and user:read:email permissions, and we receive only your Twitch subject identifier together with your email address and its verification status. The sign-in exchange itself carries no name and no profile image, we make no further calls to Twitch for signing you in, and the short-lived access token from the sign-in exchange is released back to Twitch immediately and is never stored. A Twitch account that has not confirmed an email address cannot be used to sign in. For Sign in with Kick we request only the user:read permission and we receive your Kick account id together with the email address on the Kick account. Kick does not tell us whether that address is verified; we therefore treat it as contact information only, your account identity binds to the Kick account id and never to the email address, and a Kick account without an email address cannot be used to sign in. From that single profile lookup we also take your Kick name and the address of your Kick profile picture; when you create your account, we use them as starting values for your fanping display name and avatar where you have not set your own (the name only after the same checks as any display name you enter, the picture only as a link to Kick's image server, not as a copy), and you can change both at any time. We make no further calls to Kick for signing you in, and the short-lived access token from the sign-in exchange is used for that single profile lookup and then revoked at Kick; it is never stored. Signing in with Kick is separate from connecting the Kick integration (Section 3.8); when you sign in with Kick you accept the Kick integration terms as part of creating your account, and we then establish the connection for the channel you signed in with, without asking you to authorise Kick a second time. Through that connection we receive your channel's public profile, including its username and avatar (Section 3.8); once the connection exists, its avatar takes the place of the starting picture. Signing in with Twitch is separate from connecting the Twitch integration (Section 3.8): the sign-in exchange gives us none of the channel data described there. When you create your account with Twitch you accept the integration terms as part of sign-up, and we then establish the channel connection. Through that connection (not through the sign-in) we receive your channel's public profile, including its display name and avatar (Section 3.8), and the channel name can be suggested as your fanping display name during setup, where you choose and can change it. For Sign in with Discord we request only the identify and email permissions and we receive your Discord user id together with the email address on the Discord account and whether Discord has verified that address; we accept the sign-in only where Discord reports the address as verified, so a Discord account without a verified email address cannot be used to sign in. From that single profile lookup we also take your Discord display name (or your username, where you have no display name or it does not pass our checks) and the address of your Discord profile picture; when you create your account, we use them as starting values for your fanping display name and avatar where you have not set your own (the name only after the same checks as any display name you enter, the picture only as a link to Discord's image server, not as a copy), and you can change both at any time. We make no further calls to Discord for signing you in, and the short-lived access token from the sign-in exchange is used for that single profile lookup and then revoked at Discord; it is never stored. Signing in with Discord is separate from connecting a Discord server (Section 3.8): the sign-in gives us no access to any server, connecting a server does not sign you in, and, unlike Twitch and Kick, no integration is established and no integration terms are accepted as part of sign-up. We additionally store: display name, an avatar fallback colour, locale and display preferences (time/date format, and a timezone that is preset from your browser or from the location information our network provider Cloudflare (Section 8) derives from your connection, and that you can change), QR-code customisation settings, an optional public imprint link (a URL the creator chooses to provide, which the creator thereby publishes on their public channel page, voucher pages and their creator profile in the fan app; like other links you submit, it is screened by our link-safety provider before it is accepted, Section 3.5), account and billing status, and consent and age-confirmation timestamps (terms, privacy, 18+ confirmation, and the analytics consent state for the dashboard). Where you write an optional channel-page bio, we store the current bio text and, while a submission is being screened, the submitted draft together with the screening outcome (Section 3.5); the bio appears on your channel page in the fan app, visible only to signed-in fans who follow your channel, and stays until you change or clear it or until your account is deleted. While you set up your account, we also keep a record of your own setup steps (for example which setup path you chose, whether a test post went out, whether you downloaded your QR code, and whether you sent or skipped the community post), each with a timestamp and at most a short technical detail; it contains nothing about any fan, we read it only as aggregate counts across all creators to improve the setup, it is included in your data export (Section 12), and it is deleted 180 days after each step and with your account. So that the dashboard can continue your setup where you left off, on any device, we also keep one record of your current setup state: which way you chose to start, how far you got in the optional self-test and in the guided setup, your own confirmations that you follow your channel on your phone and that your test ping arrived, which offers you put off and, where you opened the setup link from our /fanping command in a Discord server, that server's id, so that the connection page can preselect it (not its name). If you pair your own phone for the self-test, the record also holds the one-time pairing code (valid for 15 minutes) and a reference to the fan account that opened it, used only so that this account is not counted as a fan you won; you see nothing about that fan account, and the reference is removed when that fan account is deleted. The record holds the current state only, is overwritten as you go and is deleted with your account; apart from the pairing details (the code, its times and the fan account reference), it is included in your data export (Section 12).

The creator email and the Google, Apple, Twitch, Kick and Discord subject identifiers are encrypted at rest (Section 10). Where available, you can add further Google, Apple, Twitch, Kick or Discord accounts of your own as sign-in methods for the same fanping account, after confirming with a method you already have; the rules above apply to each of them, its subject identifier is encrypted in the same way, and its email address is never used to find or merge accounts. For each sign-in method we also keep when you added it, a hint so that you can recognise it in your settings (a masked form of its email address or, for Kick and Discord, its account name) and when you last signed in with it; we use that time only to make sure you can still sign in before you remove another method. These details are deleted when you remove the method or your account, and removing a method signs you out on your other devices. Connecting an integration or a Discord server never adds a sign-in method.

3.2 Fan account and device data

A fan is either anonymous (no credentials) or registered (a username and a password). We do not collect a fan email address. For registered fans we store the username (encrypted at rest) and a salted password hash; passwords are never stored in plain text. For all fans we store an 18+ self-confirmation timestamp.

For each fan device we store: a client-generated device identifier, the push token (encrypted at rest), the platform (iOS/Android), the app version, and device-attestation material (Apple App Attest or Google Play Integrity).

For anonymous fans, the app derives a one-way hash from an OS-provided device identifier on the device; the raw identifier never leaves the device and we store only the hash. We use the hash as an anti-abuse safeguard, so that a single device cannot accumulate multiple anonymous accounts: if a device that already has an anonymous fan account creates another one (for example after a reinstall), we retire the earlier anonymous account and create a fresh one. A retired account is inactive: its sessions are ended, its follows are suspended and do not count towards any creator’s follower numbers or limits, and it receives no pings. It is permanently deleted within 14 days; until then it can be restored with your recovery code. During a declared incident-recovery window (a bounded, logged period we activate after a technical incident), creating a new anonymous account from a device we recognise may instead restore your existing anonymous account (or its retired predecessor). Outside such a window, a reinstall always starts fresh. The hash is never used to match or recover a registered account, and it is deleted together with the anonymous account.

Fans can set up a passkey to help secure and recover their account. When you create one, your device generates a key pair; we receive and store only the public key, together with a credential identifier, the device platform, and usage metadata. The private key never leaves your device or your passkey provider, and unlocking it with your screen lock or biometrics happens only on your device; we never receive or process biometric data. The passkey is specific to fanping by design and cannot be used to track you across other services. It is deleted together with your account and is included in your data export. A synced passkey may also be stored in your own iCloud Keychain or Google Password Manager account; that storage is your relationship with Apple or Google, not processing by us.

The Fan App requests camera access only when you actively open the QR scanner to follow a creator. Camera frames are processed exclusively on your device to decode the QR code; no images or video are recorded, stored, or transmitted to our servers or to any third party. You can use the app without granting camera access; scanning is then unavailable and you can follow creators via links instead.

3.3 Notification preferences

Fans can set quiet hours, a timezone, lock-screen display toggles (whether to show the stream title and the creator avatar in the notification), per-follow notification toggles and, for a creator who streams on more than one platform, which of those platforms they want to be alerted for. These preferences are stored and synchronised, but they are enforced on the device by the app, not by suppressing delivery on our servers.

3.4 User-generated content

Creators publish “pings”, each of which may contain free text (up to 280 characters; plan-specific lower limits may apply), a single link, and a fixed system template. Channel names are public 8-character handles. Creators may also save link entries with labels. Pings are delivered to all followers of the channel; in this sense ping content is public to the creator’s followers. Creators cannot attach or upload images or other media to pings. A ping may show a picture belonging to the content it announces or links to: the live preview of the stream a go-live ping announces (from the creator’s own connected channel), the preview image of a stream recording, or the thumbnail of a video the ping links to on a recognized platform. Such a picture is shown only after automated screening: we store only the picture’s public address on the platform and a fingerprint of the exact screened image, never the image itself; your device fetches the picture directly from the platform, and it is shown only while it still matches the screened fingerprint. Where a creator attaches a voucher drop to a ping, fanping processes the creator-supplied code solely to transmit it to eligible fans and to record how many claims have occurred; fanping does not evaluate, validate, or guarantee the code. A creator can also attach a poll to a ping, to the prepared announcement for their next stream, to the stream recap (a recap armed for one stream, or the automatic recap a creator can switch on to go out after every stream, delivered in the app only and without a push notification), or to the welcome message new followers receive: a question with a fixed set of answer options that the creator writes. The question and options are the creator’s content: they are screened like any other ping content, when the poll is saved and again before it is sent; once the first vote has been cast, the question and options can no longer be edited (a creator who wants a different question duplicates the poll instead). How fans’ votes are handled is described in Section 3.4a. A creator can also prepare the announcement for their next stream, or the recap sent after it (Section 3.8), in advance instead of sending a ping by hand, and can attach a voucher drop to it. In that case we store what the creator entered — the message text and the options they chose and, for a drop, the code or codes and, optionally, an additional link and a short hint text shown with the drop — until the announcement or recap goes out or the creator removes the prepared entry again. Removing it deletes it. Once it has gone out, the stored code or codes, the extra link and the hint text are deleted from the entry, as are any subscriber names a recap printed. What stays is the entry’s outcome, the message the creator wrote for it and, for a recap, the public reference to the stream it described (the address of the recording, its title and its preview image, where the platform provides them), so that the message that went out stays displayable and checkable; Section 6 says how long we keep it. A prepared entry is screened like any other ping content, both when it is saved and again when it is sent. For each ping you send or schedule by hand, we also keep with the ping where it was decided to go at that moment: the number of app recipients, the ids of the Discord channels it was meant for and whether it could appear in your Twitch panel, never channel or server names and no message content, so that your history stays correct when you change your setup later. A ping you send while nobody can be notified and nothing can be published is kept in your history as a ping that reached no one. Both are part of the ping record and share its retention (Section 6).

3.4a Polls and go-live check-ins (fan responses)

Where a ping carries a poll (Section 3.4), a fan who follows the channel can vote for one of its options and change that vote until the poll closes. A creator can also pin one of their polls to their channel page in the fan app; a fan who follows the channel can vote on it there in the same way, without needing a delivered message. We store one vote record per fan and poll: which option you chose and when. Results are aggregates only, for everyone: the creator and our own systems see how many votes each option received, fans and viewers see each option's share as a percentage, without vote numbers (a poll posted to Discord as a native Discord poll shows Discord's own live counts there, which cannot be hidden), and no surface, log or export we provide to a creator discloses who voted for what. A creator can choose to show fans the results in the Service only after the poll closes or only once the creator reveals them; until then you see the question, the options and your own vote. Where the creator forwards such a ping to a connected Discord channel and native Discord polls are enabled for the Service, the same poll is posted there as a native Discord poll under the sender identity configured for that channel; from Discord we read back only the per-option totals, we never call Discord’s interface that lists individual voters, and we store no Discord account id for any poll. For a poll that reached you with a message, your vote window is tied to your own delivery of that message and to your follow of the channel, so a long-running poll does not keep an old delivery open for voting; for a poll pinned to a channel page, you can vote while you follow the channel and the poll is still pinned and open. A vote is deleted when the poll it belongs to is deleted, when your fan account is deleted, and in any case 90 days after the poll closes; the aggregate counts keep the result. Section 6 says how long a poll itself is kept.

Voting on a shared poll in your browser. A creator can share one of their polls as a link. If you open it in a browser while the poll is open, you can vote there without the app and without an account, and change your vote while the poll is open. To count each browser once and to let you change your vote, our server sets a cookie with a random identifier (fp_wv, valid for 12 months, sent only to our public channel addresses); we store only a cryptographic hash of it together with your chosen option and the time, never the identifier itself, and we build no profile from it. While a poll can be voted on, the page runs Cloudflare Turnstile, which processes your IP address and technical information about your browser to tell people from automated traffic (Section 8); a vote is accepted only with a passed check, and the voting address is rate-limited per IP address (the address is held only for the limit window). To show dates in your local format, the page uses the country code and, where available, the time zone that our network provider derives from your request; neither is stored. Results appear as percentages only and follow the creator's choice of when they become visible. Your vote is deleted 90 days after the poll closes and in any case with the poll (Section 6); it is not part of any export, because no account exists. We process the vote to provide the voting function you choose to use (Art. 6(1)(b) GDPR) and on the basis of our legitimate interest in counting each browser once and protecting the voting address against abuse (Art. 6(1)(f) GDPR); the cookie is strictly necessary for the vote you request (§ 25(2) no. 2 TDDDG).

A go-live ping can offer quick check-in responses (for example “On my way”, “Remind me in 15” and “Not today”). If you answer, we store one answer per stream: which response you chose, the channel and stream it belongs to, and the time; answering again replaces your earlier answer, and withdrawing your answer deletes the record. We keep an answer for at most 90 days after the stream. The creator sees only aggregate counts per stream — how many fans answered each way — never who answered what. “Remind me in 15” schedules a single reminder to your own devices, sent only if the stream is still live at that time and respecting your quiet hours; the reminder is a courtesy delivery to you and does not count against the creator’s sending limits. “Not today” takes your devices off that channel’s push delivery on our servers for the rest of that stream, including its recap; delivery resumes automatically when the stream and its recap are over, at the latest 24 hours after your answer, and registering a device anew does not bypass an active mute. This server-side silencing is the one exception to the rule in Section 3.3 that notification preferences are enforced on the device, and it happens only because you asked for it. If you open a live ping instead of using a quick response, we record the same “on my way” answer for that stream unless you already answered; this uses the tap event the app sends for interaction analytics, so if you have switched interaction analytics off (Section 5.2), no such event is sent and nothing is recorded when you open a ping. A creator can switch the quick responses off for their channel; an answer already given keeps its promised effect (a scheduled reminder is still delivered, an active mute still ends on its own).

3.5 Content-moderation data

Before a ping is delivered, its text, any display-name change and any link are automatically screened for safety by our moderation providers (Section 8). Links may be exempted from link screening when they point to a defined set of recognized platforms; such links are then not transmitted to the link-safety provider. We store the screening result, not a copy of the screened content.

Where you choose to display your content on a connected third-party surface (such as the fanping Twitch Extension), your content is additionally reviewed automatically for compliance with the display rules of that surface. These checks may be performed using automated and AI-based services operated by processors on our behalf (Section 8). The outcome (a visibility status and reason per surface) is stored with your content and shown to you in your dashboard. Content submitted to these providers is not used by them to train their models.

3.6 Reports, feedback and complaints

A fan can report a creator or a ping, selecting a reason (child safety, spam, inappropriate, harassment, impersonation, scam, other) and optional free-text detail, and confirming the report is made in good faith. Child-safety reports are prioritised for human review. We store the report (reporter identifier, reason, detail, target, status). Reporter identity is protected: it is never shown to the reported creator and is redacted in a creator’s data export under Art. 15(4) GDPR.

A fan or creator can submit feedback (bug, feature, general, or complaint), with a message and optional metadata. The feedback message and metadata are encrypted at rest.

3.7 Analytics (pseudonymised)

To operate the Service and to give creators aggregate insight into their channel (for example deliveries, opens, follows and reactions over time, including when their audience is most responsive), we process interaction events in pseudonymised form: before an event is stored, the fan identifier is replaced with a salted one-way pseudonym, together with coarse context supplied by the app (timezone name, operating system, app version). We use these events for service improvement and aggregate creator statistics. We do not use them for advertising and we do not build individual fan profiles (Section 11).

Pseudonymised data remains personal data under Art. 4(5) GDPR and we treat it accordingly. Fans can switch off interaction analytics at any time through a self-service toggle in the Fan App (Settings → Data & Privacy); the switch takes effect immediately, on the device and on our servers (Section 5.2).

3.8 Integration data (Twitch, Discord, YouTube and Kick)

If a creator connects Twitch, we receive and store the creator’s public Twitch profile: user id, login, display name and profile image URL; we use the stored profile-image URL also to periodically re-verify the source image of a generated channel QR (see below). For this connection we do not request Twitch OAuth scopes beyond the event read permissions described below, and we do not receive a Twitch email address. The short-lived Twitch user access token used to make the connection is revoked immediately after the initial profile lookup and is not stored. (The separate Twitch sign-in described below and in Section 3.1 does receive your email address; the two are distinct.) If you enable the stream-online auto-ping, we receive stream-online events for your channel from Twitch to trigger that ping. For creators with a connected Twitch account we also keep a current live-state record for the channel (whether the channel is live, the stream title, and the game/category), refreshed from Twitch, to power the auto-ping and to show the channel’s live status in the Service. Stream titles pass our automated content screening before they are shown to fans; a title that fails screening, or cannot be screened, is not shown. The live-state record is cleared when the Twitch connection is disconnected or revoked, and it is deleted with the creator account.

Sign in with Twitch (a separate lane). Twitch is also one of the providers you can use to sign in to fanping (Section 3.1). That sign-in uses a separate authorisation with its own permissions: it requests only the openid and user:read:email permissions and yields only your Twitch subject identifier, your email address and its verification status, both stored encrypted at rest. The access token from that exchange is released back to Twitch immediately and is not stored, and the sign-in gives us no ongoing access to your Twitch account. Signing in with Twitch does not connect your channel and does not start any of the processing described in this Section or in Section 3.8a. When you sign in with Twitch you accept the integration terms as part of creating your account, and we establish the connection for the channel you signed in with, without asking you to authorise Twitch a second time; from that point on the connection is the one described above, including its data, its retention and its deletion on disconnect.

Avatar QR code (optional). If you explicitly enable the channel-QR feature, we use the image your channel currently shows as its avatar — your uploaded avatar or your public profile image from the platform you connected (Twitch, YouTube or Kick) — to generate an artistic QR code that you can publish as your channel’s public QR (for example on your landing page). Automated face detection is used solely to position the image crop; this is image cropping, not identification. We do not extract, store, or match any facial template or biometric identifier. The generated QR is stored and served via our content-delivery provider (Section 8); the source profile image is held only transiently to render the QR. The QR is deleted from our storage immediately and purged from the content-delivery-network edge cache when you disconnect the platform the source image came from, disable the feature, or delete your account; any residual cached copy expires within at most 24 hours.

If a creator connects Discord, we store the connected server (guild) id, server metadata (name, icon, approximate member count) and the per-channel delivery configuration. The webhook URL we create is encrypted at rest and is excluded from data exports. Our bot has write-only permissions: it posts your pings and does not read message content, member lists, or presence; the only data it reads back are the aggregate reaction and poll-vote counts on its own posts, as described below. If you switch on live roles, we additionally store your own Discord account id, which we receive once when you connect (Discord’s “identify” permission), and we use it for one purpose only: to add the role you chose to your own member entry in that server while you are live, and to remove it again when your stream ends. Apart from a helper who accepts a delegated setup link (Section 3.8c), we do not read or store any other member’s account id, roles, or profile. Your account id and the role settings are deleted when you disconnect the server and when you delete your account. Signing in with Discord (Section 3.1) is a separate lane: it gives us no access to any server, and connecting a server does not sign you in.

Slash command and bot status. Our bot offers one command, /fanping, that any member of a server the bot has been added to can use. When someone uses it, Discord sends us that interaction; we read from it only the server id and whether the caller may manage that server, we answer only that person with information already visible in that server (the connected creator’s display name, the channels the creator configured, the public channel-page link and, for server managers, when we last posted), and we store nothing about the caller and log no identity, only an aggregate count of uses. Our bot also holds one standing connection to Discord solely to show its own online status; over that connection we request no events about servers, members, messages or other users’ presence, and we store nothing from it.

Delivery records. For every message our bot posts we keep a hash-only delivery record (the message and channel id, which mentions it was configured to trigger, a cryptographic hash of the posted content, never the text itself, and a delivery status) for up to 90 days, to show delivery state and to remove our own posts when you retract a ping. Where a posted message shows a countdown, our bot keeps that line current: about once a minute it checks whether the countdown line has changed and, only then, reads its own message back from Discord, replaces only that line and saves the message again, without a new notification. For this we keep, next to the delivery record, the message and channel id, the countdown it belongs to, a status and a hash of the line last written, never the message text; this record is deleted with the delivery records after 90 days, when you disconnect the server or when you delete the countdown. The one community post described next is the exception: it is kept as its own record, with its text.

Community post. During setup you can send, once per account, a community post to one of the channels you connected: a message you write, screened like your other Discord content, posted under the sender identity configured for that channel together with your channel QR code and links to your channel page and the app stores, and notifying no one. For this one post we keep the text you wrote together with the channel and message ids and the time you claimed and sent it, so that we can show you the post, link to it in Discord and make sure it cannot be sent twice; the record is kept for the life of your account, is included in your data export (Section 12), and is deleted with your account.

Click statistics. The outbound links in the posts our bot delivers are, when click statistics are enabled for the server, routed through a fanping first-party redirect (go.fanping.app), so that destinations can be screened for safety and malicious links blocked; we store a redirect token per wrapped link (its destination URL and an expiry). Clicks are counted only for channels where the creator has enabled click statistics, and we count clicks in aggregate only: short-lived, pseudonymised per-day counters that are automatically discarded within 24 hours after the day ends, plus a per-day, per-channel aggregate (clicks, an estimated unique-visitor count, and a coarse country tally). We store no per-visitor record.

Reaction and poll statistics. If you enable reaction statistics for a channel, we periodically read back the aggregate emoji reaction totals that Discord attaches to the messages our bot itself posted to that channel (for about three days after each delivery) and store only those aggregate counts (emoji and number) with the hash-only delivery record, for up to 90 days. We do not receive, store, or show who reacted, and the stored statistics contain no user identifier. The same applies to a poll one of your pings carried to a channel there: we periodically read back only the aggregate per-option vote totals Discord reports for that message and store them as counts with the poll; we never receive, store, or show who voted on Discord.

The redirect interstitial and the single functional skip-cookie are described in Section 14; ordinary request logs, which do contain IP address and request path, are covered in Section 3.9.

If a creator connects YouTube, we receive and store the creator’s public YouTube channel profile: channel id, handle and avatar (channel image) URL. We obtain this through Google’s standard OAuth authorisation; the OAuth access token is used once, immediately after you connect, to look up your channel id, and is then discarded. We do not store a YouTube access or refresh token, we do not post to your channel, and we do not access any private data. To power the go-live auto-ping and to show your live status in the Service, we receive go-live notifications for your channel (via YouTube’s PubSubHubbub push feed and periodic polling of the public YouTube Data API) and keep a current live-state record: whether the channel is live, and the (moderated) stream title. Stream titles pass our automated content screening before they are shown to fans; a title that fails screening, or cannot be screened, is not shown. We also receive a notification through the same push feed when your channel publishes a new video or premiere; because that feed can miss an event, we additionally check your channel's public list of uploads through the official YouTube Data API about every 15 minutes, limited to public videos published after you connected and within the last 48 hours. The new-video auto-ping is enabled by default when you connect YouTube; you can turn it off at any time in the dashboard. While it is on, we use the video’s public id and title to compose and deliver that ping — the title passes the same automated content screening before it is shown to fans, and the ping links to the video’s public watch page — and we keep a short-lived per-video delivery record for up to 7 days solely to prevent duplicate pings. A video that is uploaded but not public (private, unlisted, or scheduled for later) is not visible to us and triggers no notification and no ping. The live-state record and the stored channel profile are cleared when the YouTube connection is disconnected or revoked, and are deleted with the creator account. This integration uses YouTube API Services; by using it you also agree to the YouTube Terms of Service and acknowledge the Google Privacy Policy. You can revoke fanping’s access to your Google/YouTube account at any time through your Google security settings.

If a creator connects Kick, we receive and store the creator’s public Kick profile: account id, username, channel slug (channel address) and avatar URL. We obtain this through Kick’s standard OAuth authorisation (scopes limited to reading account and channel information and subscribing to channel events); the OAuth access token is used once, immediately after you connect, to look up your profile, and is then revoked at Kick. We do not store a Kick access or refresh token, we do not store your Kick password, and this connection is not how we obtain an email address (your Kick email address is processed only when you sign in to fanping with Kick, Section 3.1), we do not post to your channel or read your chat, and we do not access any non-public account data. To power the go-live auto-ping and to show your live status in the Service, we receive go-live and go-offline events for your channel (via Kick’s event webhooks and, as a fallback, periodic polling of the public Kick API) and keep a current live-state record: whether the channel is live, and the (moderated) stream title. Stream titles pass our automated content screening before they are shown to fans; a title that fails screening, or cannot be screened, is not shown. The live-state record and the stored channel profile are cleared when the Kick connection is disconnected or revoked, and are deleted with the creator account. Kick is operated by Kick Streaming Pty Ltd as an independent controller; Kick’s own Terms of Service and Privacy Policy apply to your Kick account. You can revoke fanping’s access at any time in your Kick account’s authorized-apps settings.

For creators who connect a streaming platform, we group the events of one stream under a random session identifier and keep the stream’s own metadata for that session: when it started and ended, its title, the categories or games shown during it, and, where the platform provides them, its peak viewer count and the public address, title and preview image of its recording. We use this to show the creator their own stream history and, where the creator has prepared a recap message, to send that message on their behalf after the delay they selected — and to cancel it if they go live again within that window. If the creator has set a go-live delay for a platform, we hold the assembled go-live announcement — the channel’s public live data, the message the creator prepared for it and, where a voucher drop was prepared, the link to its voucher page together with the extra link and hint text (never the codes) — for the delay they chose (between 1 and 30 minutes) and send it only if the stream is still live at that point; the held copy is deleted when it is sent or discarded. This data describes the creator’s stream, not their audience.

With your permission, we receive events from the platform you connected: from Twitch when someone subscribes to your channel, gifts a subscription, sends Bits, or takes part in a Hype Train, and from Kick when someone subscribes to your channel or renews or gifts a subscription. Twitch also tells us, without any additional permission from you, when another channel raids yours (which channel, and how many viewers it brought). Each event contains the platform’s own identifier for the person or channel, their public display name, and details of the event such as the tier or amount. Unless you have switched on a feature that stores them — such as the recap described below — we use these events only to pass them on to the features you have enabled at that moment; they are then held for at most 24 hours in transit and are not written to our database. We do not download subscriber lists from the platform.

If you enable the subscriber recap, we store, for each of your streams, the subscriptions and gifted subscriptions that happened during it: the platform’s identifier for the subscriber, their public display name, the subscription tier, whether it was a gift, and the time. We use this only to show you who subscribed during your stream and, if you choose so, to name them in your recap message. A recap that names them is a ping like any other: it goes to the fans who follow you and, where you have connected Discord, to the channels you configured there, and it is kept with your other pings. We do not link this to fanping accounts, we do not use it to target notifications, and we do not share or sell it. We delete it 90 days after the stream, when you disconnect the platform, and when your creator account is deleted. If you are a subscriber and you object to being recorded this way, contact us and we will exclude your platform account from this feature permanently.

If you also switch on the parts of the recap that thank the people who gifted subscriptions during your stream, or the channels that raided you, we store one record per such event: the platform’s identifier for the acting account and its public display name, how large the event was (the number of subscriptions gifted and their tier, or the number of viewers a raid brought), the platform’s own identifier for the event, and the time. Where a gift is made anonymously, the platform sends us no identity and we store none: the record then holds only the number of gifted subscriptions and the fact that it was anonymous, and the recap names it as “Anonymous”. We record these events only while your stream is live and only for a channel you have connected; an event that reaches us outside a live stream is discarded. We use them only to show you what happened during your stream and, if you choose so, to name the people and channels involved in your recap message, which reaches your fans as described above. We do not link this to fanping accounts, we do not use it to target notifications, and we do not share or sell it. We delete it 90 days after the stream, when you disconnect the platform, and when your creator account is deleted. If you gifted a subscription or raided a channel and you object to being recorded this way, contact us and we will exclude your platform account from this feature permanently.

3.8a Stream analytics for connected creators

If a creator connects their Twitch account to fanping and leaves stream analytics enabled (see Section 12 on the opt-out), we process ongoing stream data about their Twitch channel to provide the creator with their own statistics and to build aggregate benchmarks from it. We do not collect this data from the creator directly; we obtain it indirectly from the public Twitch API (collection from a source other than the data subject, Art. 14 GDPR).

We process the following data about the connected creator’s channel:

• Twitch login, display name and Twitch user id;

• stream title and game or category;

• the start and end of a live session (derived from the live state);

• viewer counts, sampled at regular intervals (an aggregate count of concurrent viewers, kept as a time series).

The viewer count is an aggregate figure. We do not collect individual viewers, chat names, viewer user ids, or any other attribute that could identify an individual viewing person; the connected creator (identified by Twitch login and display name) is the only person this feature concerns.

Purpose. We use this data to provide the connected creator with statistics about their own channel (for example peak and average viewer counts, session progressions, and ramp-up metrics) and to build aggregate, provider-wide benchmarks from it that do not identify any individual third party.

Twitch as source. Twitch is the source of this data (see Section 8). Where we display stream analytics, we label Twitch as the data source and link to the Twitch source page, and we also show the as-of time of the data.

3.8b fanping Twitch Extension

If you install and connect the fanping Twitch Extension (“fanping Channel Hub” in the Twitch directory) on your Twitch channel, we process the data needed to display your channel information on your Twitch surfaces: your Twitch channel identifier, your channel schedule and live status, your live agenda, your fan counter, an offline channel note you can write for your viewers (shown only while your channel is offline, screened before it is shown), a countdown or one of your polls you choose to pin to the panel (each passes an automated suitability check when you pin it) and, where you enable it, your recent announcements. We process this data to provide the connected display surface you enabled (Art. 6(1)(b) GDPR). To keep the session timeline current we receive stream lifecycle events (stream start and end, category and title changes) from Twitch’s official EventSub service for connected channels only; these timeline events are held transiently and are not part of your permanent record (see Section 6 on retention).

Viewers. The extension frontend sets no cookies, uses no local storage, and runs no tracking or analytics on viewers. When a viewer’s client requests the panel, our backend receives an opaque, Twitch-issued viewer identifier inside the signed request token plus standard short-lived technical request logs; we do not store the viewer identifier and we build no viewer profile. For our own product metrics we keep only aggregate render counts per channel and day, with no viewer identifiers and nothing recorded per viewer.

Voting on polls. Where a creator has pinned one of their polls to the panel and you choose to vote, we store your vote (the chosen option) under a pseudonymous key: a keyed cryptographic hash of the Twitch-issued opaque viewer identifier from the signed request token, salted with a random value specific to that poll. We use this key solely to count each viewer once and to rate-limit the voting endpoint; we do not store the identifier itself, we cannot reasonably attribute the key to any person, and we build no viewer profile from it. Poll results are stored as aggregate per-option counts only and shown to viewers as percentages, and no export we provide contains these keys. A poll can stay pinned to the panel after it closes, without accepting further votes, until the creator pins another poll or unpins it. Your vote is deleted 90 days after the poll closes, and the key, its salt and your vote are deleted together with the poll (Section 6). Voting requires being logged in to Twitch; viewers who are not logged in cannot vote. We process votes to provide the interactive display surface the creator enabled (Art. 6(1)(b) GDPR toward the creator) and on the basis of our legitimate interest in counting each viewer only once and in protecting the voting endpoint against abuse (Art. 6(1)(f) GDPR).

3.8c Delegated Discord setup (someone a creator asks for help)

A creator who does not administer their own Discord server can create a single-purpose, time-limited link and hand it to the person who does (we call that person the helper). If you open such a link, you sign in with Discord and accept the participation terms shown to you before anything about you is stored; those terms are published alongside our other integration terms. Until you accept, your Discord identity is held for at most ten minutes in a single-use temporary entry and in nothing else; if you close the page, no record of you is created.

When you accept, we store, on the creator’s session record: your Discord account id, the Discord name and avatar image address that Discord returns for that account, the version of the participation terms you accepted and when you accepted them, and a timestamp that we refresh while you have the setup page open so the creator can see whether you are working on the server right now. For each sign-in we additionally record an entry with your IP address and browser user agent. We ask Discord only for your basic account information and your server list; the server list is used once, to check that you administer the one server this link is for, and is not stored. We do not receive your Discord email address, we do not read messages, and we do not create a fanping account for you.

We use this to make the delegated setup work, to let the creator see who worked on their server and end that access when they want to, and to keep a record of who accepted the participation terms and when. The creator sees your Discord account id, name and avatar image, your acceptance time and whether you are currently active. The IP address and user agent are not shown to the creator; they are part of our own security record.

The legal basis is our legitimate interest, and the creator’s, in a delegated setup that stays accountable and can be ended at any time (Art. 6(1)(f) GDPR). You take part voluntarily and can decline by closing the page.

We keep the record for as long as the link can still be used and for 30 days after it ends, whether it ended by expiring or because the creator revoked it, and we delete it when the creator’s fanping account is deleted. Your rights and how to exercise them without a fanping account are described in Section 12.3.

3.9 Technical, security and log data

For security, abuse prevention and operation we process IP addresses and request metadata (for example for rate-limiting and device-attestation throttling). To protect accounts against password guessing, we keep a counter of failed sign-in attempts per account, keyed by a pseudonymised (hashed) form of the account name, never the plain text. This anti-abuse data is short-lived and expires automatically within at most 24 hours. We also keep application logs, which may contain identifiers, IP addresses and request paths (including a record of immediate account deletions) and are retained for 7 days (Section 6). Sensitive fields (passwords, tokens, push tokens, cookies, authorization headers) are masked in request logs.

3.10 Public Twitch stream telemetry (fanping insights)

To power fanping insights (statistics about how live-stream audiences build up, estimated from sampled public data), we collect public stream telemetry from the Twitch API about live Twitch channels above a small audience threshold: viewer counts over time, the streamed game/category, the broadcast language, the stream title, stream start/end and raid events, and, once per day, the channel’s aggregate follower total (the public total count only; identities of individual followers are never read or stored). Where another channel raids a tracked channel, we may additionally record the tracked channel’s aggregate follower total immediately before and about an hour after that raid, together with the raid’s size as reported by Twitch, to measure whether raids lead to follows; these are event-based readings of the same public total, they identify no individual follower and no individual viewer, and they are used only internally (Section 6). A channel owner can also add their own channel to fanping insights themselves: if you verify ownership of your channel through Twitch on your channel’s insights page, we begin collecting this telemetry for your channel from the moment of that verification (self-service opt-in). For each tracked channel we also store its public channel identity: the Twitch channel ID, login, display name, and public profile image (avatar), and we record which Twitch Extensions the channel currently has active (public extension name and public marketplace metadata only) and, from the stream start times and broadcast language we already hold, we estimate for our own shortlist how likely a channel streams from North America/Australia or from Europe (an estimate we never show and that decides nothing about you), used solely to shortlist channels for our own business outreach and never shown on any public surface. This telemetry describes public broadcasts; it contains no chat content and no data about individual viewers. We collect this data from Twitch, not from the streamer (indirect collection, Art. 14 GDPR); most affected streamers are not fanping users. We provide the information required by Art. 14 GDPR publicly in this Policy (Art. 14(5)(b) GDPR); where we contact a channel (see below), we provide it at the latest with the first message.

When another Twitch channel raids a tracked channel, the raid event we record includes the raiding channel’s public identity as carried by the Twitch notification itself: its login and display name, together with the time and the size of the raid. We store this also where the raiding channel is not itself tracked for fanping insights; it is the same name Twitch shows the raided channel at that moment (indirect collection, Art. 14 GDPR; notifying every raiding channel individually would be disproportionate, so we provide the information required by Art. 14 GDPR in this Policy, Art. 14(5)(b)). We use these records to show the raided channel’s owner statistics about the raids into their own channel: who raided them, how large those raids were and how many of the arriving viewers stayed, expressly also as a basis for assessing potential collaborations with recurring raid partners. The name is shown only to the owner of the raided channel; we build no profile of a raiding channel across other channels, and a channel that has opted out of fanping insights is never named on any of these surfaces. A raiding channel can use the same verified opt-out and objection routes described in this Section to have its stored names removed and future naming suppressed. Raid event records, including these names, are kept for up to 12 months (Section 6).

From the raw telemetry we compute derived statistics (session summaries, audience ramp-up curves, comparative percentiles). Displayed values are estimates from sampled data and are labelled as such. Raw telemetry is kept short-term (Section 6); a private archive copy is kept for 21 days (Section 6), on the basis of our legitimate interest in accurate statistics (Art. 6(1)(f), Art. 5(1)(d) GDPR), solely so that derived statistics can be recomputed when we correct a calculation method, including corrections requested under Art. 16 GDPR. Per-channel statistics are displayed to signed-in fanping insights users, to a streamer who claims their own channel’s page (Twitch verification proves channel ownership), and to the holder of a private, expiring link we send to the channel owner (see below); we will update this Section before any broader public availability. Where we display stream statistics, we label Twitch as the data source.

For each channel we track, we also check whether the channel's public Twitch bio lists contact routes (for example: a business email address or a Discord server). We record only which kinds of contact route exist (for example: email yes/no, Discord yes/no), never the address or link itself. We use this to understand which channels welcome business inquiries, so that our team can, where appropriate, reach out for business purposes (for example, to introduce fanping). If we reach out, we use only a contact route the channel has published for business inquiries, and only where such contact is permitted by applicable e-marketing law. Where we contact a streamer at a business address they publish themselves, we keep a record of that contact: the address, where we found it (including a screenshot of the public page it appears on), any notes on the applicable jurisdiction, and when we wrote. We keep this record to be able to show that our message was permitted, and to make sure that anyone who asks us to stop is never contacted again. Such a message may include a private, expiring link to your channel’s statistics. If we send you such a link, we record on our servers that the link was opened and when it was last opened, so that we can see whether our message reached you; we do not store your IP address, your device or browser details, or any identifier for the person opening the link, and we cannot tell from this record who opened it. You may object to outreach-related processing at any time, free of charge and without any verification (Art. 21(2) GDPR); we then stop it for your channel.

Streamers can have their channel removed from fanping insights at any time via a verified opt-out (Twitch login proves channel ownership); an opt-out removes the channel's pages, telemetry, derived statistics and contact-route records. An opt-out stays in effect unless you, as the verified channel owner, explicitly opt your channel back in (by connecting your channel as a creator with stream analytics enabled, or by verifying ownership on your channel’s insights page); no background process ever lifts an opt-out. Stream analytics for connected creators (Section 3.8a) and fanping insights are separate: deleting a fanping account or disabling stream analytics does not by itself remove a channel from fanping insights; the verified opt-out above is available to connected and unconnected channels alike.

4. Purposes and Legal Bases (Art. 6 GDPR)

5. What the Service Does and Does Not Do (accuracy statements)

To avoid misrepresentation, we state the following current limits explicitly.

5.1 Notifications are device-controlled in part

Quiet hours and lock-screen display toggles are enforced by the app on the device, not by our servers. A push is delivered to all subscribed devices of a channel’s followers, and the device decides how to display it. The one server-side exception is a fan’s own “Not today” answer to a live ping, which temporarily takes that fan’s devices off the channel’s delivery, as described in Section 3.4a.

5.2 Analytics and diagnostics controls

The Fan App provides self-service privacy toggles under Settings → Data & Privacy. Switching off interaction analytics takes effect immediately, on the device and on our servers: the app sends no further interaction events, analytics processing for the account is disabled, and any event still in transit is dropped before it is stored (Section 3.7). Switching off crash reports stops the Fan App from sending crash and error diagnostics from the device, effective immediately. The Creator Dashboard offers the same crash-report opt-out under Profile settings → Privacy: switching it off stops the dashboard from sending error diagnostics from the browser, effective immediately. Both controls are independent and both are on by default. The Creator Dashboard also stores an analytics consent state and uses optional analytics storage only with consent (Section 14). Whether or not you can reach the app or dashboard, you may object to either form of processing at any time via [email protected] (Section 12).

5.3 Notice-and-action only (DSA)

We accept reports about content and creators and review them. Our moderation process is described in the Terms of Service.

5.4 Image content

Creators cannot upload images into pings. Where a ping shows a picture (a live-stream preview, a recording’s preview image, or the thumbnail of a linked video, Section 3.4), the image is hosted by the originating platform and passes our automated image screening before it can be shown; a picture that no longer matches the screened version is not shown. Profile images provided by connected platforms (such as Twitch avatars) are hosted and moderated by the originating platform. We act on credible reports of illegal content (Section 5.3).

5.5 Email

We do not send marketing or newsletter email. We may send you service-related messages, for example about material changes to the Terms of Service or this Policy, or important account or security matters. Our payment provider Paddle sends its own transactional emails (for example receipts and invoices) as an independent controller. Account-related tokens are surfaced in product (in the app or the Creator Dashboard), not emailed. If you contact us, or ask us to reply to your feedback, we will use the email address you provide to respond. Emails you send to [email protected] are delivered directly to our Google-hosted support mailbox (Google Workspace, Section 8).

6. Data Retention

We retain personal data only as long as necessary for the purpose for which it was collected, subject to legal-obligation exceptions. The current periods are:

7. Disclosure of Personal Data

We disclose personal data only to the recipients listed in Section 8, to public authorities where legally required, and to professional advisers under confidentiality. We do not sell personal data.

8. Sub-Processors and Recipients

The following recipients receive or process personal data for the Service. “Processor” means the recipient acts on our instructions under a data-processing agreement; “independent controller” means the recipient determines its own purposes for the data it receives and its own privacy notice governs that data.

Error and crash diagnostics run on our own EU infrastructure and are not sent to any third-party error-tracking or analytics provider (Section 14).

We have data-processing agreements with our processors. Further information about a specific recipient is available on request via [email protected].

9. International Transfers (Chapter V GDPR)

Most personal data is stored in the EU: the application database is hosted in Germany, and encrypted database backups are held in the EU (West Europe). Some recipients are outside the EU or have a non-EU parent. We rely on the following transfer mechanisms:

You may request further information about, and a copy of, the safeguards for a specific transfer via [email protected].

10. Security Measures (Art. 32 GDPR)

We apply technical and organisational measures appropriate to the risk, including:

• encryption in transit and at rest, including field-level encryption of sensitive personal data;

• passwords and session tokens stored only in hashed form;

• access controls, mobile device attestation, rate-limiting, encrypted backups and restricted administrative access.

We do not publish further implementation detail of our security measures. No method of transmission or storage is completely secure; we cannot guarantee absolute security.

11. Automated Decision-Making and Profiling (Art. 22 GDPR)

The Service uses automated processing in two areas:

• Content moderation and surface suitability. Ping text, display names and links are screened automatically before delivery by more than one automated safety service; if content exceeds defined safety thresholds (or if a screening service cannot be reached), the content is blocked from being sent. In addition, for content that a creator chooses to display on a connected third-party surface (such as the fanping Twitch Extension), an automated service assesses whether the content is suitable for that surface’s display rules. The outcome is a visibility status and reason per surface, shown to the creator in the dashboard. These decisions concern whether and where a piece of content is displayed; they produce no legal or similarly significant effect on any individual, and a creator can revise and resubmit content or adjust where it is displayed.

• Automated pings and strikes. A creator can configure an automatic ping to fire when their connected channel goes live (immediately or after a delay they set), a new-video ping for YouTube, and a recap after the stream ends. Separately, moderation strikes can accumulate and lead to warnings or suspension; serious cases are escalated to a human.

Our analytics serves aggregate creator insight (for example, when a creator’s audience is most responsive). We do not evaluate individual fans, we do not make automated decisions producing legal or similarly significant effects about individual users, and we do not use profiling for advertising. Where we assess whether content is advertising in nature, this concerns the suitability of the content itself for a connected display surface, not any profiling of individuals; we do not build advertising profiles of fans or creators. We provide human points of contact for moderation and account decisions (Section 16).

12. Your Rights

Subject to the conditions in the GDPR, you have the right to:

• Access (Art. 15) and portability (Art. 20). You can export your data through the in-app data-export function, which returns your data as a JSON document (rate-limited to once per hour). The creator export includes profile (with your consent timestamps), your setup-progress record and setup state (Section 3.1), your sign-in methods (without their subject identifiers), channels, pings (with the recorded reach of each ping), billing records, saved links, feedback, reports filed against you (with the reporter’s identity redacted under Art. 15(4)), integration-terms acceptance records and Discord connections (the encrypted webhook URL is excluded). For a creator who uses the Discord integration, the export also includes that integration data, specifically the Discord configuration, the hash-only delivery records (including any aggregate emoji reaction counts stored with them) the redirect tokens (destination and expiry), the one-time community post and the countdown-line records; the encrypted webhook URL remains excluded. The fan export includes profile, devices, passkeys, follows and reactions, the welcome messages you received, your poll votes and your go-live check-in answers. Pseudonymised analytics events are not part of the self-service export but can be addressed on request.

• Rectification (Art. 16). You can edit your profile; contact us for corrections you cannot make yourself.

• Erasure (Art. 17). See Section 12.1, including the limited exceptions.

• Restriction (Art. 18) and objection (Art. 21). Because analytics and error diagnostics rely on legitimate interest, you may object at any time: the self-service toggles (Section 5.2) implement this objection with immediate effect, and the manual route via [email protected] remains available to everyone.

• Object to stream analytics (connected creators). If you connect Twitch and stream analytics is active for your channel (Section 3.8a), you can object at any time and switch it off through a personal opt-out toggle in the Creator Dashboard; switching it off stops further collection and triggers deletion of the derived stream data already collected for you (Section 12.1). If your channel data was processed indirectly via Twitch and you do not have a fanping account, you can still exercise your rights (access, erasure, objection) by contacting [email protected].

• Withdraw consent where processing is based on consent (for example, the analytics consent state in the dashboard), without affecting prior processing.

• Lodge a complaint (Art. 77) with the Austrian Datenschutzbehörde or your local supervisory authority (Section 16).

Where the data-protection law of your country or state gives you comparable rights over your personal data, you can exercise them through the same contact and we will handle your request under the law that applies to you.

To exercise any right, contact [email protected]. We respond within the statutory time limits.

12.1 Account deletion and erasure exceptions

Creators can request deletion from the dashboard; deletion completes after a 30-day grace period, and an active paid subscription must be cancelled first. A creator may also delete immediately using a one-time deletion token returned in the dashboard. Fans can delete from the app, either after a grace period or immediately. For registered fans, immediate deletion is available alongside the grace route. For anonymous fans, the in-app “Delete Account” action uses the grace-period route so that an accidental deletion can be undone (the same rationale applies when a reinstall retires a superseded anonymous account, Section 3.2); choosing “Delete & Log Out” instead deletes an anonymous account and its data immediately and irreversibly, and the app states this in the confirmation dialog before you confirm (an anonymous account has no credentials through which it could be recovered later). Registered fans can also delete their account without the app through the self-service deletion page at https://fanping.app/fan/account-deletion: after signing in and confirming, the account and all associated fan data are deleted immediately and every session token is invalidated at once. On deletion we erase or anonymise your personal data across our systems, including pseudonymised analytics keyed to your account. For a connected creator, disconnecting Twitch, switching stream analytics off, or deleting the account also deletes the associated stream-analytics data: the raw viewer-count snapshots and the derived statistics records are removed, and a deletion that cannot immediately reach the analytics store is queued and retried until it is confirmed. For a creator connected to YouTube, disconnecting the integration, revoking fanping’s access on the Google side, or deleting the account unsubscribes the go-live feed and deletes the stored YouTube integration data (channel profile and live-state record).

The following data is retained as an exception to erasure, on the basis of legal obligation or our legitimate interest in keeping moderation and financial evidence:

• records preserved as evidence of serious abuse or where required for legal obligations (for example child-safety incidents), for as long as the legal purpose requires;

• anonymised moderation and financial records (reports, strikes, billing events) from which your direct identifiers have been removed;

• limited copies persisting in encrypted backups for up to 31 days after deletion (a storage-level safety rule removes any remaining backup copy no later than 47 days after it was written).

12.2 Rights of streamers who are not fanping users

If fanping insights shows statistics about your Twitch channel and you are not a fanping user, all rights in this Section apply to you as well. You can opt out at any time via [email protected] (Section 16); where your channel’s insights page is available to you, the fastest route is the verified opt-out there (prove channel ownership with a Twitch login or with a one-time code placed in your Twitch bio); it removes your pages and data as described in Section 3.10. If you believe a displayed value is wrong, you can ask us to correct it; our calculation methods are versioned, historical values can be recomputed, and we will otherwise correct or delete values shown to be inaccurate (Art. 16 GDPR). You can also reach us at the contact address in Section 16; for removal requests we will ask you to verify control of the channel (via Twitch login or another suitable proof), so that no one can remove a channel that is not theirs.

12.3 Rights of a person who helped with a Discord setup

If you accepted a delegated Discord setup link (Section 3.8c), you have all the rights in this Section even though you never had a fanping account. Because you have no account, none of the in-app routes apply to you; write to [email protected] instead and name the Discord account you used, and we will locate the record from that. On request we tell you what is stored about you, correct it, or delete it. You can also object at any time to this processing (Art. 21 GDPR); an objection ends the session, so the setup access ends with it. Independently of us, the creator who invited you can end your access at any moment, and the link stops working on its own when its time window ends. Deleting or objecting removes the record we hold about you; it does not undo settings that were saved in the creator’s account or in their Discord server while you were helping, because those are the creator’s own data.

13. Children and Age Restriction

fanping is an 18+ service. It is not directed to children, and we do not knowingly process the personal data of anyone under 18. At sign-up, users confirm they are at least 18, and we record the confirmation timestamp. If we learn that we have collected data from a person under 18, we will delete it.

14. Cookies, Local Storage and Error Diagnostics

Creator Dashboard (web). We use only strictly necessary storage for authentication and security: session cookies and a short-lived OAuth state cookie. Optional analytics storage in the dashboard is used only with your consent, and your consent choice is stored. So that you do not lose work, the dashboard keeps drafts in your browser's local storage, including an unfinished send (a random request id and your draft) until its outcome is known; these entries stay in your browser and reach us only as the ping you decide to send; an unfinished send is removed once its outcome is known, a draft once it has been sent, and all of them when you sign out (not when a session merely expires). We use self-hosted fonts and serve no third-party advertising or tracking cookies. When you start a subscription checkout, our payment provider Paddle (Merchant of Record, Section 8) loads its checkout component and may set its own strictly necessary payment and fraud-prevention cookies as an independent controller; this happens only when you initiate a checkout.

Error and crash diagnostics. We operate error diagnostics on our own EU infrastructure, configured for error reporting only (no session replay, no behavioural tracing, no profiling). No diagnostic data is sent to a third-party provider. We rely on legitimate interest (Art. 6(1)(f)) for error diagnostics. You can switch off crash reporting at any time through the self-service toggles (Section 5.2) or object via [email protected] (Section 12).

Redirect service (go.fanping.app). On our link domain (go.fanping.app) we set functional first-party cookies that are strictly necessary for the service and never used for tracking or advertising: (a) a redirect-integrity cookie used to safely forward Discord link clicks, set only when you click a wrapped link in a Discord post and choose “don’t show this again”, so we can skip the interstitial next time; and (b) a claim-identity cookie named vclaim (a random identifier, no personal data) set when you open a voucher claim page, used solely to enforce one claim per person and to let you see a code you already revealed. Both are first-party, HttpOnly, set only on your explicit action (§ 25(2) TDDDG / Art. 5(3) ePrivacy exception for strictly necessary storage), and not shared with any third party; the redirect and claim pages load no third-party resources. The click statistics themselves are described in Section 3.8.

Landing and pricing pages. Our public marketing pages load no third-party scripts, fonts or tracking and set no cookies. The one exception is a poll a creator shares as a link: while it can be voted on, the page loads Cloudflare Turnstile to check votes, and our server sets the voting cookie described in Section 3.4a. Localized subscription prices are retrieved through our own backend; your IP address is not sent to our payment provider before you start a checkout (only a country code derived from your request is used).

Streamer insights pages. On our public streamer-insights pages we use a strictly necessary first-party cookie (HttpOnly) only after a streamer signs in to claim their page. That sign-in stays active on the device for up to 30 days from its last use; the streamer can end it on any device at any time with the sign-out control on their page. Ending the sign-in deletes nothing and does not release the claim; objection and deletion work as described in Section 12. We measure page views and clicks on these pages without storing or reading anything on your device: events carry a random identifier generated in memory for a single page view and are processed pseudonymously on our servers (legitimate interest, Art. 6(1)(f)); no cookie or local storage is used for this measurement, no cross-visit profile is created, and nothing is shared with third parties. You may object at any time (Section 12).

Fan App (mobile). The app stores authentication tokens in the platform secure store (iOS Keychain / Android Keystore) and keeps the push token and preferences in device storage. These are not web cookies.

15. Changes to this Policy

We may update this Policy. We will inform you of material changes as required by applicable data protection law, before the change takes effect where such prior notice is required; where a change requires your consent, we will seek it. The current version, with its version number and effective date, is always available at /legal/privacy.

16. Contact and Supervisory Authority

For privacy questions or to exercise your rights:

Antrium GmbH, Hackhofergasse 1, 1190 Vienna, Austria Email: [email protected]

You may lodge a complaint with the Austrian Data Protection Authority (Datenschutzbehörde), Barichgasse 40-42, 1030 Vienna, Austria (Art. 77 GDPR), or with your local supervisory authority.

17. Language

This Policy is drawn up in English. We may provide translations for your convenience, but the English-language version is the authoritative and controlling text; in the event of any conflict or inconsistency between the English version and a translation, the English version prevails.