Privacy Policy

Rootlogik GmbH · Last updated: November 2026

1. Who we are

Rootlogik GmbH (Germany) operates BlickIQ. For data protection enquiries, contact us at info@rootlogik.de.

2. What data we process

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.

3. Connected data sources

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:

  • Shopify and WooCommerce — orders, line items, products, refunds and fulfilment events.
  • Stripe — charges, refunds, subscriptions, invoices and balance transactions.
  • Google Ads, Meta Ads and Google Analytics 4 — advertising and traffic performance.
  • FundraisingBox — donations, recurring giving plans and projects.
  • Sendcloud — parcels, orders, returns, carrier status events and shipping invoices.

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.

4. Legal basis

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.

5. Third parties

Companies that handle your data for us. These process data on our behalf:

  • Anthropic Ireland, Limited (Dublin, Ireland) — receives your questions, your support chat messages, and the data needed to answer them, as a processor under GDPR Art. 28. Although we contract with Anthropic’s Irish company, the data is stored in the United States and the AI model may run in any country, so this is a transfer outside the EEA. It is governed by Standard Contractual Clauses. Anthropic does not use API inputs to train its models by default, and retains prompts for 30 days for trust and safety review. See anthropic.com/privacy.
  • Supabase — our database provider, holding your account, your conversation history and your synced data. Your database, sign-in service and stored files are in the EU (Frankfurt). We contract with Supabase’s Singapore company, and its support staff in the United States can reach data held in the EU, so this is a transfer outside the EEA governed by Standard Contractual Clauses. System logs and backups may sit elsewhere.
  • Railway — our application hosting provider. The servers running BlickIQ and the data they store are in the EU (Amsterdam), but Railway’s own platform processing, including deployment logs, takes place in the United States, and Railway does not guarantee that computing capacity always stays inside the EEA. This is a transfer outside the EEA governed by Standard Contractual Clauses. For its own account and usage records Railway decides its own purposes rather than acting on our instructions.
  • Brevo (Brevo GmbH, Berlin) — our transactional email provider, a processor under GDPR Art. 28. It receives your email address and the contents of the messages we send you, such as invitations, account notices and billing alerts. Your data is stored in the EU. Brevo group companies in the United States and India can access it for support and maintenance, under Standard Contractual Clauses.
  • Better Stack (Better Stack, Inc., United States) — our uptime and error-tracking provider, a processor under GDPR Art. 28. It checks that BlickIQ is up, and when something goes wrong, technical error reports can be sent to it from your browser and from our servers. A report can include the error message, the address of the page or request with identifiers removed where we can, your browser and device type, and the IP address of the connection that delivered it, which for a report sent from your browser can be your own. We remove personal details from error messages where we can, but that cannot reliably catch names or postal addresses. Error reports are stored in Better Stack’s EU region. We contract with Better Stack’s US company, so this is a transfer outside the EEA, which we understand to be governed by the Standard Contractual Clauses in its data processing agreement; our external legal review is confirming that reading. Error reports are not linked to your account by a user ID, so we cannot find yours to delete on request; we rely on their automatic deletion after 90 days.

Third parties who are not our processor. When you use these you deal with them directly, under their own privacy policies:

  • Google Sign-In — runs as code embedded in the page rather than by sending you elsewhere (see section 2). If you choose it, Google confirms your identity to us. We store the email address and the account identifier it returns, and nothing else from your Google profile.
  • Microsoft sign-in — opens a Microsoft-hosted sign-in window. Same result: we store the email address and the account identifier, and nothing else from your Microsoft profile.
  • Stripe — checkout and billing happen on Stripe-hosted pages, so we never see or store your full card number. The payment records we keep for accounting do include the card brand, the last four digits and your billing address.

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.

6. How long we keep data

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.

7. Your rights

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.

8. Supervisory authority

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.

Privacy Policy — BlickIQ