Rootlogik GmbH · Last updated: November 2026
Rootlogik GmbH (Germany) operates BlickIQ. For data protection enquiries, contact us at info@rootlogik.de.
Questions you type, and our answers. When you submit a question, that text is sent to Anthropic’s Claude AI API to generate SQL and write the analysis. Your questions and the answers are also saved to your conversation history so you can return to them later. A conversation is deleted automatically once it has gone unused for your plan’s history period, or earlier if you delete it — see sections 6 and 7.
Conversations belong to the account, not to one person. If several colleagues share a BlickIQ account, every one of them can open, read and delete every conversation in it, including yours. We do not separate conversation history by individual user.
Support chat. What you type in the support widget is sent to Anthropic’s Claude AI API to produce a reply. When a conversation starts we record that it happened, along with your language setting and the identification string your browser sends. If you submit a support ticket, or the conversation is handed to a human, the transcript and the email address you give us are stored on our servers and forwarded to our helpdesk provider (see section 5). The record that a conversation started, and our database copy of a ticket or a handed-over transcript, are deleted after a set period (see section 6). The conversation is also kept in your browser’s own storage. Please do not paste customer details into support chat — unlike connector data, it is not filtered.
Quality sample. Roughly one in twenty answered questions is copied into a separate internal table so our staff can grade answer quality and improve the product. The copy holds the question, the answer, and the database query we generated from it. Email addresses and long number sequences are removed from the question and the answer; names are not, because there is no reliable way to detect them automatically, and the generated query is stored as written. This copy is not linked back to the conversation it came from, so deleting a conversation does not remove it.
Your acceptance of our terms. When you agree to our terms while buying a subscription, we keep a record of that agreement. It holds the account identifier your sign-in provider gave us, the email address on that sign-in, which version of the terms you accepted, a fingerprint of the exact text you were shown, and the time. We keep the full text of every version we have published, so we can show you what you agreed to. We do not record your IP address or your browser against this. These records are our evidence that a contract exists, so they are not deleted when a conversation is deleted, and we keep them for as long as we may need to rely on them.
What we store on your device. We set strictly necessary cookies to keep you signed in. They arehttpOnly(page scripts cannot read them) and expire within 8 hours. No consent is required for strictly necessary cookies under the ePrivacy Directive. We set no analytics, advertising or tracking cookies.
We also use your browser’s own storage, which falls under the same rules as cookies. Rather than list every key, here are the kinds of things that go there: your support-chat conversation, including everything you typed into it; interface preferences such as panel sizes; a short-lived sign-in session while you are signing in with Microsoft; and marketing attribution, such as a partner referral code kept for up to seven days or the campaign parameters in the link you arrived from. Some of this has no automatic expiry. All of it is on your own device and is cleared when you clear your browser data.
Application logs. Our servers write technical logs so we can debug and diagnose problems. Assume that anything you type can appear in them: question text reaches our logs on questions that succeed as well as on those that fail, and technical error messages can quote a value from the record that caused the error. We strip email addresses, phone numbers and bank account numbers from log output where we can, but that filtering is not applied at every point in the system that writes a log line, and it cannot reliably catch names or postal addresses at all. We would rather tell you to treat the logs as carrying what you typed than give you a guarantee we cannot keep everywhere. Log files rotate on our servers and our hosting provider applies its own retention to the log stream; we do not operate a fixed retention period of our own.
Our team’s internal work sessions. Our team uses Anthropic’s Claude Code tool as an internal assistant. A session runs on our own machine and sends its content to Anthropic for processing: what our team types, what the assistant replies, and what its tools read and return. Our team can also reach a session from a phone or browser through a feature called Remote Control. While a session is connected this way, its transcript is also stored on Anthropic’s servers, to keep the conversation in sync across devices. How your own questions reach Anthropic is described separately in section 5. These sessions are for our engineering work, so the kinds of things they carry are source code, tickets from our issue tracker, proposed code changes and the comments on them, plan documents, the status of automated test runs, and query results from our development database, which holds test data. A ticket, comment or log can quote whatever someone wrote into it, including details from a support request or an error report, so a transcript can contain personal data. Storage does not necessarily end when a session disconnects: Anthropic keeps this data under its Claude Code data usage policy. These sessions run on the Claude Max plan, with the setting that lets Anthropic use the account’s data to improve its models turned off. Under that policy the retention period is 30 days, and Anthropic does not train its models on this data. We have not yet confirmed where these transcripts are stored or how any transfer outside the EEA is covered.
Third-party code in your browser. We use no analytics services, advertising cookies or tracking pixels, and fonts are served from our own infrastructure. One piece of third-party code does run in your browser: Google’s Sign-In library (accounts.google.com/gsi/client), loaded on any page carrying a “Sign in with Google” button — signing in, subscribing, claiming an invitation or activating an account — so that button can work. We load no advertising, analytics or tracking scripts from anyone.
BlickIQ answers questions about your own business data. To do that, you authorise us to read from the platforms you already use. Eight are available today, and we read only from the ones you connect:
Meta (Facebook) specifically. When you connect a Meta ad account, BlickIQ requests the ads_read permission only. We read advertising performance data — ad account, campaign, ad-set and ad names and identifiers, plus daily spend, impressions, clicks and conversions, and the cohort-level breakdowns Meta returns (such as age band, gender, country and placement). We store no personal data about the people who saw or clicked your ads: Meta’s reporting API returns aggregate cohort figures, never per-impression or per-click identifiers. Custom Audience names are discarded at sync time and never written to our database.
Customer and donor details are dropped at sync time. For the four connectors where we drop them — Shopify, WooCommerce, Stripe and FundraisingBox — we discard names, email addresses, phone numbers, postal addresses, birth dates and bank account numbers from the fields those systems define for them, before anything is written to our database. We keep the source system’s own record identifiers (for example a Stripe cus_… customer ID) so that repeat-purchase and lifetime-value analysis still works. Identifiers of this kind can still count as personal data, so we treat them as such.
What that dropping does not cover: free-text and pass-through fields. Where a source system lets you or your platform type whatever you like into a field, or hands us a block of data it defines itself, we store it as sent. Examples rather than a complete list: a Stripe charge’s description and its metadata block, which donation platforms routinely use to carry donor details; a Shopify refund’s merchant-written note; a FundraisingBox direct-debit mandate’s bank BIC. If someone on your side writes personal data into a free-text field, it reaches our database, and we would rather say so than imply a filter that does not exist.
Sendcloud is a real exception, and we will not describe it as anything else. For shipments we keep only the destination country and the first two or three characters of the recipient postcode — enough for shipping-zone analysis, not enough to identify a household. But Sendcloud orders and returns are currently stored as the complete record Sendcloud returns to us, which can include recipient contact details such as a name, address, email address or phone number. That is a gap in our data minimisation, not a design choice, and closing it is open engineering work. Until it is closed, this is what happens, and a deletion request covers those records like any other.
Access tokens for connected sources are encrypted at rest with a key held outside the database, and both the tokens and the synced data are stored in EU infrastructure.
Your account and your connected data: performance of a contract (GDPR Art. 6(1)(b)). Reading the data sources you connect and answering questions about them is the service you signed up for.
Keeping the service running and secure: legitimate interest (Art. 6(1)(f)). This covers authentication, error logging, abuse prevention and billing records.
Grading answer quality: a separate legitimate interest (Art. 6(1)(f)). The sample described in section 2 improves the product rather than delivering your contract, so we declare it as its own purpose rather than folding it into the basis above.
Records about your own customers and donors. Where synced data still relates to your customers, we process it on your instructions as a processor under Art. 28, not on a basis of our own choosing.
Transcripts of our team’s internal work sessions. The legal basis for the transcripts described in section 2 is still being assessed, so we do not state one here.
We do not intentionally process special category data (Art. 9), and we do not rely on consent as the legal basis for the processing described here.
Companies that handle your data for us. These process data on our behalf:
Third parties who are not our processor. When you use these you deal with them directly, under their own privacy policies:
This section names the third parties most relevant to how BlickIQ works. It is not yet a complete list of every sub-processor in our supply chain; the full disclosure is being prepared alongside our external legal review.
The data in your account has no automatic expiry, with four narrow exceptions. Your account data, connected credentials and synced source data are kept for as long as your account exists. We do not run a timer that deletes them after a set period, and we do not want to imply otherwise. Your conversation history is kept for your plan’s history period, the fourth exception below. The first exception: quick questions asked straight from the dashboard are cleared once they are more than 24 hours old, the next time that workspace is opened. If nobody opens it, they are not cleared.
The second exception: our own quality checks. When an answer is produced, we can run automatic checks on it for internal consistency — for example, whether percentages add up, or whether the same row appears twice. What we keep is the score sheet, not the answer: how many checks ran, how many failed, and which ones. It holds no question text, no query, and no figures from your data beyond two coarse descriptions of the request itself: what kind of question it was (for example a ranking or a comparison), and roughly how many rows came back, as a band such as "11-100" rather than an exact count. Any such record is deleted automatically after 90 days, and it is deleted immediately if your account is deleted.
The third exception: four kinds of support record. Once a day we delete from our database the support tickets you submitted that are more than 12 months old, the transcripts of support chats handed to a human that are more than 90 days old, the thumbs-up or thumbs-down ratings of support replies that are more than 6 months old, and the record that a support conversation started (your language setting and browser identification string, described in section 2) once it is more than 90 days old. A chat transcript attached to a ticket is part of the ticket, so it is kept for the ticket’s 12 months, not 90 days. When we delete your account at your request, we delete the support records linked to it at the same time. A support ticket sent without signing in is deleted on request by the email address it was sent from. Transcripts handed to a human, ratings, and the record that a chat started, from a support chat without signing in, have no account or email address field, so only the periods above remove them; anything you typed into such a chat, including your own email address, stays until then. This deletes the copy in our database. It does not reach copies already passed on, including the ticket at our helpdesk provider, the notification email to our support inbox sent when the helpdesk could not take a ticket, short quotes from support chats in our team’s weekly internal support summary, and our database provider’s backups; those follow their own retention.
The fourth exception: conversation history. Once a day we delete each conversation that has had no new question and no rename for your plan’s history period: 3 months on Starter, 12 months on Growth and 24 months on Custom, monthly or annual alike. The whole conversation goes, with all of its messages, and it cannot be restored. Opening or reading a conversation does not count as using it. During a free trial, the period of the plan you are trying applies. Nothing is deleted this way from an account whose subscription has lapsed or been cancelled; its conversations are kept as long as the account exists. After a change of plan, the new period applies no earlier than 30 days after the change. This does not reach the quality sample described in section 2 or the quality-check score sheet described above, which follow their own rules, nor our database provider’s backups.
What you can delete yourself, right now. Any conversation can be deleted from the sidebar in the app. That removes the conversation and all of its messages immediately, subject to the quality sample described in section 2, and to the quality-check score sheet described above, which is linked to your account rather than to a conversation and so is not removed by deleting one.
Everything else in your account is deleted on request, within 30 days. That covers a single connector’s credentials and synced rows, or the whole account and the data associated with it. See Request Data Deletion for how to ask and what the limits are.
Deletion removes data from our live systems. A copy can still persist for a while afterwards in places we do not fully control, including our database provider’s routine encrypted backups, our hosting provider’s log stream, our AI provider’s short-term retention of the prompts sent to it, the transcripts of our team’s internal work sessions described in section 2, and the error reports described in section 5. Each of those rolls off on its own schedule. We have not yet established whether we can delete an individual transcript of those sessions at Anthropic, so we do not promise it; they follow the period stated in section 2.
Under GDPR you have the right of access, rectification, erasure, restriction, data portability, objection, and to lodge a complaint with a supervisory authority. To exercise any of them, contact info@rootlogik.de from the address associated with your account. For erasure specifically, the route, the timeframe and the exceptions are set out on Request Data Deletion.
You may lodge a complaint with the supervisory authority for the German state (Land) in which Rootlogik GmbH is registered, which is the authority competent for complaints against us. A list of the German supervisory authorities is published by the Federal Commissioner for Data Protection and Freedom of Information (BfDI) at bfdi.bund.de.