Privacy Policy

What: your email address (always); a display name and profile picture if you signed in with Google, Apple or Discord; a Better Auth session row with a bearer token (mobile) or a session cookie (web), including the IP address and User-Agent that initiated the session; for delete-account flows a six-digit confirmation code that lives in our verification table for up to 10 minutes.

Why: to authenticate you, keep you signed in across devices, and let you manage your account.

Legal basis: Article 6(1)(b) GDPR - performance of the contract for your Valking account.

Retention: for the lifetime of your account. Sessions expire and are pruned on their own schedule; verification codes are single-use. When you delete your account, the user row and every cascading record (sessions, linked Riot accounts, favourites, search history, communications log) are removed.

What: your Riot PUUID, Riot ID (gameName + tagLine), and shard, written into our riot_links table when you complete the Riot Sign-On (RSO) link flow. We do not store any Riot password or long-lived OAuth refresh token after the link completes.

Why:to make your own profile recognisable to Valking (Premium gating, the home- screen card, “public profile” flow on a locked profile).

Legal basis: Article 6(1)(b) GDPR - performance of the linked-account feature you actively chose to enable.

Retention: until you unlink (sets unlinked_at on the row) or delete your account.

What: match history, agent and weapon stats, map analytics, leaderboard positions for the Riot IDs you (or any visitor) look up. This data is produced by Riot Games and exposed through the public Riot Games API; we cache, aggregate and recompute it on our infrastructure. We attach it to internal identifiers (rso_players row IDs, shard-partitioned profile tables) so we can serve subsequent lookups quickly.

Why: to provide the core stats and analytics features of the Service.

Legal basis:Article 6(1)(f) GDPR - legitimate interest in operating a third-party game- companion service over publicly accessible game data, balanced against the player’s reasonable expectation of visibility (Riot itself publishes the same information). Players can hide their profile via Riot’s own privacy controls.

Retention: we apply a retention policy to match data based on tier (free vs. Premium) that is documented internally in docs/PREMIUM_LIMITS.md. Stats older than the retention window are purged by a daily job.

