Privacy Policy (GDPR)

Last updated: August 20, 2026

1. Controller

The controller details are provided in the Impressum.
Email: toyornot.com@gmail.com
Phone (optional): +4915567138522

2. Data We Process

• Uploaded image files that you submit for rating, lesson evaluation, model improvement, model training and evaluation, prompt development, quality review, or promotional examples.
• Rating cache records in rating_scores, including timestamps, request id, image-hash cache identity, score data such as score_1_10, and rating result metadata.
• Successful rating request-event records in rating_events, including timestamps, request id, total score, display score, judgement engine id, rating schema version, bounded judgeability and criteria-availability fields, a guest or signed-in owner, and a local activity day key.
• Service-role-only criteria telemetry records, including bounded model, phase, latency, token, cost, retry, and synthesis metadata used to monitor Plus criteria generation. These records do not store raw images, prompts, filenames, critique text, evidence text, emails, or arbitrary provider output.
• Lesson progress records in lesson_progress, including course id, node id, pass state, score bucket data, image-quality issue code, attempt count, timestamps, and a guest or signed-in owner. Raw lesson images, filenames, model prompts, and free-text user content are not stored in these records.
• Lesson scan-event records in lesson_scan_events, including request id, course id, node id, node type, account tier, local activity day key, pass state, score bucket, image-quality issue code, and a guest or signed-in owner.
• Server-side rating history records for guest browsers and signed-in accounts, including the timestamp, request id, and rating result returned to you. For the first seven days after a rating, the record can also reference a stored judged-image copy and a smaller thumbnail derivative. Guest records are linked to the necessary browser guest identifier and may be reassigned to the signed-in account when the app completes guest-history merge after sign-in.
• Legacy public leaderboard metadata from entries posted before the feature was retired, including a reference to the rating history entry, the display name chosen at posting time, a two-letter country code derived from the request's IP-based hosting-platform geolocation at posting time, a moderation visibility flag, and the post timestamp. These entries are no longer publicly served.
• Authenticated daily-entitlement and share-bonus records, including day key, usage counters, bonus status, share token, attempt status, completion method, landing path, referrer host, user-agent string, and related audit timestamps.
• Optional rating limit-reset reminder preference records for signed-in accounts, including enabled state, delivery hour, local time zone, UI locale, capped-day key, next scheduled reminder timestamp, and last-sent day key.
• Optional lesson limit reminder preference records for guest browsers and signed-in accounts, including enabled state, delivery hour, local time zone, UI locale, limited lesson day key, next scheduled reminder timestamp, and last-sent day key.
• Optional browser push-subscription records for rating and lesson reminders, including the push endpoint, cryptographic subscription keys, expiration time when provided by the browser, user-agent string, delivery success or failure timestamps, and disablement metadata. Reminder metadata does not store raw images, prompts, lesson uploads, filenames, feedback text, emails, or arbitrary payloads.
• TOYORNOT Plus billing records, including Stripe customer and subscription references, presentment currency, subscription status, amount, renewal-period end, cancellation state, and related audit timestamps.
• TOYORNOT Plus entitlement metadata in Supabase auth app metadata, including account tier, premium access source, promo expiry timestamp when applicable, and legacy preview expiry or grant timestamps if an older Plus preview remains in account metadata.
• Billing checkout-consent records, including legal-version identifiers, market profile, market country code, UI locale, checkbox acceptance states, Stripe Checkout session id, Stripe customer id, request id, and timestamp.
• Billing notice-event records, including purchase/cancellation notice type, delivery status, recipient email, subject, related subscription id, payload metadata, error details, and timestamps.
• Optional email lifecycle consent records, including your signed-in Google account email, opt-in status, consent source, UI locale, legal-version identifiers, request id, user-agent string, and consent/audit timestamps.
• Lifecycle email send records created when the optional email program sends you an email, including the email kind, subject, recipient address, delivery status, error details on failure, and timestamps.
• Creator Clips program records, including creator name, contact email, payout method, payout region, payout destination details, submitted social URL, accepted creator-terms version, review state, verified views, public and internal review notes, payout batch membership, payout amount, external payout reference when recorded, and related audit timestamps.
• Technical request metadata (for example IP address, user agent, timestamps, and best-effort hosting-platform geolocation headers such as country and time zone).
• Consent preferences stored in your browser (toyornot-consent-v1).
• A session-scoped pending email-consent marker stored in your browser (toyornot-email-lifecycle-consent-pending-v1) when you check the optional email box before Google sign-in. This marker does not contain your email address and is cleared after the consent record is submitted or rejected.
• A necessary pending scanner auth-resume marker stored in browser session storage (toyornot-pending-scanner-auth-resume-v1) when a scanner action needs to resume after Google sign-in, including the save-result flow. It contains only a version, rating request id, creation timestamp, and bounded source label; it does not contain the image, filename, prompt, critique, feedback, email address, or rating-result content.
• Guest daily judgement-limit state stored in your browser (toyornot-daily-judgement-cap-v1) to enforce the local guest usage cap.
• First-upload crop-guide state stored in your browser (toyornot-initial-crop-guide-seen-v1) to remember that the one-time crop instruction has already been shown.
• First-open lesson-guide state stored in your browser (toyornot-initial-lesson-intro-guide-seen-v1) to remember that the one-time Duolingo for Graffiti instruction has already been dismissed.
• Necessary account-display cache stored in your browser (toyornot-account-display-status-v1 and toyornot-authenticated-account-tier-v1), including only guest/free/premium display status, signed-in user id when applicable, and update timestamp, so the app can avoid briefly showing stale account-tier UI while server entitlements refresh.
• A necessary guest identifier stored in your browser (toyornot-guest-id-v1) so anonymous result flows, guest rating history, guest-only server features, guest-history merge after sign-in, and first-party retention-funnel measurement can recognize the same browser.
• Necessary loading-survey frequency state stored in your browser (toyornot-loading-survey-prompt-v2 and a session marker) so optional loading-screen survey sessions are capped without storing answers in browser profile state.
• Necessary contextual-feedback frequency and queue state stored in your browser (toyornot-contextual-feedback-state-v1, toyornot-contextual-feedback-queue-v1, and toyornot-feedback-prompt-session-v1). It stores a pseudonymous feedback key, bounded rating and active-day counters, prompt cooldown timestamps, queued moment/placement/allow-listed trigger-source codes, local de-duplication keys, an optional rating-attempt id, and the current session claim so feedback, install, and push-reminder requests stay rare and do not cascade. The bounded trigger-source code may be sent with a feedback event; the raw local de-duplication key is never sent to the feedback API. It also stores guest or a pseudonymous account_<16hex> marker derived locally from the signed-in user id to keep queued triggers, milestones, and moment history partitioned when accounts change. That local account marker is never sent to the feedback API; subject-scoped counters and history reset on a subject change while browser-wide interruption timestamps and the pseudonymous guest feedback key remain. Authenticated feedback requests do not transmit that guest key. This state does not store images, filenames, prompts, critiques, emails, payment details, payment/session tokens, or free-text answers.
• A necessary session-scoped retention identifier stored in your browser (toyornot-retention-session-key-v1) so scanner home-session pageviews, activation events, and later return sessions can be linked into the first-party retention report.
• A necessary bounded experiment exposure record stored in your browser (toyornot-experiment-exposures-v2) so first-party experiment exposures are not sent repeatedly and a later rating can be attributed to the measured rollout. It contains only the experiment and variant, guest subject, source request id, de-duplication key, and timestamp, and expires after eight days.
• A bounded next-practice follow-up marker stored in your browser (toyornot-next-practice-target-v1) so a later completed scan can be attributed to the visible result-overlay or signed-in home target. It contains only primitive account type, score bucket, submission type, target category/source, UI locale, source request id when available, clicked state, bounded placement, and created/expiry days; it stores no image, filename, prompt, critique, feedback, email address, account id, or exact score, and expires after eight days.
• Necessary first-party retention-funnel records in the application database, including scanner session/pageview cohorts, activation stages, return-session timestamps, referrer host, UI locale, visitor country, visitor type, and submission type when available.
• Optional loading-survey records in loading_survey_responses, including survey key, question key, question position, bounded answer key, rating attempt id, guest or signed-in owner, account tier, usage mode, submission type, image source label, route, UI locale, visitor country/time-zone labels, release key, and timestamp. These records do not include raw uploads, prompts, filenames, free-text feedback, emails, or profile-level survey traits.
• Optional contextual-feedback records in contextual_feedback_events, including a prompt id, survey version, view/answer/dismiss event type, bounded moment, question, trigger-source code, answer or dismissal reason, the complete displayed answer order, placement, route, UI locale, release key, optional rating-attempt id, timestamp, account tier/auth mode, and either a pseudonymous browser feedback key or signed-in account owner. The trigger source is one allow-listed code compatible with its moment, never the raw local de-duplication key or a payment/session token. Rows for one prompt retain one context and owner and can contain a view plus at most one answer-or-dismissal outcome. Internal reporting uses only eight bounded columns for per-day, per-moment, answer, dismissal, question, placement, and trigger-source aggregates without returning prompt, owner, rating-attempt, or other identifiers. These records contain no written answer, image, filename, prompt, critique, email, payment detail, token, or arbitrary metadata.
• Optional site-feedback records in site_feedback_submissions, including sentiment, selected reason where provided, an optional comment of up to 240 characters, route, UI locale, bounded rating/session counts, release key, pseudonymous feedback key, signed-in account owner where available, and timestamp. Do not include sensitive personal or payment information in a feedback comment.
• Necessary first-party experiment records in analytics_experiment_events, including experiment key, variant key, exposure or outcome event name, stable visitor or user subject key, bounded metadata, UI locale, visitor country, route/source labels, timestamp, and request id where available. These records do not include raw uploads, prompts, free-text feedback, emails, or unbounded payloads.
• Optional analytics events, anonymous browser analytics identifiers, pseudonymous signed-in user or feedback identifiers on consented server events, bounded Resend email attribution markers, server-side rating, contextual-feedback, site-feedback, and AI-provider diagnostic events, client-side exception diagnostics, and session replay data for PostHog only in verified production and only if you consent to analytics and sponsored content.
• Optional sponsored-content selection, viewable-impression, and click-through data for consent-gated Amazon affiliate offers in the waiting overlay, including assignment metadata and hashed anonymous session identifiers used to optimize which offers are shown.

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

