Picobello Privacy Policy

Version 1 · Release date: 13 October 2026

Picobello is a family chores and rewards app operated by Picobello Software UG (haftungsbeschränkt) ("Picobello", "we", "us"). A parent or guardian creates and manages the family account. Children use profiles created and authorized by that adult.

This policy explains the current app and its related cloud, website, authentication, notification, subscription, support, export and deletion services. It focuses on the EU General Data Protection Regulation ("GDPR"). Additional local rules may apply; section 10.7 adds information for people in the United States.

In short: we do not show third-party advertising, sell personal data, use product-analytics SDKs, track users across apps, use family data to train AI models, provide public child profiles, or allow children to contact strangers. A parent approves every child profile by email before a child can use it (section 10.3). We do process family and child data needed for accounts, household tasks, rewards, synchronization, security, parent-requested features, de-identified aggregate usage statistics to improve the app, and — only if a parent chooses it — de-identified statistics about how adults use the app.

1. Controller and contact

The controller is Picobello Software UG (haftungsbeschränkt), registered office Berlin, with the business address c/o The Base Berlin One, Pestalozzistraße 5-8, Apt. 216, 13187 Berlin, Germany.

The company is represented by its managing director, Felix Parey, and is registered in the commercial register of Amtsgericht Charlottenburg under HRB 291439 B.

Privacy and support email: support@picobelloapp.com

Phone: +49 160 93115625

Data Protection Officer: IITR Datenschutz GmbH, Dr. Sebastian Kraska, Marienplatz 2, 80331 München, Germany. Email: email@iitr.de, phone: +49 89 18917360. You can contact our Data Protection Officer with any question about the processing of your data or your rights.

2. Who uses Picobello

• Parents and guardians create adult accounts, configure the household, create and authorize child profiles, choose tasks and rewards, review activity, manage subscriptions and control connected sessions.
• Children use an authenticated child session or a shared family device to view and complete quests, earn and spend coins, use the family reward shop and view age-appropriate privacy information.
• Additional parents can join through the adult joining flow, either with their own sign-in (email, Sign in with Apple or Google) or, without one, by entering a co-parent code on their device. A parent who joined only by code has fewer rights than a parent with their own sign-in: they can be removed by a parent with their own sign-in and lose access if the last parent with their own sign-in deletes their account (section 9).

The child label is an app role, not a legal determination that a person is a minor. The role currently supports ages 4–18. For a person below the applicable digital-consent threshold, the parent or legal guardian provides the required authorization. At or above that threshold, the app can present a self-consent transition so the young person makes the privacy choices that belong to them, such as deleting their own profile, instead of a parent. A person recorded as 18, or otherwise legally an adult, receives the authority, notices, choices and rights that apply to an adult; guardian authorization is not relied on as that adult's consent.

Parents should use a nickname rather than a child's full legal name and should not enter medical, religious, location, behavioral or other sensitive information into names, support messages or household configurations.

3. Information we process

3.1 Parent account and authentication

Depending on the sign-in method, we process:

• email address, display name and selected avatar;
• Firebase Authentication user ID and account status;
• Sign in with Apple or Google account identifier and basic identity information supplied by that provider;
• email verification, sign-in and password-reset session information, including short-lived codes or link metadata;
• family ID, role, tutorial status and account timestamps; and
• authentication, App Check, rate-limit and security metadata.

Passwords are handled by Firebase Authentication. Picobello does not store a readable copy of a parent's password in its Firestore application records.

A parent can also sign in with a passkey. If a parent creates one, we store the passkey's public credential: the credential ID, the public key, a signature counter, the transport types, the parent's email address, the Firebase Authentication user ID, the device model (for example “iPhone15,4” or “Pixel 8”) and the times it was created and last used. The private key never leaves the parent's device or credential manager. We delete the stored passkey records when the parent's account is deleted. A short-lived sign-in challenge is created for each passkey registration or sign-in and removed by the daily cleanup (section 7).

On Android, Google sign-in runs through the device's Credential Manager and Google Play services, which hand Google's sign-in token for the chosen account to Firebase Authentication. Sign in with Apple is offered on iOS only; a parent who signed up with Apple reaches the same account on Android by email address.

3.2 Child profiles

For a child profile we process:

• an internal child and family identifier;
• the display name or nickname entered by the parent;
• a selected in-app avatar;
• an age band rather than an exact age: one of 4-6, 7-9, 10-12, 13, 14, 15 or 16-18. Only a parent or guardian can set or change it; a child cannot set or change their own age band. The band is synchronized and may be received by the same-family recipients described in section 3.6;
• child tutorial status;
• Firebase authentication and revocable session identifiers; and
• the guardian-authorization status associated with the profile, including whether a parent has approved it by email (section 10.3).

We keep a band rather than a year because the year is not something we need. The bands are deliberately coarse for younger children and exact from 13 upward: the age at which a young person makes their own privacy choices, instead of a guardian making them, varies by country between 13 and 16, so from 13 on the app has to be able to tell which side of the applicable threshold a profile sits on. Below 13 no threshold applies anywhere, so a three-year band is enough.

A child's age band is ordinary personal data in this app, not special-category data by itself. We do not try to infer a child's sexual orientation, health, religion or other sensitive characteristic from it.

3.3 Family configuration, quests and rewards

We process family membership and the choices needed to provide the service, including:

• selected areas, quests, reward-shop items, currency and subscription status;
• the country the parent confirms for the family and, for a US family, the state, which decide which local rules and features apply (for example the age at which a young person makes their own privacy choices);
• quest assignments, eligible child IDs, availability and completion state;
• assignment, expiry and cooldown timestamps;
• parent approvals or disallow decisions and related coin changes;
• custom family coin prices, timing and eligibility settings;
• coin balances, daily and total completion counts;
• purchased or redeemed reward items, quantities, status and timestamps; and
• a short activity feed containing quest or reward events, each with a timestamp; individual entries are automatically deleted after 7 days, leaving only the running completion counts listed above.

