Data processing

For data about a shop’s visitors (“shoppers”), the merchant is the controller and OneSite Agency is its processor. For merchants’ own accounts and our website we are the controller. Our Terms of Service are our data processing agreement; there is no separate document to sign.

Shopper data, kept per shop and only for that shop:

• Conversations: what the shopper typed or dictated and the products shown and chosen (tables queries, events). Dictated speech is turned into text on our own servers; the audio is not stored.
• Visits: referrer, UTM tags, device type, browser, operating system, time zone, and an approximate country and city looked up from the IP address (table visits). The IP address itself is not stored.
• Contacts a shopper chooses to leave after a request the shop could not answer (table misses): stored encrypted with AES-GCM, with the key kept outside the database, next to a keyed hash used only to find them again for a deletion or data request. A request for a person is sent to the merchant by email and is not stored; we keep only the fact that it was made (table handoffs).
• Checkout notes and requests for a shopper’s data (tables checkout_notes, data_exports).
• Order records of the shop (tables purchase_orders, purchase_lines, purchase_discounts, purchase_cart): totals, line items and discount codes. They hold no shopper identity; their link to a conversation is removed when the shopper records expire.

Merchant and shop data:

• Catalogue, product embeddings and enrichment, the merchant’s facts about delivery, payment and returns, storefront pages and uploaded images, monthly model spend, and the merchant’s actions in the dashboard (tables products, embeddings, product_enrichment, facts, pages, storefront_*, budget_month, cabinet_deeds and similar, all keyed to the shop).
• Accounts for merchants who sign in on our site: email address, a password stored only as an Argon2id hash, language, and the time, IP address and browser of each sign-in (tables accounts, memberships, sessions).
• Platform connection: the shop’s domain, subscription state and the access keys needed to call the platform’s API; for direct customers, Stripe’s customer and subscription identifiers. Card details never reach us.
• Applications sent from our website, and, for shops brought by a referral partner, the accrued commission (tables applications, partner_accruals).

Knowledge that is not tied to any shop, with no shop identifier by construction: ratings of other sites’ charts, an IP-to-place reference table, per-title attributes derived from titles, and public ratings and reviews of books read from public pages of other sites. Reviews include the reviewer’s display name and text and are kept only while the source still shows them (see below).

We do not train or fine-tune language models on any merchant or shopper data and we do not sell data. Data from shops that installed through Shopify is not used for any kind of learning.

• Shopper records (conversations, events, visits, contacts, checkout notes, data-request records): deleted 395 days (13 months) after they were recorded, by a nightly job. The period is a product decision: the owner’s reports compare a month with the same month of the previous year.
• Reviews copied from other sites: deleted 30 days after the source last showed them. Ratings stay, as they contain no person.
• A shop after an uninstall: data is kept so that a reinstall restores it, until Shopify sends its erasure notice (shop/redact) 48 hours later; then everything about the shop is deleted. For a direct subscription, the shop is deleted 30 days after the subscription ends.
• A merchant account: while the account exists, and deleted within 30 days of a request.
• Database backups: nightly, encrypted, kept for 14 days on the same server, so deleted data leaves the backups within 14 days.

• The merchant sees its own shop’s data in the dashboard. Every record is stored under the shop it belongs to and is read only on behalf of that shop; one shop never sees another’s data, and a registry of every table and cache records which are shop-owned and which are shared knowledge, enforced by a test.
• Our operator has access to production systems; access is limited to the operator.
• A referral partner who brought a shop sees the shop’s domain, whether it is paying and the commission accrued.
• The sub-processors below, only what is described for each.

Everything we store lives on our servers at Hetzner Online GmbH in Nuremberg, Germany. Search, text embeddings and speech recognition run on those servers, with no third party. Sub-processors:

• Hetzner Online GmbH, Germany: hosting.
• DeepSeek, Hangzhou, China: the language model. To compose an answer it receives the text of the conversation and product data from the shop’s catalogue; to describe products it receives catalogue data and, for books, the texts of public reviews without reviewer names. It receives no shopper name, contact, IP address or order data. Each request is a transfer to China, which has no EU adequacy decision; as controller, the merchant decides whether it is acceptable for its shoppers. Requests are sent over an encrypted connection.
• Shopify: the platform the app runs on, and billing for app installs. Stripe: billing for merchants who subscribe with us directly.
• PostHog, EU cloud: usage analytics on our website and dashboard, not inside the assistant on a storefront.
• Telegram: when enabled, internal notifications to our team about new merchant applications.

The provider of the language model is a setting of the service, not a fixed part of the code, and the country above is that of the provider in use today. We add or change a sub-processor in the Privacy Policy, with its date, before it starts.

The merchant decides about shoppers’ data, so shoppers write to the shop first; if they write to us, we pass the request on and help the merchant answer it. Through Shopify the three standard requests are handled automatically:

• Data request (customers/data_request): within 30 days we send the shop owner the data we hold about that customer, as a machine-readable file.
• Customer erasure (customers/redact): we delete the contact that customer left, the conversations linked to it and the orders listed in the request.
• Shop erasure (shop/redact): we delete everything we hold about the shop.

Merchants write to the address below and we answer within 30 days. Shoppers and merchants can also complain to a data protection authority.

One path serves both a platform erasure notice and an operator removal. Every shop-owned table references the shop with a cascading key, so deleting the shop’s single row removes everything that belongs to it in one transaction, all or nothing. Images uploaded to the storefront builder live on disk and are removed first; a failed deletion is repeated. Merchants left with no shops are removed after the shop.

What remains after a shop is deleted, by design:

• Commission accruals owed to a referral partner: amount and domain, with the shop identifier cleared. They contain no shoppers.
• The operator’s action log, which must outlive its subject as evidence of who enabled, disabled or deleted a shop, including the deletion itself.
• Shop-independent knowledge listed above, which holds no shop or shopper identifier. Backups age out within 14 days.