• Provide the rating and lesson features, including score caching, rating history, guest-history merge after sign-in, lesson progress, quota enforcement, streak tracking, and secure service operation: Art. 6(1)(b) GDPR (contract/performance).
• Improve, evaluate, train, and calibrate rating and lesson models, prompts, scoring guidance, quality benchmarks, and safety/abuse controls using uploaded content and related bounded metadata: Art. 6(1)(b) GDPR (contract/performance) and Art. 6(1)(f) GDPR (legitimate interests).
• Create promotional, educational, product-demo, documentation, and marketing examples from uploaded images, generated results, share-card-style outputs, and cropped or resized variants where permitted by the Terms: Art. 6(1)(f) GDPR (legitimate interests) and, where legally required, Art. 6(1)(a) GDPR (consent).
• Provide and administer TOYORNOT Plus subscriptions, entitlement checks, legacy preview access where still active, and billing support: Art. 6(1)(b) GDPR (contract/performance).
• Provide and administer the Creator Clips program, including creator profile setup, submission review, fraud prevention, verified-view recording, manual payout administration, and payout-record support: Art. 6(1)(b) GDPR (contract/performance) and Art. 6(1)(f) GDPR (legitimate interests).
• Provide optional sharing and referral features: Art. 6(1)(b) GDPR (contract/performance) and Art. 6(1)(f) GDPR (legitimate interests).
• Retain and manage deletion, moderation, legal, and abuse-prevention obligations for legacy public leaderboard metadata: Art. 6(1)(b) GDPR (contract/performance for prior publication requests) and Art. 6(1)(f) GDPR (legitimate interests for abuse prevention and moderation).
• Provide the optional browser reminders that tell signed-in free users when their next daily rating window is available, and tell signed-in free users or lesson guests when free lesson points are available again: Art. 6(1)(b) GDPR (contract/performance for the requested reminder feature).
• Record and use explicit opt-in consent for optional lifecycle emails such as practice reminders, onboarding help, product updates, and retention messages: Art. 6(1)(a) GDPR (consent).
• Measure the first-party scanner activation and return funnel needed to operate and evaluate the product safely: Art. 6(1)(f) GDPR (legitimate interests).
• Understand high-level user intent, Plus benefit demand, and rating-experience friction through optional bounded loading survey answers: Art. 6(1)(f) GDPR (legitimate interests).
• Understand bounded reasons behind completed or abandoned product moments through optional contextual feedback and site feedback, and use that information to improve the service: Art. 6(1)(f) GDPR (legitimate interests).
• Measure first-party product experiments and measured rollouts needed to decide whether to ship, iterate, or remove product changes safely: Art. 6(1)(f) GDPR (legitimate interests).
• Service stability and abuse prevention: Art. 6(1)(f) GDPR (legitimate interests).
• Optional PostHog analytics and sponsored content technologies: Art. 6(1)(a) GDPR (consent).
• Legal obligations (for example legal retention): Art. 6(1)(c) GDPR.