The app stores a parent-switch passcode verifier and salt when that shared-device feature is enabled on an iPad or an Android tablet. On Android the verifier stays on the tablet, encrypted with a key held in the Android Keystore. The four-digit passcode itself is not stored in readable form.

3.4 Limited personalization

During parent setup, the app filters the quest catalog and filters or preselects reward-shop items using the children's age bands and the parent's material/non-material reward preference. For a family with more than one child, an item can remain available when it matches at least one child. This calculation occurs in the app and is used only to help the parent configure the family. The parent makes the final selection.

This is limited profiling or personalization under data-protection law. It is not advertising and does not make a legal or similarly significant decision about a child. The resulting family selections are synchronized; a separate behavioral advertising profile is not created.

3.5 Pairing and connected sessions

An authenticated parent can create a six-digit child household code. The code:

• is valid for 10 minutes;
• may be used by more than one child device while it remains valid;
• lets a device presenting the valid code receive the active children's internal IDs, display names and avatars so the child can select the correct profile; and
• can create a revocable authenticated session for the selected child without a second approval tap on the parent's device, but only for a profile a parent has already approved by email (section 10.3).

The parent can see join activity, receives a join notification when enabled, and can revoke the grant or later revoke child sessions. A separate co-parent code is intended for one adult; it is valid for 10 minutes and is consumed after a successful adult join (section 2 describes what a parent who joined only by code can do).

For pairing and abuse prevention we process a grant ID, family and creator IDs, role, hashed challenge, claim/session identifiers, status, attempt counts and creation, expiry, use, last-seen or revocation timestamps. Infrastructure may receive the request IP address; rate-limit records use rotating or pseudonymous hashes rather than storing the raw address in the rate-limit document.

For each paired child device we record its device class and model identifier (for example “iPhone15,4” or, on Android, “Pixel 8”), whether it is a shared household tablet, and when it was last used, so a parent can tell paired devices apart and revoke them. A model identifier is shared by every unit of that model and does not identify a single device. We do not collect a child device's user-assigned name, serial number, advertising identifier, Apple vendor identifier, Android ID, precise location or time zone for pairing. Section 10.4 lists every device identifier and what it is used for.

3.6 What family members can receive

Our database rules and backend are designed to isolate one family's private data from every other family. Within an authenticated family:

• parents can administer family configuration and receive child profile, progress, activity, inventory, pairing and session information;
• a device presenting a valid but not-yet-consumed child code receives only the pairing roster described above;
• an authenticated child session receives only same-family profile identifiers, roles, family identifier, parent-entered display names and bundled avatar names for profile switching; sibling age bands, balances, activity totals and privacy choices are excluded; and
• child sessions can receive same-family assignment and configuration state needed by the quest and shop experience, while raw user records are self-only and detailed activity and inventory are restricted to the child or an authorized parent.

Child profile switching returns only identifiers, parent-entered nicknames and bundled avatars. Parent and child roster responses differ. Parents receive family information needed to manage the service; independent teenager rights and guardian-authority disputes require separate handling.

3.7 Notifications

If notifications are enabled, we process the device's Firebase installation ID and APNs or FCM push token, the authorized profile and session references, update time, language and notification preferences. A restricted installation record also retains previous profile bindings so that erasing a profile can retire its old shared-device identifier. Remote notifications use generic prompts or synchronization signals; personal details are retrieved through the authenticated app. The operating system may display notification text on the lock screen according to the device's settings.

Core functionality remains available without push notifications. Local reminders are stored on the device until delivered, cancelled or removed by the operating system.

3.8 Subscription information

For the subscription or trial currently required to activate a new family, we process the product and entitlement, a StoreKit app-account token, original transaction identifier, signed transaction during server verification, and active, expiry, revocation or transfer state. Apple processes payment-card and billing information; Picobello does not receive the full payment-card number.

On Android the subscription is bought through Google Play Billing. We process the product, base plan and offer, the Google Play purchase token and order ID, the same random family account token used on iOS (attached to the purchase so it can be matched to the family), and the active, expiry, acknowledgement, cancellation or replacement state. Our server confirms each purchase with Google Play and receives Google Play's real-time notifications when a subscription changes. Google processes payment and billing information; Picobello does not receive the full payment-card number.

On iOS the app also reads the country and currency of the App Store storefront, so it can show the right prices and suggest the family's currency.

To understand how the subscription performs, our server records each verified App Store notification (start, trial, renewal, cancellation, refund, billing retry) in daily counts, and keeps one record per subscription that follows its state across notifications: the product, the offer, the trial, renewal and cancellation state and the related dates. The record is identified by a one-way hash of Apple's original transaction identifier. It holds no name, email address, family or child identifier, but it is pseudonymous rather than anonymous: we can connect it to a family by recomputing the hash from the transaction identifier we hold for that family's subscription. We keep a record for 25 months after its last update while the subscription is active and for 30 days after it ends, and the daily counts for about 25 months. This applies to subscriptions bought through the App Store; Google Play purchases are not recorded this way. It is part of our legitimate interest in understanding and improving the service (section 4), and you can object to it at any time (section 9).

3.9 Aggregate usage statistics to improve the app

We use aggregate usage statistics to improve the app. Once a day a scheduled Cloud Function produces de-identified statistics from active child profiles: a population count, the proportion with a known age band, and counts in the broad bands 4–6, 7–9, 10–12, 13–15 and 16–18. Alongside each band's count we publish the total number of quests children in that band have completed, and that total divided by the band's size.

The function does not write child IDs, family IDs, exact-age rows or per-child activity rows. It reads one child's age and that child's quest total together only in memory, for as long as it takes to add them to a band, and keeps no record pairing the two.

The whole publication is withheld until at least 10 active profiles exist, and any band with fewer than 10 profiles is omitted — its quest total with it, so an omitted band discloses nothing. Of the child statistics, only this thresholded aggregate reaches the separate administrator dashboard.

We keep the current aggregate and one snapshot per calendar week, so that we can see how the age mix of the app changes over time. Each weekly snapshot is thresholded independently by the same rules. Weekly snapshots are kept for 26 weeks and then deleted. We publish and store the values themselves, never the difference between two of them.

