Privacy Policy
Privacy Policy
Kitcho processes data for your account and the features you use. Separately, we offer optional internal measurement of app and website use. Not all processing is essential to operating the service itself.
This is a translation for convenience. The original Czech version is authoritative and takes precedence if the texts differ. Your statutory rights remain unaffected. Read the Czech original.
Last updated: 2026-10-22
Who controls the data
- The data controller is GoBeast s.r.o., company registration number 17077621, registered office Na Císařce 3223/24, Smíchov, 150 00 Praha 5, Czech Republic.
- Send privacy questions and requests for access, correction or erasure to support@kitcho.eu. You can also contact support within the app.
What data we process
- Account data: name, email, internal account identifier, app language, access tokens, refresh tokens and account settings.
- User content: recipes, ingredients, instructions, nutrition values, shopping lists, aisles, loyalty cards, packing lists, packing sets, recurring purchases, planning, households and shared expense settlements.
- Photos and attachments: loyalty card photos, recipe images, shopping item photos, packing item photos, support ticket attachments and other files uploaded by the user.
- Support tickets: report text, replies, ticket status, technical context and attachments sent by the user.
- Shared expenses and settlements: participants, payments, expenses, currencies, exchange rates, split amounts, change history, invitations and settlement sharing.
- Locations for loyalty cards: precise location used for card recommendations or card opening, learned card places, globally ignored location zones and places where a specific card should not be suggested.
- Operational and security data: API operation time and type, outcome and duration, account identifier, and possibly email, IP address, user-agent and error context. Usage events described below are processed separately and are not automatically essential security diagnostics.
How we use data
- To sign users in and synchronize data between the app and related services.
- To display and edit content saved by the user.
- To share selected data with people or households when the user chooses to do so.
- To support offline use on the device and synchronize changes with the backend later.
- To suggest loyalty cards based on places where the user uses them or where a merchant is saved.
- For support, bug fixing, security, abuse prevention and app improvements.
Data sharing
- We do not sell data and we do not use it for advertising tracking across apps or websites.
- Data is shared only through features used by the user, such as shared shopping lists, households, shared loyalty cards, recipes or settlements.
- Kitcho infrastructure is hosted by WEDOS; the provider may access data within its services. Internal product measurement is not sent to external analytics or advertising services, uses no advertising identifiers and is not linked with activity in other companies’ apps or websites for advertising.
Optional measurement for your entire account
- Product measurement is off by default. It starts only after informed, explicit permission for the current consent text. On the web, choose in the offered dialog or Settings → Usage measurement; supported mobile versions offer the corresponding choice. Refusing, postponing or withdrawing consent does not restrict Kitcho features.
- One choice applies to your entire signed-in account on all signed-in devices and the web. Permission, refusal and withdrawal are stored on the server and synchronized to other clients. Without valid consent for the current version, the server accepts no new product events. Earlier consent for one installation is not automatically extended to the whole account. Older mobile versions without this check do not create new product events.
- The purpose is to improve Kitcho by understanding the first measured opening after consent, returns and use of key features. The first measured opening is not the download date or reliable proof of a first installation; no further events does not prove an uninstall.
- After verifying consent, a measurement context uses a random ID and a separate random installation secret. The secret is not a login token and grants no access to account content; the installation database stores only its hash. On mobile this is an installation context; on the web it is an account and browser-tab session context in sessionStorage. We do not use a device fingerprint.
- Installation records contain the account link, platform, new/existing/uncertain installation status and server times of the first and last measured opening, first account link, first successful data change and returns in day 1, 7 and 30 windows. A web context is not evidence of a mobile app installation.
- Client events can describe app openings, selected screens, recipe details, cooking and timers. Stored fields include event type, account, platform, screen, server and optional client time, context ID hash and consent revisions. Allowed metadata include language, app version and build, and related recipe, plan, list or collection IDs if sent by the client. The scope depends on the supported client version.
- The server also records selected successful changes as the product event server.api_write, only after verifying the same account consent and matching measurement context. It contains account, time, platform, operation type, API route template, HTTP status and consent revision evidence, not the change payload. Approximate online presence also requires consent.
- Data are linked to your account and are not anonymous analytics. Authorized administrators may see the account nickname/name and email with events. New product events store neither IP address nor user-agent. The collector does not send recipe text, shopping content, search queries, passwords, precise location or advertising identifiers. This does not limit separate data needed by features you use, such as saving a recipe or location-based card recommendations.
Separate operational and security records
- Regardless of product consent, necessary records may be created for security, abuse prevention and troubleshooting: API request metadata, errors and rate limits. New detailed database API logs do not store request bodies, response bodies or free-form error text. Separate error logs may contain technical messages and error context.
- The operational console may show minute-level totals of successful API change types derived from these records, without names, accounts, IPs, specific object IDs or stable pseudonyms. This does not anonymize underlying diagnostic logs, which may contain identifiers. Detailed named product events require consent. Administration and detailed diagnostics are accessible only to authorized administrators with the relevant permission.
How long data are kept
- Client product events and server.api_write become due for deletion after 90 days from creation; installation records after more than 180 days without a measured opening. Cleanup runs in batches when the relevant administrator summary is loaded; inactivity or backlogs may delay completion beyond the exact expiry time. Online presence is derived from the last verified activity within a 90-second window, without creating a separate permanent presence history.
- The current account choice and explicit decision history are recorded to respect and demonstrate your choice: state, time, revision, text version and where applicable a copy of the text, language, platform, decision source and random operation ID. This evidence is not removed with the 90-day event history; the current system retains it for the lifetime of the account and removes it on account deletion. Minimal hash records of revoked installation contexts without account links or secrets become due for batch deletion 180 days after revocation.
- Routine database API diagnostic records become due for deletion after 30 days; failed operations with HTTP status 400 or above and database error logs after 90 days. Automatic cleanup runs in bounded batches during API traffic. Security rate-limit records are cleaned after one day during later requests. Deletion at the exact expiry time is not guaranteed.
- These automatic periods do not cover hosting logs, infrastructure backups, fallback error files or failed-email logs. Application code does not guarantee a common deadline for these categories, and erasure from the active database does not mean immediate erasure from all backups. Contact the controller at support@kitcho.eu for details and erasure requests.
Switching off, sign-out and erasure
- On the web, withdraw at any time under Settings → Usage measurement → Turn off for the entire account, or similarly in a supported mobile version. Once confirmed by the server, further product measurement is rejected for the entire account on all devices and the web. Completed or concurrently completing requests cannot be recalled. Withdrawal itself does not erase past history or installation records.
- Offline, the web stops local measurement and stores a pending refusal or withdrawal in the browser-tab session. Delivery is retried after reconnection for the same signed-in account. Until the server confirms, the change has not taken effect on other devices. A newer decision from another device is not blindly overwritten; you may need to choose again. Completion cannot be guaranteed after closing the session, deleting local data or uninstalling the app. Mobile behavior and retries depend on the app version and its ability to run.
- Erasing past history is a separate request. The server supports account-wide erasure of past client product events and server.api_write linked to the account, not recipes, shopping, operational and security logs, installation summaries or consent evidence. History erasure does not itself withdraw consent; new events can be created if permission remains. If your version has no separate history-erasure option, contact support.
- Signing out does not withdraw account consent, but new account product events and measured openings are not accepted without sign-in. The web retires its local context and requests its deletion; a mobile client may unlink the installation. Switching accounts must not transfer measurement to another person. Availability of these mobile controls depends on the supported version.
- Account deletion removes account decisions and their evidence and installation contexts belonging to the account; minimal revocation hashes may remain for the period above. Other historical product events lose the account link rather than automatically losing entire rows and metadata. Removing a link alone does not guarantee irreversible anonymization. You may separately request full product-history erasure, for example before deleting the account; the controller handles further requests.
Location and card recommendations
- Kitcho does not continuously track location in the background.
- Location is used when working with loyalty card recommendations, opening a card or manually saving a card location.
- The user can disable location-based recommendations by not granting location access to the app or by not using location recommendations.
- The user can manage learned card places, globally ignored zones and places where one specific card should not be suggested.
Storage and security
- Passwords are stored only as hashes, not as readable text.
- Refresh tokens are stored separately and can be invalidated by signing out or changing the password.
- The app may keep an offline cache on the device so it works faster and without internet access. Changes are synchronized with the backend when the connection returns.
- Users should protect sensitive data by securing their devices.
Account deletion
- The account can be deleted directly in the app. The backend verifies the password, sends a confirmation code by email and then deletes or anonymizes the account after confirmation.
- Personal data is deleted or anonymized depending on the type of data and applicable legal obligations.
- Shared objects may be transferred to another member or adjusted so other users’ data is not broken.
- After account deletion, the original login and refresh tokens can no longer be used.
Reasons for processing and your rights
- Data necessary for accounts, synchronization and requested features are processed to provide the service. Optional app and web product measurement is based on consent. Essential security and diagnostics are processed separately on the basis of the legitimate interest in protecting service security and reliability, not as a substitute for declined product analytics.
- You may request access, correction, erasure, restriction and, where applicable, data portability. You may object to processing based on legitimate interests. Withdrawal does not affect the lawfulness of earlier processing. Contact support@kitcho.eu. Complaints may be lodged with the Czech Office for Personal Data Protection or the competent supervisory authority where you live.