Full scan purchases (October 2, 2026)

Coins and recurring free coin delivery have been retired. Historical grant, expiry, reservation, email-delivery and purchased-balance records remain subject to their existing retention and account-deletion rules. We retain a ledger entry for any one-time conversion of remaining purchased balances into whole Full scans. This does not create an advertising or email subscription.

When you choose a Full scan purchase, we process your account ID, Stripe purchase references, accepted terms version, scan transactions, image fingerprints and completed scan results to fulfil the contract and prevent duplicate charges. We do not send your images, critiques or prompts to Stripe. Refunds and disputes adjust your purchased access.

Where a purchase follows a recorded first-party offer exposure, we attach its pseudonymous visitor reference to Stripe payment metadata to count confirmed purchases against that offer. This reference contains no image, critique, email or upload name. This measurement follows the first-party product measurement rules below; optional PostHog tracking requires analytics consent.

When you open the scan offers, sign in or pay with an image selected, the prepared image, surface and feedback language are temporarily saved in this browser's IndexedDB so you can return to it. Buying a Full scan does not start it automatically. No image is required to buy a scan. The copy is recoverable for 30 minutes, deleted after a successful scan, or deleted the next time an expired copy is encountered. Clearing site data removes it sooner. This storage supports the purchase you requested and is separate from optional analytics.

Paid result text is also held for purchase recovery; deleting the associated history result removes that recovery copy. Account deletion removes the app's credit wallet, scan copies and ledger. Stripe may separately retain transaction records under the billing retention rules below. Optional PostHog tracking remains consent-gated; no images or free-text critiques are included in purchase analytics. See the purchase terms.

Privacy Policy (GDPR)

Last updated: October 15, 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, 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.
• Legacy lesson progress records from the retired interactive lessons feature 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.
• Legacy lesson scan-event records from the retired interactive lessons feature 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.
• Legacy 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 reminders and legacy records from retired 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.
• Legacy 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.
• A necessary guest-scan completion flag (toyornot-guest-scan-completed-v1) to remember that your first guest scan completed. It contains only a yes/no value, without an image, account identifier, or analytics data.
• 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.
• Legacy 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.
• Loading-survey frequency state stored in your browser (toyornot-loading-survey-prompt-v2 and a session marker) so optional loading-screen questions appear at most once per session and three times per seven days, with at least 24 hours between survey appearances. It stores timestamps and question display counts, not your answers. The shared feedback state also stores a bounded last-prompt source to preserve other feedback cooldowns.
• 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, stable question position, fixed-choice answer, rating attempt id, guest or signed-in owner, account tier, usage mode, submission type, image source label, route, UI locale, inferred visitor country/time-zone labels, release key, and timestamp. Questions may ask your age range (never birth date or exact age), country of residence, graffiti experience, usual medium, discovery source, and product needs. You can skip any question; age and residence also offer “prefer not to say”. Submitted answers and declines are remembered for your account or this browser’s guest identifier so the same question is not asked again. They are voluntary research data and do not affect ratings, entitlements, prices, advertising, or email consent. We return only completed question names to your browser, not saved demographic answers. Records contain no raw uploads, prompts, filenames, free-text feedback, or emails, and we do not copy answers into account profile 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.
• Legacy records from the retired affiliate offer optimizer may include offer-selection, viewable-impression, click-through, assignment, and hashed anonymous session data. The application no longer collects these records or displays affiliate offers.

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

• Provide the rating features, including score caching, rating history, guest-history merge after sign-in, quota enforcement, streak tracking, and secure service operation: Art. 6(1)(b) GDPR (contract/performance).
• Improve, evaluate, train, and calibrate rating 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).
• Maintain legacy Creator Clips records, including review of existing submissions, fraud prevention, verified-view recording, outstanding 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 requested practice reminders and, in legacy daily-allowance mode only, daily rating-window reminders: 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, broad audience age ranges and countries, graffiti experience, discovery sources, product demand, and rating-experience friction through voluntary fixed-choice loading survey answers, and remember completed questions: Art. 6(1)(f) GDPR (legitimate interests). Every question is optional and the rating continues without an answer. Age-range and self-reported residence answers are kept in first-party research records and excluded from optional PostHog answer events and diagnostics; the survey controls are masked from replay and excluded from automatic capture.
• 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 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.