4. TOYORNOT Plus Billing and Stripe

If you buy TOYORNOT Plus, checkout and recurring billing are handled through Stripe. We process billing-status records and Stripe references so we can activate TOYORNOT Plus, restore billing state, handle cancellations, respond to payment issues, and show you the correct subscription status in the app. Full payment card details are collected and processed by Stripe and are not stored by us.

TOYORNOT Plus no longer offers new Plus previews. If an account still has legacy Plus preview metadata, we store bounded entitlement metadata such as the preview source, grant timestamp, and expiry timestamp only to honor or expire that existing access, show the correct account status, resolve support issues, and maintain operational records.

Before checkout begins, we record the legal-review acceptance data required for the TOYORNOT Plus purchase flow. We also keep billing-notice audit records so we can show whether a purchase confirmation, cancellation confirmation, or later pricing/terms notice was sent, skipped, or failed.

Where billing email delivery is configured, transactional billing emails are sent through Resend. These emails can include contract-summary information, cancellation confirmation details, and support contact information. The billing support address currently used by the site is toyornot.com@gmail.com.

5. Optional Browser Reminders

If you choose an optional browser reminder, we store the reminder preference and one or more browser push-subscription records so we can deliver the reminder on the next local day after you hit the relevant free limit. Rating limit-reset reminders are account-bound for signed-in free accounts. Lesson limit reminders are stored separately and can be enabled independently for signed-in free accounts or for the current guest browser. Browser notification permission is requested by your browser and can be revoked there at any time. Reminder delivery is skipped when your refreshed quota has already been used, when your account has TOYORNOT Plus access, when reminders are disabled, or when no active push subscription remains for the reminder owner.