This server-side aggregation is kept separate from Firebase Analytics and from individual activity data. Picobello does not join Firestore ages to Firebase Analytics identifiers, and does not keep a dataset that combines an individual's age with their activity. The dashboard works only on the de-identified aggregate output and cannot read child or family documents directly.

A parent, and a young person of any age using their own profile, can object at any time to that profile being counted in these statistics. The objection is a switch in the app, takes effect on the next scheduled run, and removes the profile from the figures entirely rather than merely from a band. Objecting changes nothing else about the app.

Picobello does not ask a child, at any age, to consent to analytics about themselves, because we collect none on that basis. Everything in this section runs on our legitimate interest and is governed by the objection above.

Separately, a parent may choose whether Picobello receives de-identified statistics about how long setting up Picobello takes and how parents use the subscription screen. We ask on a screen of its own right after sign-in, before the subscription screen; the answer changes nothing else about the app. If chosen, the app sends one record when the parent finishes the setup, with the total time, the time spent on each setup step, the platform, the app version and the language. It also sends one record each time the subscription screen closes: where it was shown (during setup, after a subscription ended, or from Settings), which version of the screen, the time on screen, how the visit ended (for example a purchase, closing the screen, signing out or leaving the app), the plan selected, how often a purchase was started, cancelled or failed, how often the plan selection changed and, on Android, the back button was pressed, the platform, the app version and the language. To show whether parents come back, the app keeps a small counter on the device, and only after the parent agreed: the number of visits on that device, the date of the first and how the last one ended. Our server keeps only the visit number grouped as 1, 2, 3 or 4 or more, the days since the first visit grouped as the same day, 1, 2–3, 4–7 or 8 or more, and how the previous visit ended. Each record holds a random per-event identifier and the time. It holds no parent, child, family or device identifier, and no retained address, so two of these records cannot be connected to each other or to an account. Children's use of the app is never part of this. It remains consent-based, it is not required for the statistics above, and it can be switched off in the app at any time, which stops future collection and deletes the counter on that device.

3.10 Privacy requests, exports and deletion

We process the requester and child/family identifiers, request type, scope, status, correspondence and timestamps needed to handle access, portability, correction, restriction, objection, authorization withdrawal, session revocation and deletion requests received through the in-app privacy tools or our privacy-support channel. To fulfill a verified access or portability request, we may temporarily compile a concentrated copy of family data in a protected Cloud Storage object, an expiring download link or another protected electronic file.

An automatically compiled file does not necessarily include every short-lived security record. The privacy-support process therefore performs any supplementary, verified search required for a complete access response.

Deletion cascades include purchase receipts, pairing claims, approval evidence, exports, notification tokens and passkey records. Retries are idempotent.

How long deletion takes. We complete a deletion within one month of receiving the request. A deletion started in the app runs straight away and removes the data from our active systems within minutes. When a parent account or family is deleted, the support requests it sent are deleted too: closed ones at once, and an open one once we have been able to answer it, but no later than one month after the deletion. Copies outside our active systems have separate periods: database backups expire within 98 days, and Resend holds sent emails for 30 days (plus up to 7 days in its backups). Google's applicable Cloud and Firebase data-processing terms provide up to 180 days to remove deleted customer data from its systems, subject to legal exceptions; Firebase states the same outer period after deletion of an Authentication user or Firebase installation ID. Separate Google service and security metadata follows Google's own retention notice, which allows longer periods for some security, abuse and legal records. A restored backup applies every later deletion before anyone can use it. If you ask for deletion by email, we reply to that email once the deletion is done and then delete the correspondence by the same deadline.

3.11 Local storage and operational data

The iOS app keeps SwiftData records, pending synchronization operations, cached profile/family information and preferences for its requested features. Personal storage directories are marked as excluded from device backup. Authentication is managed by the platform and Firebase SDKs. Deleting a profile or account, or withdrawing parental approval, removes this local data from the device; signing a parent out does not erase the local copy of the family's data.

On Android the app keeps the Firestore SDK cache, a local family roster and pending-write database, and preferences. Device secrets use Android Keystore. The app disables backup and excludes personal files, databases and preferences from cloud backup and device transfer.

Google/Firebase and hosting infrastructure may process IP address, App Check data (Apple App Attest on iOS, Google Play Integrity on Android), app version, request time, error and security logs. We use this operational data for delivery, debugging, fraud prevention and security, not product measurement. Google separately describes some technical metadata as Firebase or Google Cloud Service Data and permits uses such as maintaining and improving its services under its Firebase privacy page and Cloud Privacy Notice. We have disabled the optional Firebase setting for using Firebase Service Data to improve non-Firebase Google services; this does not disable Google's other stated service-data uses.

On iOS the app asks Apple's App Store at most once a day for the current version number of Picobello, sending the app's bundle ID and the device's storefront country, so it can tell you when an update is available. This also happens in child mode.

Support emails may contain the sender's address, message and any information the sender chooses to include. Please do not send passwords, authentication tokens or unnecessary child information.

3.12 Transactional and support email