To reduce waiting, we may load Stripe's payment components while a Full scan offer is visible after a result. For eligible signed-in visitors, we also prepare an unpaid checkout using the account reference and receipt email. This preparation also happens when you open the purchase page for the selected offer. It does not accept terms, make a payment, or send your image or feedback to Stripe. We record the required terms version and acceptance when you confirm payment for a Full scan or Plus, before asking Stripe to process it. 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 reminders have been retired and no longer send notifications. Legacy lesson preferences and subscription records remain stored separately until deleted under the retention policy. 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

The optional email box starts unchecked before Google sign-in. Email opt-in is not required to scan or buy. The purchase sign-in flow does not ask for marketing email consent. If you choose to check it, we use the email address returned by your authenticated Google account to record your email preference. 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. Free coin-drop emails have ended, including queued deliveries. Existing email preferences are not automatically expanded or re-enrolled. 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

Requesting a scan sends the prepared image, selected feedback language, and relevant scan information to OpenRouter and its AI model and hosting providers for automated analysis, including a retry when needed. Selecting or cropping an image alone does not send it to these AI providers. This processing is needed to perform the scan you request (Art. 6(1)(b) GDPR); accepting the Terms is not blanket consent to unrelated uses of personal data. Upload only content you are entitled to submit for this analysis, and avoid including people or personal information that is not needed to assess the graffiti.

Basic scans send the prepared graffiti image and selected feedback language through OpenRouter to Google's Gemini Flash Lite model. Full and Plus scans use OpenAI's GPT-6 Sol model to decide eligibility, assign the score and four-word verdict, and produce detailed feedback in one assessment. The public rate-share API uses the same Sol flow in English. Eligible upstream hosting providers, including Microsoft Azure for the OpenAI models, process these requests. We require routing to endpoints designated by OpenRouter as having zero data retention and disable provider data collection for these rating requests. This does not change the site's own history, cache, or other retention practices described below; providers may use transient in-memory processing, and OpenRouter retains operational request metadata.

Live scan routing does not authorize the AI providers to independently publish your image or use the request to train their models. OpenRouter does not store image, prompt, or response content unless input/output logging or sharing is enabled; we require those options to remain disabled for the service account. Zero-data-retention routing applies to eligible inference endpoints, not to ToyOrNot's history and cache or OpenRouter's operational request metadata. It also does not guarantee processing within the EEA. The recipient categories and safeguards in this section apply when the underlying provider changes; an unrelated purpose or materially different data practice requires the appropriate notice and lawful basis before it starts.

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, and model/API providers for rating, model improvement, prompt development, model training, and model evaluation. 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 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 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.
• Legacy lesson progress and lesson scan-event records: no new records are collected by the retired feature. Existing records remain in the application database pending retention cleanup or a valid erasure request where applicable.
• 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 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. Legacy lesson reminder records are no longer used for delivery and remain pending retention cleanup or a valid erasure request where applicable.
• 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.
• Historical free coin email delivery records (no new deliveries): account id, drop and expiry timestamps, lease state and delivery time; the exact recipient and email payload are temporarily stored for safe retries and cleared after delivery or skipping. Drop delivery records are deleted after 30 days by the reminder cron and on account deletion. Purchased balances are stored separately and are never reset by free drops.
• 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.
• Legacy Creator Clips profile, submission, review, and payout records: retained as long as needed to settle existing obligations, 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.
• Legacy affiliate optimizer records: existing records remain until deleted from the application database or removed for a valid erasure request where applicable. Retiring the feature does not itself erase previously collected records.
• 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.
• Home-screen installation prompt state: local rating, session, display and dismissal counts and an installation timestamp prevent premature or repeated prompts. Stored until browser storage is cleared; the session marker lasts until the tab/session ends. Optional installation analytics are collected only with analytics consent.
• First-upload crop-guide browser state: stored until you clear browser storage.
• Guest-scan completion flag: stored until you clear browser storage.
• Legacy first-open lesson-guide browser state: no longer read or written by the application; remains 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.
• First-party loading-survey records, including age ranges, countries and declined answers: retained as long as needed for product research and remembering completed questions, subject to valid erasure or objection requests. You can contact the controller listed in this policy to request deletion. Clearing browser storage removes the guest identifier and frequency state, but does not itself delete submitted server records. Guest records are tied to the previous browser identifier; signed-in records remain tied to the account.
• 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 Your pieces. 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.