6. Optional Lifecycle Emails

If you check the optional email box before signing in with Google, we use the email address returned by your authenticated Google account to record email lifecycle consent. The consent record is separate from cookie analytics consent and from browser push-reminder preferences. While the email program is active, opted-in accounts can receive occasional lifecycle emails such as practice reminders after several days without rating activity, product updates, retention messages, and legacy time-sensitive Plus-preview reminders before an existing preview ends. These sends are limited by per-account eligibility rules and cooldowns. Every lifecycle email contains a per-account unsubscribe link and supports one-click unsubscribe headers, and we keep a per-email send log to suppress duplicate sends and document delivery. You can withdraw email consent for future processing at any time by using the unsubscribe link in any lifecycle email, or by contacting us at the privacy address below.

7. Optional Sharing

If you choose to use the optional sharing flow, you decide whether to post outside this site. We do not connect to your social-media account or post on your behalf.

8. Legacy Public Leaderboard Data

Public leaderboard posting has been retired. New posts are not accepted, and historic entries are no longer publicly served.

Historic metadata may remain linked to the underlying rating history entry until you delete that rating or clear your history, or until we remove it for moderation, legal, abuse-prevention, or data-maintenance reasons. Third parties may have viewed, cached, or copied content while the feature was public.

9. Third-Party Services and Transfers