Picobello uses Resend (Plus Five Five, Inc., 2261 Market Street #5039, San Francisco, CA 94114, USA) to deliver requested sign-in codes, email-verification messages, password-reset messages, parental-approval requests and confirmations, support-email verification codes, support requests and minimal acknowledgements. Our support mailbox is hosted by Hostinger (Hostinger International Ltd, 61 Lordou Vironos str., 6023 Larnaca, Cyprus). Mailbox copies follow our support retention and deletion process, and when we delete a message we also empty it from the mailbox's Trash. Hostinger states that it may keep residual copies in its own backups for a limited period, which it does not publish, and that it deletes mailbox data 30 days after the service ends. Hostinger keeps delivery and access logs, which contain email and IP addresses, available to us for 30 days. Resend receives the sender and recipient email addresses, subject, message body, authentication code or link, delivery headers and status information. Support messages may also contain the topic, the requester's message, limited account or family references used to investigate the request, and any attachments the requester chooses to send.

These are transactional or user-requested support messages, not advertising. Picobello does not enable open or click tracking for them and does not use them to build an advertising profile. Resend processes this customer message data as a service provider/processor for Picobello. Resend may process its own account, billing and service-usage data as an independent controller under its privacy policy.

To reduce automated abuse of the public support form, Picobello uses Cloudflare Turnstile. The support page loads Cloudflare's Turnstile script, Google's Firebase sign-in script (gstatic.com) and, for the Sign in with Apple option, Apple's sign-in script when it opens, so Cloudflare, Google and Apple receive the visitor's IP address, browser information and the page address even before any support action. When a visitor starts one of the protected support actions, Cloudflare may process the visitor's IP address, browser and device signals, challenge result and related technical metadata. The resulting one-time token is sent to Picobello's backend for validation. Cloudflare also uses these signals as an independent controller to improve its bot detection. Turnstile is used for support-form security, not advertising or product analytics. See Cloudflare's privacy policy for the provider's information.

3.13 Age signals from Google Play and Apple

Some laws require an app to take account of the age information that an app store holds, for example Texas's app-store law for users in Texas. On Android, where Google Play provides it, the app asks Google Play for the age signal of the Google account on the device: whether the account holder is a verified adult or a supervised user, the account's age range, and, for a supervised user, an install identifier and the date a parent last approved a significant change in Google Play.

We use the signal only to give age-appropriate access and to meet those laws, for example to keep a supervised account out of parent functions or to act on a parent's withdrawal of approval in Google Play. Google Play's terms limit it to that purpose, and we do not use it for advertising, marketing, analytics or profiling. It is not added to a child's profile: a child's age band is still set only by a parent (section 3.2). Where we keep part of it on our servers, such as the install identifier Google Play uses to tell us that approval was withdrawn, we keep it with that device's session and delete it with the session.

On iOS, where Apple requires it, the app uses Apple's Declared Age Range service. When a parent signs up, the app asks whether the Apple Account holder is an adult; the answer is used on the device to decide whether to continue and is not stored by us. On a child's device the app asks for the account's age range and whether a parent has approved a significant app change. We keep only the outcome (for example allowed or approval required), the platform and the time with that device's session, and delete it with the session. We do not store the age range itself, it is not added to a child's profile, and we use it only to give age-appropriate access and to meet the app-store laws that apply to the user.

3.14 Withdrawal of consent in the App Store on iOS

The same laws let a parent withdraw, in the App Store, their consent to a child's use of an app, and require the app to act on it. Apple then tells us the App Store's transaction identifier for the Apple Account concerned: one value per Apple Account and app, the same on every device signed in with that account. So that we can recognize that account's devices, the child's app reports the identifier of its own Apple Account each time it opens, and we store only a one-way hash of it with that device's session. When Apple tells us that consent was withdrawn, we end every child session stored with the matching hash: the device returns to the pairing screen, and a parent has to connect it again. We use the hash for nothing else, it is not added to the child's profile, and it is deleted with the session (section 10.6).

3.15 Website visits

When you visit picobelloapp.com, our hosting provider, Google Firebase Hosting, processes your IP address, browser and device information, the page requested, the referring page and the time in its server logs, and keeps request IP addresses for a few months. We use them to deliver the website and keep it secure. The website sets no cookies. If you switch the language, the choice is stored in your browser's local storage (under the name “picobello-locale”) so that the site remembers it; it is not sent to us. The website contains no advertising or analytics scripts and loads no third-party fonts. The support page loads additional scripts, as described in section 3.12.

4. Why we process information and our GDPR bases

For the EEA and other jurisdictions that use the GDPR framework, the following bases are used. Where consent is required, we request it separately and provide a way to withdraw it:

• Parent account, subscription and requested family service: Article 6(1)(b), taking steps requested by the parent and performing the service contract.
• Child profile, quests, rewards, synchronization and limited personalization: Article 6(1)(f), our legitimate interest, and the parent's, in providing the family service the parent chose for their household, after giving particular weight to the child's interests and rights in a documented child-focused assessment. It covers only what the service needs to work: the parent-entered nickname and age band, the avatar the child picks from the set bundled with the app, quest and reward activity with its seven-day history, coin balances, the age-band filtering in section 3.4, and the identifiers in section 10.4. It never covers advertising, profiling beyond section 3.4, sharing for anyone else's purposes or public visibility. We do not rely on consent for this processing, so the national age limits for a child's own consent under Article 8 do not apply to it. The parent's email approval in section 10.3 is a safeguard, not the legal basis: nothing is collected from a child until a parent has decided. A parent, and a young person for their own profile, can object (section 9); a parent can also withdraw the approval, which ends the profile.
• Push notifications: for parents, Article 6(1)(b) as part of the requested service; for child profiles, Article 6(1)(f) as part of the family service above. The device's notification permission is the control: nothing is shown on a device where it is off, and it can be turned off at any time in the app or the device settings. Storing the push token is strictly necessary for the notifications the user asked for by turning them on.
• Requested authentication and support email: Article 6(1)(b) for account-related messages and requested support, or Article 6(1)(f) where necessary to protect the service and prevent abuse. Resend's processing is limited to delivering those messages on our instructions.
• Aggregate usage statistics to improve the app: Article 6(1)(f), our legitimate interest in understanding the broad age mix and activity level of the service we actually run, subject to the documented child-focused legitimate interest assessment. Safeguards include server-only aggregation, broad age bands, a minimum group size of 10 applied to every published figure, omission of smaller groups, no identifiers or individual activity in the published aggregate, no retained record pairing an individual's age with their activity, independently thresholded weekly snapshots kept for 26 weeks, values rather than differences, restricted administrator access, no Firebase Analytics linkage, and an in-app right to object that removes a profile from the statistics.
• Optional de-identified statistics about adult app use (setup time and subscription-screen visits): Article 6(1)(a). This first-party collection happens only after the parent chooses it, covers adult use only, carries no identifier that could connect one record to another or to an account, and can be switched off in the app at any time, which stops future collection. The same consent covers storing the visit counter on the device and reading it (in Germany § 25(1) TDDDG).
• Subscription statistics: Article 6(1)(f), our legitimate interest in understanding how the subscription performs and improving the service. The records are pseudonymous, hold no name, email address, family or child identifier and are kept for the periods in section 7; you can object (section 9).
• Age signals from Google Play (Android) and Apple (iOS): Article 6(1)(f), our legitimate interest in giving age-appropriate access and meeting the app-store age laws that apply to the user, after taking the child's interests and rights into account; the signal is used for nothing else.
• App Store consent withdrawal on iOS: Article 6(1)(f), our legitimate interest in acting on a parent's withdrawal of consent in the App Store, as the app-store laws that apply to the user require, after taking the child's interests and rights into account; the hash is used for nothing else.
• Website visits: Article 6(1)(f), our legitimate interest in delivering the website and keeping it secure; the language choice stored in your browser is strictly necessary for the feature you asked for.
• Authentication security, abuse prevention, service integrity and limited legal-defense records: Article 6(1)(f), our legitimate interests in keeping a child-focused family service secure, after taking the child's interests and rights into account.
• Privacy rights, regulatory, tax, accounting and breach duties: Article 6(1)(c), where a specific legal obligation applies.
• Protecting someone in an emergency: Article 6(1)(d), to protect the vital interests of a child or another person when we learn that their life or safety is in immediate danger.

We do not use child data for advertising, cross-app tracking, data-broker sharing or individual-level engagement analytics. We do not use solely automated decisions that create legal or similarly significant effects.

5. Providers and other recipients

We disclose only what is necessary to:

• Google/Firebase and Google Cloud: Authentication, Firestore, Cloud Functions, Cloud Storage, Cloud Messaging, App Check, Hosting and operational logs. Google Sign-In is used only when the parent selects it.
• Google Play: distribution of the Android app, Play Billing subscriptions and their server-side verification, Play Integrity app attestation, Play Age Signals, and Google Play services, which run Google sign-in through the Android Credential Manager.
• Apple: Sign in with Apple, App Attest, APNs, StoreKit, App Store distribution and subscription services, the App Store's notice when a parent withdraws consent (section 3.14), Declared Age Range (section 3.13) and the App Store version lookup (section 3.11).
• Cloudflare: Turnstile challenge and token validation for abuse prevention on the public support form. Cloudflare receives the technical signals needed to provide that security service and also uses them as an independent controller to improve its bot detection.
• Resend (Plus Five Five, Inc.): transactional and support-email delivery. Resend receives the email addresses, message content, codes or links, support text or attachments and delivery metadata needed to send those messages. Resend's current GDPR materials and Data Processing Agreement state that customer data is stored in the United States, that its Article 28 DPA includes EU Standard Contractual Clauses and the UK Addendum where applicable, and that it participates in the EU-U.S. Data Privacy Framework. The relevant safeguards can be requested from Picobello.
• Authorized family members: according to the family visibility described above.
• Authorized support, security, legal or professional advisers: only where appointed, needed and covered by approved confidentiality and access controls.
• Authorities or other recipients required by law: after validating the request where legally permitted.
• Emergency services and police: only when we learn that a child or another person is in immediate danger, and only the information they need to help.
• A successor operator: if the service is reorganized or transferred, subject to applicable notice, child-data and consent requirements.

We do not sell personal data or share it for cross-context behavioral advertising. The current app does not contain third-party advertising, Firebase Analytics, another product-analytics SDK, open chat or public child profiles.

No artificial-intelligence service receives personal data from Picobello, and we do not use parents' or children's information to train AI models. We use AI tools to help develop Picobello's software; they work with source code and test data and are not given access to the personal data of the people who use Picobello.

6. International processing

The configured Firestore production and development databases, and the content Storage bucket, are in Google's europe-west3 region (Frankfurt, Germany). General-purpose Cloud Functions and scheduled jobs run in europe-west1 (Belgium); resource-triggered functions that must be colocated with Firestore or Storage run in europe-west3. Google, Apple, Cloudflare and other providers may nevertheless process information in the United States or other countries. Resend stores customer data in the United States, including message content and delivery logs.

Where GDPR transfer restrictions apply, Picobello uses an applicable legal mechanism, such as an adequacy decision or the provider's data-processing terms incorporating Standard Contractual Clauses and supplementary safeguards. Resend states that its DPA covers U.S. transfers through the EU Standard Contractual Clauses and the UK Addendum, with the EU-U.S. Data Privacy Framework as an additional mechanism. Current provider and transfer evidence can be requested through the contact above.

For families in Switzerland, the Swiss Federal Act on Data Protection (FADP) also applies. Personal data is disclosed abroad to Germany and Belgium (Google's hosting regions), Cyprus (Hostinger's support mailbox) and the United States (Google, Cloudflare and Resend). Switzerland recognises Germany, Belgium and Cyprus as providing adequate protection. Transfers to Google and Cloudflare in the United States rely on their certification under the Swiss-U.S. Data Privacy Framework; transfers to Resend rely on Standard Contractual Clauses adapted for Swiss law in its Data Processing Agreement.

7. Retention

Current application-level retention is:

• parent, child, family, current assignment, balance and inventory records: while the relevant account/profile is active, followed by the applicable deletion process;
• a family that no parent or child has used for 12 months and that has no active Picobello subscription: while a subscription is active, the parent is paying for the family's data to be kept, so the 12 months start only once it has ended. Every parent with a sign-in email is warned 30 days in advance, and unless a parent or child opens Picobello before then, the family, every child profile and their data are deleted through the same process as a parent-requested family deletion. We keep the date the family was last used only for this, and delete it with the family;
• individual activity records: available for up to seven days. Server rules reject older records immediately; an hourly job removes the stored rows. Physical deletion can be delayed by a failed job and is monitored separately. Current balances, operational quest state, entitlements and purchase receipts have separate purposes and are not erased merely because the activity feed expires;
• aggregate analytics publication: the current thresholded aggregate is replaced by the next scheduled run, and one snapshot per calendar week is kept for 26 weeks; none of these records contains a child or family identifier, an exact-age row or a per-child activity row;
• optional adult event records (setup time and subscription-screen visits): 30 days; resulting daily aggregate records: approximately 25 months; the visit counter on the parent's device: until the statistics are switched off on that device or the app is removed;
• shop-purchase idempotency receipts: 30 days;
• child pairing code: valid for 10 minutes; grant and claim records are scheduled for deletion 15 minutes after expiry or consumption/revocation, with cleanup running every 15 minutes;
• pairing rate-limit records: the applicable 10-minute attempt window;
• email sign-in sessions: valid for 10 minutes; email-verification codes: valid for 15 minutes; support-form verification codes (10 minutes) and tokens (30 minutes); passkey challenges (5 minutes). The expired records are removed by a daily cleanup and can therefore remain for up to about a day, longer if the job is delayed. Abandoned anonymous bootstrap accounts become eligible for deletion after 24 hours and, because cleanup runs every 24 hours, can ordinarily remain for roughly 24–48 hours or longer if the job is delayed;
• transactional and support email content and delivery logs held by Resend: Resend currently publishes 30 days for its Free, Pro and Scale plans, with backups persisting for 7 days; Enterprise retention can be configured differently. The applicable Resend account plan and DPA control the exact provider period, and account termination is followed by deletion within the period stated in that DPA (currently up to 90 days);
• routine support requests: 90 days after resolution; attachments: 30 days after resolution. Open requests are reviewed for continued necessity. A documented legal obligation or dispute may require limited, separately reviewed retention. If the sender's parent account or family is deleted, closed requests are deleted at once and open requests are kept only until we have answered them, no longer than one month after the deletion; mailbox copies are deleted by the same date. Delivery-provider copies have their own periods (see Resend above);
• active child sessions: until revoked or the child/account is deleted; revoked session evidence: 90 days;
• rights-request records: unresolved requests remain until fulfilled or otherwise lawfully resolved. Closed records are eligible for deletion 365 days after closure. Applicable response deadlines are separate; GDPR requests use a calendar month, not a fixed 30-day approximation;
• export file and link: up to 72 hours; minimized terminal export-job receipt: a further 7 days;
• child/account deletion jobs, receipts and tombstones: 98 days (14 weeks), so that they outlast the last backup that can still contain the deleted data;
• guardian authorization, terms and notice receipts: 2,555 days (approximately seven years), minimized when a child is deleted;
• child profiles awaiting parental approval: the original 30-day deadline runs from the first approval request or profile creation, not a resend. The daily cleanup removes overdue profiles; retries may delay physical erasure;
• parental-approval records: 2,555 days after an approval is given, as evidence of it; a request that was never approved or was replaced by a newer email, 7 days after its link expired or was replaced;
• passkey records: while the parent account exists, deleted with it;
• App Store subscription statistics: the per-subscription record 25 months after its last update while the subscription is active and 30 days after it ends; the daily counts about 25 months;
• shared-device parent sign-in records (iPad and Android tablet): while the family exists; a revoked record stays until the family is deleted;
• a parent account that never created a family: deleted after 30 days without sign-in, together with its sign-in record and any passkey (we cannot end a Sign in with Apple authorization ourselves in this case; you can remove Picobello under Sign in with Apple in your Apple Account settings);
• admin audit records: 365 days; and
• push registrations: a 30-day inactivity limit, renewed while an eligible notification session uses the app. Switching profiles changes routing; final logout, loss of notification permission or profile erasure initiates retirement. Offline cleanup retries when connectivity returns. The server removes routing before requesting provider installation deletion and retains a minimal hashed receipt for 187 days. Firebase states that installation deletion can take 1–2 days to propagate and remaining copies up to 180 days to expire. Turning off one in-app notification category does not itself delete the installation. Push messages are sent without offline queue retention; users can refresh the app instead.

Provider logs, security investigations, support correspondence, subscription/accounting records and backups have separate, purpose-specific periods. Database backups are kept for 7 days (daily backups) or 98 days (weekly backups), and deletion records cover that window. A restore must reapply later deletion records before access is enabled.

8. Security

Measures in the current design include encrypted transport, Firebase Authentication, App Check with Apple App Attest or Google Play Integrity, deny-by-default database and storage rules, server-validated family membership and roles, short-lived pairing codes, rate limits, revocable sessions, restricted backend-only lifecycle collections, expiring exports and scheduled deletion.

No service is completely secure. We keep an incident runbook and a breach log. If a personal-data breach occurs, we investigate and document it, and we notify the supervisory authority and affected people where Articles 33 and 34 require it.

9. Rights and choices

Subject to applicable law, a parent, guardian or child may request:

• access to personal data and information about its use;
• a portable copy where applicable;
• correction of inaccurate information;
• deletion;
• restriction or objection;
• withdrawal of consent or guardian authorization; and
• revocation of connected child sessions.

Two of these are switches in the app rather than requests to us. A parent can turn the optional adult statistics (setup time and subscription-screen visits) on or off in Settings under Privacy Choices, and can object there, per child, to a profile being counted in the aggregate statistics. A young person using their own profile has the objection switch in their own privacy area, at any age. A switch is recorded immediately and needs no explanation or approval; the statistics reflect an objection from the next daily run.

A parent, and a young person for their own profile, can also object to the processing of a child profile itself, which relies on legitimate interest (section 4). A profile cannot work without that processing, so we handle such an objection by ending the profile's use and deleting it through the child-profile deletion process, apart from the limited records described in section 7. Objecting only to the aggregate statistics does not affect the profile.

You can also object to the subscription statistics (section 3.8) by emailing us; we then delete the record linked to your subscription.

To request access, a portable copy or export, correction, restriction, objection, authorization withdrawal or other privacy support, use the in-app privacy tools or email support@picobelloapp.com. Account deletion, child-profile deletion, connected-session revocation and notification choices remain available through the applicable parent-controlled app settings. The operating procedure requires proportionate identity and parental-authority checks and escalation of family-conflict or child-safety concerns instead of automatic disclosure to every family member. Where appropriate, copies containing child or family data are delivered through a protected download or protected electronic file rather than in the body of an ordinary email. A request sent by email may be processed by Resend during delivery.

If another parent with an independent Apple, Google or verified-email sign-in remains in the family, deleting one parent's account removes that parent and their access but does not delete family data still administered by the remaining credentialed parent or parents. Deleting the final independently credentialed parent account starts deletion of the family, every child profile and any parent profiles that only joined through an invite code. A child profile can also be deleted separately through the applicable parent-controlled flow.

You may complain to the data-protection authority in the EU/EEA country where you live or work or where you believe an infringement occurred. In Switzerland, you may contact the Federal Data Protection and Information Commissioner (FDPIC). Withdrawing consent does not affect processing already carried out lawfully, and limited records may remain where a legal obligation or appropriately documented legal claim requires them.

10. Children and additional markets

10.1 Child-facing information

A short English/German child-facing privacy explanation and privacy center are available in the app. Parents control creation of cloud child profiles below the applicable digital-consent threshold, while at or above that threshold the app hands the young person's own privacy choices to them. The child-facing explanation is supplemental; this full notice controls if the two versions differ.

10.2 What a child's profile holds

Every child profile is created by a parent using a nickname and age band. Once a parent has approved the profile, the child picks their own avatar from a fixed set bundled with the app; the child cannot upload or create an image. Children cannot supply contact details, photographs, location or free-text messages. Use of the app produces personal data, including operational identifiers, quests, balances and reward activity. Google/Firebase and other operational providers receive data needed to deliver the service. Firebase-free UI packages do not prevent those backend disclosures. Approval, purpose restrictions, access controls and the retention rules in this notice apply.

10.3 Parental approval before a child uses Picobello

A parent or guardian approves every new child profile by email before any profile data is collected from the child. This is the “email plus” method of parental consent that the US Children's Online Privacy Protection Rule allows (16 CFR 312.5(b)(2)(viii)). We use it for every child profile, in every country and in every age band, so that choosing an older band never skips it. It works like this:

• A new child profile starts as pending. A pending profile holds only what the parent entered: the nickname and the age band. No device can pair with it, switch into it or open a child session for it, so no profile data is collected from the child. A device that opens the pairing screen does receive a temporary anonymous sign-in from Firebase Authentication, with the usual IP address and App Check data; it is linked to no profile, and unused ones are deleted within about two days (section 7).
• We email a notice to the sign-in email address of the parent who created the profile. It names the children, says what we collect from them, how we use it and who sees it, and links to this policy. The email is delivered by Resend (section 3.12).
• The parent approves by opening the link and tapping the approval button, in the Picobello app if it is installed and otherwise on picobelloapp.com. Opening the link approves nothing by itself. The app never offers approval without the emailed link, so a child who can use a parent's device or shared-device passcode cannot approve their own profile.
• A link expires no later than the original 30-day deadline. Resending replaces earlier links and never restarts pending-profile retention.
• If nobody approves by the original 30-day deadline, the pending profiles and their names are deleted by the daily cleanup. Resending does not extend this deadline; physical deletion may take longer if cleanup fails.
• Approval creates a durable confirmation-email job for the original verified recipient. Child access remains paused until the provider accepts that confirmation for delivery. Failed submissions are retried with a finite limit; permanent failure keeps activation suspended. Provider acceptance does not prove that the message reached the inbox.
• Material changes require a fresh notice and approval before the changed processing starts. Previously approved profiles may continue only the purposes their valid existing approval covers, until the recorded re-approval deadline. New purposes stay disabled. Missing evidence, withdrawal, restriction or deletion blocks child access.
• Withdrawing immediately blocks the children's devices and new sessions, then permanently deletes the profiles the approval covered, with their activity, through the same process as a parent-requested deletion. Anything that cannot finish at once is completed by the daily cleanup. The family account and the parent's own data remain.

Each approval is bound to the exact notice version, notice-content digest, purposes, covered child identifiers and original verified recipient. The personalized notice and displayed child names are snapshotted for that decision. Material notice changes invalidate pending links. A pending confirmation job temporarily holds the recipient address and withdrawal link needed for delivery; those temporary values are removed on completion, cancellation or permanent failure. Deletion minimizes personalized approval evidence. Approval records are personal data, including where identifiers are hashed.

10.4 Device identifiers and what we use them for

A child's use of Picobello involves the persistent identifiers below. We use them only to run the service for the family: to sign a device in, keep its data in sync, deliver notifications, keep the service secure and let parents see and revoke paired devices.

• Account and profile identifiers: the internal child and family IDs and the Firebase Authentication user ID of the child session. They authenticate the child, load the right profile and keep quests, coins and rewards in sync across the family's devices.
• Session reference: a random value the app creates on the device and keeps in its own storage, one for each child on that device. It lets a reconnection or profile switch on the same device reuse one session record, which a parent can see and revoke.
• Device class, model identifier and last use: for example “iPhone15,4” or “Pixel 8”, whether the device is a shared household tablet, and when the session was last used. They let parents tell paired devices apart, and let siblings switch profiles on a shared tablet but not on a child's own phone.
• Push token: the APNs or FCM token of the device, with its language and notification preferences. It delivers reminders and family notifications through Apple or Google.
• App attestation: Apple App Attest on iOS and Google Play Integrity on Android, checked through Firebase App Check. It confirms that a request comes from a genuine copy of the app; we do not store the attestation against the child's profile.
• Google Play age signal: on Android, where Google Play provides it, the account's verified-adult or supervised status, age range and, for a supervised account, an install identifier (section 3.13). It is used only to give age-appropriate access and to act on a parent's decisions in Google Play, and is never added to the child's profile.
• App Store transaction identifier: on iOS, a one-way hash of the App Store's identifier for the device's Apple Account and this app, stored with the device's session (section 3.14). It is used only to act on a parent's withdrawal of consent in the App Store, and is never added to the child's profile.
• Apple age-range outcome: on iOS, where Apple requires it, whether access is allowed or needs a parent's approval, stored only as a status with the device's session (section 3.13); it is never added to the child's profile.
• App Store version lookup: on iOS, at most once a day the app asks Apple's App Store for the current version number, sending the app's bundle ID and the device's storefront country (section 3.11).
• IP address: received by our hosting and cloud infrastructure with each request, for delivery, security and rate limiting. Rate-limit records hold a rotating or pseudonymous hash, not the address.

We do not collect a child device's advertising identifier, Apple vendor identifier, Android ID, device name, serial number, phone number or precise location. We do not use a child identifier to contact a child, for behavioral advertising or to build a profile of a child, and we do not send it to an advertising provider. Operational identifiers reach the service providers in section 5. Google processes customer data on our instructions under the applicable data-processing terms and separately processes certain service metadata under the notices described in section 3.11. Our safeguards include keeping advertising, analytics and crash-reporting SDKs out of the app, database rules that confine application records to the family and our backend, leaving children's use out of the optional adult statistics, and writing no child or device identifier into the aggregate statistics (section 3.9).

10.5 Parents' choices

A parent or guardian can request review, correction, deletion and an end to further collection using the controls and contact details in this policy. The child also has rights. Independent teenager choices and disputed guardian authority are assessed before disclosure; a family role does not entitle someone to every record.

A parent can review and correct profiles, request a copy, revoke devices and delete a profile. The confirmation-email withdrawal link revokes service access and starts deletion of the covered profiles. Necessary rights handling, security and justified legal evidence may remain subject to their separate retention limits. Service providers in section 5 process operational personal data; we do not make child information public or permit independent advertising or marketing uses.

10.6 How long we keep children's information

This is our retention policy for children's personal information. We keep each item only for the purpose given and no longer than stated:

• Profile (nickname, avatar, age band and approval status), so the child can use their profile and the family can see its members: until a parent deletes the profile, withdraws approval or deletes the family, or until the family has gone unused, without an active subscription, for 12 months (section 7). A profile that is never approved is deleted 30 days after the original approval request.
• Individual activity records, for the parent’s recent activity view: available for up to seven days, with hourly physical cleanup and local age-out. Failures may delay physical erasure, but do not extend authorized server access.
• Game state (current quests, coin balance, running completion counts, reward inventory and redemptions), to run the game: for as long as the profile exists.
• Shop-purchase receipts, so a purchase is never applied twice: 30 days.
• Session records and device details (section 10.4), to keep a device signed in and let parents revoke it: while the session is active, and 90 days after it is revoked.
• Push tokens, to deliver notifications: as described in section 7.
• The date the family was last used, to find families nobody uses or pays for any more: until the family is deleted.
• Pairing codes and claims, to connect a device: valid for 10 minutes and deleted within about 30 minutes after they expire or are used.
• Parental-approval records, as evidence of the approval: 2,555 days (about seven years) after approval. A request that was never approved or was replaced is deleted 7 days after its link expired or was replaced.
• Deletion receipts, to prove a deletion happened and stop a deleted profile from being restored: 98 days (14 weeks, as long as the oldest backup), without the child's readable profile.
• Backups, for recovery: daily backups for 7 days, weekly backups for 98 days. Active-system deletion and final backup expiry are different milestones; restores must apply deletion records before serving families.

10.7 Additional information for people in the United States

This section adds to the rest of this policy for people in the United States. Which state privacy laws apply to Picobello depends on thresholds we may not reach, so we offer the rights below to every US family.

What we collect. We collect the following categories of personal information, described in sections 3 and 10.4: identifiers (a parent's name or email address, children's nicknames, account, session and device identifiers, IP address); commercial information (subscription status); internet or other electronic activity (quest, coin and reward activity in the app, sign-in and security records); and the age band a parent sets for a child. We do not collect precise or approximate location, biometric information, health information, contacts, photos or audio. We use age bands, not birth dates.

Why, and from whom. We collect it from the parent who creates the family, from the family's use of the app, from the App Store or Google Play (subscription and age signals) and from our providers' security systems. We use it for the purposes in section 4.

Who receives it. Only the service providers and platforms listed in section 5, which act for us under contract or as the app stores. We do not sell personal information, we do not share it for cross-context behavioral advertising or targeted advertising, and we do not knowingly sell or share the personal information of anyone under 16. We do not use it for profiling that produces legal or similarly significant effects.

Your rights. You can ask us to tell you what personal information we hold about you and your family, to give you a copy, to correct it, to delete it and to give you a portable copy, and you can withdraw consent for optional processing. A parent can use these rights for a child in their care. We do not treat you differently for using them. Use the privacy tools in the app or email support@picobelloapp.com. We may need to confirm that you control the family account before we act and will not ask for more than that requires.

Response time and appeal. We respond within one calendar month and in any case within 45 days. If we decline a request, we tell you why. You can appeal our decision by replying to our answer or by emailing support@picobelloapp.com with “Appeal” in the subject line; we answer an appeal in writing within 45 days. If you are not satisfied with the result, you can contact your state attorney general.

Do Not Track. Picobello does not track you across other websites or apps. Apart from the providers named in sections 3.12 and 3.15, no third party collects personal information through the app or the website. Because we do not track, we do not change how the app or the website works when your browser sends a Do Not Track signal.

11. Changes

We may update this policy when the app, providers, legal basis, recipients or retention change. We will change the version and date and provide additional notice or request renewed authorization where required. Before we collect, use or share children's information in a materially different way, we will email parents and ask for new approval, as described in section 10.3. The guardian-authorization flow shows the exact policy and terms versions recorded in its receipts. The legal screens in the app show the current version of each document.

12. Contact

Picobello Software UG (haftungsbeschränkt)

c/o The Base Berlin One, Pestalozzistraße 5-8, Apt. 216, 13187 Berlin, Germany

Managing director: Felix Parey

Commercial register: Amtsgericht Charlottenburg, HRB 291439 B

Phone: +49 160 93115625

support@picobelloapp.com