Article 13 / 14 notice and objection (Article 21 GDPR).The players whose Riot IDs appear in our caches will in most cases not be users of valking.gg and will not have given us their contact details. Providing each player with an individual Article 14 notice would require us to contact every Riot player whose data we briefly cache, which is disproportionate within the meaning of Article 14(5)(b) GDPR (we rely on Riot’s own public-profile disclosures and on this Privacy Policy as the substitute disclosure surface). If you are a player and would like us to stop processing your public game data, the fastest route is to set your Riot profile to private in Riot’s own privacy controls - your profile disappears from our caches automatically on the next refresh. You can also object directly under Article 21 GDPR by emailing [email protected] with your Riot ID (gameName#tagLine); we acknowledge receipt within five business days, complete the purge and add the ID to a do-not-cache list within ten business days, and confirm completion within the one-month response window of Article 12(3) GDPR. We may continue to process the data if we can show compelling legitimate grounds that override your interests (Article 21(1) GDPR), which for a third-party stats tracker is a narrow set.

What: the players you favourite, the players you search for, your UI preferences. Stored server-side keyed by your user ID so the data follows you across devices.

Why: to power the favourites rail, the recent-search list, and per-user UI settings on the web and in the Apps.

Legal basis: Article 6(1)(b) GDPR.

Retention: for the lifetime of your account. Search history rolls forward in a fixed-size window (cap depends on tier) so older entries fall off automatically.

What: a RevenueCat app-user identifier that maps to your Valking user ID, the plan name, the source store (ios / android / promo), and the active-until timestamp.

Why: to know whether to unlock Premium features for you. We do not see your payment method, billing address or transaction amount - the store-of-purchase (Apple or Google) handles that.

Legal basis: Article 6(1)(b) GDPR.

Retention: while the subscription is active; archived entitlement rows remain attached to your account for support and dispute purposes for as long as the account exists.

What we see:for Premium subscriptions purchased directly on our website we receive only the minimum data needed to grant entitlements and to correlate the purchase with your Valking account: your email address, a RevenueCat customer identifier (App User ID), the package and product identifier you bought, the headline price and currency code, the billing country and postal code (for the place-of- supply VAT determination), the subscription state (active / lapsed / autorenew preference / expiry date), and a copy of our Premium entitlement entry on your account. We do not receive your full billing name, street address, payment card number, CVC, or the card’s primary account number; those data points never enter our infrastructure.

What Stripe and RevenueCat handle on their own: the hosted-checkout page that takes your card details is run by RevenueCat at pay.rev.cat; the actual charge runs through Stripe Payments Europe Ltd. as the payment service provider. Stripe captures and stores your payment instrument (PAN, CVC, expiry, full billing name, full billing address) for the purposes of card-network authorisation, fraud detection, AML / sanctions screening, and chargeback defence; for those purposes Stripe acts as an independent data controller in addition to its processor role for the contractual charge itself. RevenueCat acts as our processor under Article 28 GDPR for the subscription-lifecycle data flows (entitlement state, renewal events, customer-portal access). See Section 5 for the data-recipient breakdown.

Why: to take payment, to issue a VAT-compliant invoice, to grant cross-platform Premium access, to detect and respond to chargebacks or refunds, and to maintain the accounting record we are required to keep.

Legal basis:Article 6(1)(b) GDPR for the contractual processing (taking payment, providing access to Premium, issuing the receipt), Article 6(1)(c) GDPR for the statutory record-keeping described in Section 4.12, and Article 6(1)(f) GDPR for Stripe’s independent-controller activities (fraud / AML / chargeback defence - legitimate interest of the payment-network operator and of us in not absorbing fraudulent charges).

Retention: the live subscription fields (active-until, plan name, autorenewal preference) follow the Section 4.5 rule. Invoice records and the underlying transaction metadata are retained for ten years after issue under the statutory archival period - see Section 4.12. Stripe and RevenueCat apply their own retention policies to the data they hold as independent controller / processor; see their respective privacy notices linked from Section 5.

What: your subscription state per channel; the time you opted in or out; the IP and User-Agent of the device that made the choice; the locale you were reading the consent text in; the version stamp of the consent wording you agreed to. Every event is also appended to a history log so we can prove the opt-in if challenged.

Why: to send you the newsletter you asked for, to honour your unsubscribe immediately, and to be able to demonstrate the validity of your consent under § 7 UWG and Article 7 GDPR.

Legal basis: Article 6(1)(a) GDPR - consent. You can withdraw your consent at any time with no effect on the lawfulness of past sends, either via Account Settings → Communications, via the Unsubscribe link at the bottom of every newsletter, or via the one-click mail-client Unsubscribe button we wire through RFC 8058 List-Unsubscribe headers.

Verified single opt-in (no double opt-in): your email address is already verified by our one-time-code sign-in flow. We treat that prior verification as fulfilling the “evidence of consent” standard, and record the opt-in metadata above. If you subscribe from a context where your email is not yet verified, we will fall back to double opt-in.

Retention: opt-in state until you unsubscribe; consent-history rows for the lifetime of your account.

What: when an email we send to you bounces or is reported as spam, AWS SES forwards the feedback notification to our backend (signed via SNS). We record the event type, the recipient address, the SES message-ID, a diagnostic code and the timestamp.

Why: to protect our sender reputation, comply with Gmail/Yahoo 2024 sender requirements, and stop sending to addresses that no longer accept mail. Permanent bounces and spam complaints automatically unsubscribe the recipient from every channel.

Legal basis: Article 6(1)(f) GDPR - legitimate interest in maintaining deliverability of transactional and consented marketing email.

Retention: while your account exists. Cascade-deleted with the account.

What: request logs containing IP address, User-Agent, requested URL and response status for traffic to the API; rate-limit counters keyed by IP / Cloudflare-connecting-IP; an admin audit log for actions taken by operators.

Why: to detect abuse, throttle attackers, investigate incidents, and answer support / forensic questions.

Legal basis: Article 6(1)(f) GDPR - legitimate interest in operating a secure service.

Retention: server logs are kept for 14 days, then deleted. The admin audit log is kept while the account that authored each action exists.

What:anonymised IP, device + browser type, OS, screen size, language, page paths, event names (e.g. “view_player_profile”), an analytics identifier stored in the _ga cookie. Google Analytics property G-1LDTGVT6YH, with IP anonymisation on and data-retention set to 2 months.

Why: to understand which features are useful and where the site is slow.

Legal basis: Article 6(1)(a) GDPR - consent - in the EU, EEA, UK, Switzerland and Brazil. No analytics or advertising cookies are set until you accept them in the cookie banner. In other regions we rely on Article 6(1)(f) legitimate interest, and you can opt out at any time.

Retention: 2 months on the Google Analytics property. The _ga cookie has a 2-year lifetime; you can clear it via your browser settings or via our Cookie preferences page.

We honour the Global Privacy Control browser signal - if your browser sends it, we treat it as an opt-out from advertising cookies regardless of any prior banner choice.

What: when a client- or server-side error occurs, Sentry captures a stack trace, the URL that triggered the error, the IP, the User-Agent, and - for signed-in users - your Valking user ID and email. Source-map debug data is uploaded so we can read the stack trace.

Why: to find and fix bugs.

Legal basis: Article 6(1)(f) GDPR - legitimate interest in a working product.

Retention: Sentry retains events under its own retention policy (90 days by default on the plan we use).

What: a defined subset of the web- purchase data described in 4.6 - specifically the issued invoice (with the line items, applicable tax, currency, total, invoice number and issue date), the billing address printed on the invoice, the Stripe charge identifier, the Valking user ID (if the buyer had an account at purchase time), and the timestamps of the charge and any refund or chargeback events.

Why: commercial-law (§ 257 HGB) and tax-law (§ 147 AO) record-keeping. We need to be able to produce a complete trail of every taxable transaction in the event of an audit or a refund dispute.

Legal basis: Article 6(1)(c) GDPR - compliance with a legal obligation to which the controller is subject (the German Commercial and Tax Codes).

Retention: ten full calendar years starting from the end of the year in which the invoice was issued (§ 147(3) AO). After that period the records are deleted.

Effect on your right to erasure: when you delete your Valking account, every other piece of personal data we hold is removed (Section 9 of this Policy). The archival subset above is instead transitioned to a restricted-access tax- archive store where it stays only for the statutory period and is used exclusively for compliance with that obligation. This restriction is permitted by Article 17(3)(b) GDPR.

What:at the moment you click the binding “Zahlungspflichtig bestellen” button in our web checkout, we write an immutable audit row containing: the package and product identifier being bought, the headline price the checkout displayed, the currency, the UI locale at the time, the country we detected, the version stamp of the Terms of Service you accepted, the value of each consent checkbox you ticked (AGB acceptance, § 356 paragraph 5 BGB waiver of the right of withdrawal where applicable), a verbatim snippet of the disclosure copy you were shown, the IP address that submitted the consent, your User-Agent, your Valking user ID, the RevenueCat App User ID, and the timestamp. A second timestamp is added later when the RevenueCat webhook correlates the consent row to the actual completed purchase event.

Why:the German Civil Code requires us to be able to prove WHICH terms you agreed to and WHETHER you exercised the § 356 paragraph 5 BGB waiver before commencement of the digital service. Without this row we could not defend a Widerruf dispute or demonstrate compliance with § 312f BGB (durable-medium confirmation duty) and § 312j BGB (Buttonlösung / Bestätigungsseite). The copy snapshot also lets us reconstruct, years later, the exact text a buyer was looking at when they ticked the box.

Legal basis: Article 6(1)(c) GDPR for the parts driven by statutory obligations (§§ 312f, 312j, 356 BGB), and Article 6(1)(f) GDPR for the legal-defense fallback (legitimate interest in being able to defend a contested cancellation / refund claim in court or before a consumer authority).

Retention: rows that never correlate to a completed purchase (the consumer started the checkout but never paid) are deleted automatically 30 days after they were written. Rows that did correlate to a contract are retained as evidence for the lifetime of the subscription plus the statutory limitation period for consumer claims (up to three years from the year-end after the contract ended - §§ 195, 199 BGB); after that they are deleted unless an actual dispute requires longer retention. The retention link to the tax-archival data in 4.12 is maintained so that consent state and the corresponding invoice can be cross-referenced for the full ten-year archival window where the consumer completed the purchase.

Effect on your right to erasure: like the tax-archival subset in 4.12, the consent-evidence rows for completed purchases are not deleted on account-deletion request - they are moved into restricted access and used solely to defend against potential future claims. Abandoned (uncorrelated) rows are deleted on the normal cycle regardless of any account-deletion request.

What: the contact address shown on the Imprint page is gated behind a single anti-bot challenge served by Cloudflare Turnstile. To decide whether you are a human, Turnstile collects a set of passive device and browser signals (User-Agent, IP-derived geolocation hints, browser feature flags, timing signals, an opaque interactivity fingerprint). When the challenge passes, your browser receives a short-lived token that our backend verifies with Cloudflare before revealing the address; the token is destroyed immediately after verification.

Why: to keep the operator email address out of automated email-harvester crawlers without forcing every visitor to solve a visible CAPTCHA.

Legal basis:Article 6(1)(f) GDPR - legitimate interest in protecting the contact address from spam-harvesting and in reducing the burden of malicious email volume on the contact inbox. The processing is also necessary to access and store information on the visitor’s device under § 25 TDDDG; we rely on the strictly-necessary exception (§ 25(2) Nr. 2 TDDDG) because the access is required to provide a service the visitor has explicitly requested by clicking “Reveal contact”.

Retention:the token is stateless and lives in memory only; we do not store it. Any Cloudflare-side logs of the challenge follow Cloudflare’s own retention policy.

No-JavaScript fallback:visitors who cannot run JavaScript (and therefore cannot solve the Turnstile challenge) see a static fallback address on the same page. The DDG §5 requirement of an “unmittelbar erreichbar” contact channel is satisfied via that fallback even when Turnstile is unavailable.