This site may use third-party processors, including cloud hosting, Supabase for authentication and data storage, Stripe for checkout, payment processing, recurring billing, and billing portal management, Resend for transactional billing-email delivery and opt-in lifecycle email delivery when configured, optional analytics infrastructure such as PostHog when consented, Amazon when you intentionally open an optional Amazon affiliate link for your visitor market, and model/API providers for rating, lesson evaluation, model improvement, prompt development, model training, and model evaluation. The in-app Amazon sponsored cards are static and do not load Amazon scripts before click-through. If personal data is transferred outside the EEA, we rely on appropriate safeguards such as EU Standard Contractual Clauses where required.

10. Retention

• Uploaded images used only for live scoring or lesson evaluation without a history owner and not selected for service improvement, model training/evaluation, prompt development, quality review, or promotional examples: retained only as long as needed to generate the requested rating or lesson result.
• Uploaded images, derived crops/resized variants, generated results, and share-card-style outputs used for service improvement, model training/evaluation, prompt development, quality review, or promotional examples: retained as long as needed for those purposes, operational auditability, takedown handling, legal defense, and product-quality records.
• Cache rows in rating_scores: retained as long as needed to support duplicate-image reuse, benchmark calculations, and related operational records.
• Owned rating_events rows with guest or user ownership and local activity day keys: retained as long as needed to operate streaks, benchmarks, abuse prevention, stats, and related operational records.
• Lesson progress and lesson scan-event records: retained as long as needed to operate lesson progress, daily lesson scan quotas, abuse prevention, product measurement, and related operational records.
• Rating-history judged-image copies and their thumbnail derivatives: available in history for seven days after the rating. When that availability window expires, the app stops returning the image paths and both stored variants are scheduled for deletion on the next daily cleanup run. Deleting the history entry, clearing history, or completing a valid erasure request removes both variants earlier where they still exist.
• Guest rating history score and result metadata: limited to the newest 25 entries for the browser guest identifier, then potentially reassigned to the signed-in account when guest-history merge completes after sign-in, or removed earlier for a valid privacy request or operational/legal reason.
• Signed-in rating history score and result metadata: kept until you delete an entry, clear your history, request erasure where applicable, or we remove it for an operational or legal reason. Signed-in history metadata is not automatically limited to 25 entries.
• Legacy public leaderboard metadata: no longer publicly served; kept until you delete the underlying rating from your history or clear your history, or until we remove it for moderation, legal, abuse-prevention, or data-maintenance reasons.
• Authenticated entitlement and share-bonus records: retained as long as needed to enforce limits, prevent abuse, and maintain operational records.
• Social proof screenshots and verification records: retained as long as needed to operate the bonus campaign, prevent duplicate claims or abuse, and maintain operational records.
• Rating and lesson reminder preference and push-subscription records: retained as long as needed to operate the reminder feature, suppress duplicate reminder sends, remove expired browser subscriptions, and maintain operational records.
• TOYORNOT Plus billing records: retained as long as needed to administer the subscription, comply with accounting or tax obligations, resolve disputes, prevent abuse, and maintain operational records.
• Legacy TOYORNOT Plus preview entitlement metadata: retained as long as needed to honor or expire existing access, resolve support issues, prevent abuse, and maintain operational records.
• Billing checkout-consent records and billing notice-event logs: retained as long as needed to document contract formation, support consumer-law workflows, respond to disputes, and comply with accounting, tax, or legal-retention obligations.
• Email lifecycle preference and consent-event records: retained as long as needed to honor your opt-in or withdrawal, prove consent, suppress unsubscribed users, handle support/privacy requests, and maintain legal or operational records.
• Lifecycle email send logs: retained as long as needed to suppress duplicate sends, document delivery and failures, handle support/privacy requests, and maintain legal or operational records.
• Creator Clips profile, submission, review, and payout records: retained as long as needed to administer the creator program, verify approved posts and payout eligibility, prevent duplicate or abusive claims, resolve disputes, document manual payment operations, and comply with accounting, tax, or legal-retention obligations.
• Server/security logs: retained only as long as needed for service security and operational monitoring.
• Analytics consent declaration in browser local storage and a first-party cookie: used for up to 365 days from your latest choice, until changed by you, or until removed from browser storage. Missing, expired, malformed, or materially future-dated declarations are treated as no analytics consent.
• First-upload crop-guide browser state: stored until you clear browser storage.
• First-open lesson-guide browser state: stored until you clear browser storage.
• Guest identifier in browser storage: stored until you clear browser storage or the identifier is rotated by the application.
• Account-display cache in browser storage: stored until it is updated by refreshed account entitlements or billing status, or until you clear browser storage.
• Pending email-consent marker in browser session storage: stored until the consent record is submitted or rejected, or until the current browser tab or session ends.
• Pending scanner auth-resume marker in browser session storage: active for up to 30 minutes and cleared after a successful, failed, invalid, or expired callback, when replaced by a newer request, when browser session storage is cleared, or when the tab/session ends.
• Retention session identifier in browser storage: stored only until the current browser tab or session ends.
• Experiment exposure record in browser local storage: ignored after eight days and removed on the next application access, or earlier when you clear browser storage.
• Contextual-feedback trigger queue: active for up to seven days, or removed earlier when evaluated, answered, dismissed, expired, or browser storage is cleared. Frequency state and the pseudonymous feedback key remain until replaced by the application or browser storage is cleared; recorded cooldown timestamps are used for up to 180 days.
• Resend email attribution marker in browser session storage: stored only until the current browser tab or session ends, and used only when optional analytics consent is active.
• First-party retention-funnel cohort and event records: retained as long as needed to operate internal activation/return reporting, investigate traffic-quality changes, and maintain related operational records.
• First-party experiment event records: retained as long as needed to operate internal experiment reporting, investigate data quality or sample-ratio issues, document product decisions, and maintain related operational records.
• First-party contextual-feedback records: retained for no more than 180 days, with scheduled deletion of older records, or removed earlier for a valid erasure request where applicable.
• First-party site-feedback records: retained as long as needed to review product friction and value, respond to privacy requests, investigate data quality, document product decisions, and maintain related operational or legal records.
• Criteria telemetry records: retained as long as needed to monitor model reliability, cost, latency, retry behavior, quality regressions, and Plus criteria fallback behavior.
• Optional anonymous analytics identifiers in browser storage: retained until consent is withdrawn or browser storage is cleared. Withdrawal disables browser PostHog capture and resets the optional browser person, device, visitor, and session identity; enabling analytics later creates new browser visitor and session identities.
• Optional consented PostHog event records: retained according to the provider-defined retention period. Withdrawal stops future optional capture until you consent again, but does not itself delete previously captured events. Consented server events may use a stable pseudonymous signed-in user id or feedback user key, so server events captured after later consent can be associated with the same pseudonymous identifier.

11. Your Rights

Under GDPR, you may have rights to access, rectification, erasure, restriction, portability, and objection, plus the right to withdraw consent at any time for future processing. You also have the right to lodge a complaint with a supervisory authority, especially in your EU member state of residence. Signed-in users can delete individual rating-history entries or clear rating history in My Hub. Those controls delete the score/result entry and any judged-image and thumbnail variants that have not already expired. Contact the privacy address below for broader account-erasure requests or if the in-product controls are unavailable.

12. Contact for Privacy Requests

Send privacy requests to: toyornot.com@gmail.com

This document is a practical template and does not replace legal advice.