Privacy Policy

Quick summary

Keel HQ is an operations platform for DTC brands. On the marketing site we collect:

• The email address you give us if you join the waitlist.
• Anonymous, cookieless analytics about which marketing pages you visit (via Fathom Analytics).
• Standard server logs (your IP address, user agent) when you load a page.
• Bot-protection signals from pages with a waitlist form, processed by Cloudflare Turnstile to distinguish people from automated abuse.

Merchants who install the Keel HQ Shopify app also authorize us to sync their store's order data — including customer email addresses — as described in the Merchant and customer data section below.

We don't sell your data. We don't track you across other websites. We don't use third-party advertising cookies.

Questions? Email privacy@keelhq.io.

Who we are

This site is operated by Lindahl LLC, doing business as Lindahl Studios (“we”, “us”, “our”), a studio based in Washington, USA, building Keel HQ at keelhq.io.

What we collect, and why

Waitlist email address

When you submit the waitlist form on the marketing page or the coming-soon page, we store your email address so we can notify you when Keel HQ opens to early access. We also store the source of the signup so we can understand which surface is converting.

We do not subscribe you to any other emails. You will only hear from us about Keel HQ's launch.

Waitlist bot protection

Pages that contain our waitlist form use Cloudflare Turnstile to help prevent automated signups. Turnstile processes client signals including your IP address, TLS fingerprint, user-agent header, site key, and the site's origin to distinguish people from bots. We use those signals only to protect the form from abuse; we do not use them for advertising or cross-site tracking. Read Cloudflare's Turnstile Privacy Addendum for more information.

Anonymous analytics

We use Fathom Analytics, a privacy-focused, cookieless analytics service, to measure aggregate traffic to our marketing pages — which pages are visited, where visitors come from, etc. Fathom does not use cookies, does not collect personal data, and does not track visitors across websites. Read Fathom's privacy commitment for more.

And we forward Core Web Vitals (LCP, CLS, INP) to Fathom as bucketed events (good / needs-improvement / poor per Google's thresholds) so we can spot performance regressions. None of this involves cookies, personal identifiers, or cross-site tracking.

Inside the Keel HQ app — never on these marketing pages — we use PostHog for product analytics and error tracking: which features get used, which flows people get stuck in, and what broke when something errors. PostHog receives the page path you visited (query parameters are stripped in your browser before the event is sent) and which section of the app it belongs to, your account's user identifier, your organization identifier — which also groups your team's activity together as one workspace — your role in that organization, Core Web Vitals for the page, and the stack trace and message of an error that goes unhandled. It also records the coarse device and browser information any web request carries.

Each named action also carries a little metadata describing the action itself — which month a report covers and whether it was regenerated, the internal identifier of the report record, which integration you connected, which method you signed in with. A few more events describe how the product is working for you: which kind of action you completed in a section of the app (“drop created”, “cost added”), which screen showed you a “nothing here yet” state and whether that was because an integration isn't connected, which integration a connection attempt failed for and the error status it returned, the role an invitation was sent for — never the invitee's address — and which section of the app you were in when you sent us a bug report, whose text and screenshot go to our issue tracker rather than to PostHog. What all of it has in common is the commitment we will hold to as the product changes: these properties describe your use of Keel HQ, never the business data Keel HQ holds for you. No order contents, no product or customer records, no revenue figures, no email addresses, no message or prompt text.

One category of figures we do send, and want to name explicitly because they are financial: your Keel HQ AI usage. A question to the AI assistant sends the AI provider and model used, the input and output token counts, the cost of that call, and how many tools it needed; a spend-cap or spend-alert event sends the cap or threshold you configured, your month-to-date AI spend, and how many people the alert went to. These are measurements of your usage of our AI features — never your store's revenue, orders, products, or customers.

Two things happen outside the dashboard screens themselves. When you sign up or sign in — with a password, through an emailed link, or with an emailed code — our server records that the sign-up or sign-in happened and which of those methods you used, against your user identifier. Never your password, never the contents of the email, and not your email address. And where we have switched error reporting on in one of our own server-side or scheduled processes — report generation and the AI-spend alert job among them — a failure their server-side error handler receives sends PostHog the error, so we find out before you do. Alongside the error goes one identifier where the failing process has one to hand — the workspace’s, or yours — and where it has neither, the report is filed against no one. We are extending that coverage over time; what gets sent when it fires does not change.

Session replay is turned off. PostHog offers a feature that records and replays what a user did on screen. We have disabled it in our application code, not merely left it unconfigured, because the dashboard displays your business's live revenue, inventory, and customer figures and we are not willing to record that. Turning it on would require a change to this policy first. For the same reason we have disabled PostHog's automatic click tracking, which would capture the text of whatever you clicked: every event we send is one we named and chose the contents of. We never send your email address, your customers' email addresses or names, or any revenue figure to PostHog.

PostHog requests are routed through our own domain rather than loaded from PostHog's servers directly. This is so ad blockers don't silently drop the error reports we rely on; it does not change what PostHog receives, which is the list above.

PostHog is never started on the demo workspace, so no product event, error report, or identification is ever sent from it.

We do not use Google Analytics, Facebook Pixel, advertising trackers, or any cross-site behavioral tracking on this site.

Server logs

Our hosting provider (Vercel) records standard request information when you load a page: IP address, user agent, request path, response status, and timestamp. We use this only to debug errors and detect abuse. Vercel retains these logs for a short period and we don't query them for individual visitors.

Merchant and customer data

When a merchant installs the Keel HQ Shopify app, they authorize Keel HQ to sync their store's order data into Keel's analytics pipeline. This sync includes the customer_email field on each order. That email is Shopify customer data — it belongs to the merchant's customers, not to the merchant themselves — and Shopify classifies it as protected customer data under their API terms.

We store customer_email for three specific purposes:

• GDPR compliance webhooks. When Shopify fires a customers/data_request webhook (a customer requesting their data) or a customers/redact webhook (a customer requesting deletion), we use the stored email to identify and act on the correct rows. Customer emails are never displayed in Keel's UI and are never sent to end-customers or shared with third parties beyond the sub-processors listed in the Sub-processors section below (our database provider, PlanetScale, which stores it as part of database rows, and the read-only legacy copy at Supabase described below).
• Reporting and analytics. The email acts as the customer identifier when Keel generates a merchant's reports — classifying each order's buyer as a new or returning customer and computing trailing-twelve-month lifetime value. These are aggregate metrics; the email itself is never shown in the reports, never used for marketing, and never sent to any AI provider.
• Internal audit trails. When a merchant asks which orders belong to a specific customer during operational triage, the email allows us to look up the matching records on their behalf — server-side only, within their org's data scope.

New and returning orders. To tell a customer's first order from a later one, we read the position Shopify reports for each order (customerOrderIndex, under the read_orders scope) and store only a yes/no flag on the order. This is Shopify protected customer data at Level 1 (order data with no name, email, address or phone), covered by the protected-customer-data approval our app already holds. We derive the flag from order data and store no customer ID, name or email for it, and it is not linked to a customer. A guest checkout has no position, and an order Shopify has not yet attributed has none either: in both cases the flag stays empty and is never counted as a new customer.

Retention and deletion schedule:

• Customer data is active while the shop's Shopify integration is connected.
• When a merchant uninstalls the app, Shopify fires a shop/redact webhook 48 hours later. On receipt, we delete all storefront-scoped rows including customer_email from sales_snapshots and all related tables.
• When Shopify fires a customers/redact webhook for an individual customer, we null the customer_email field on all matching rows within 30 days of the request.

Encryption and access control: Merchant and customer data is stored in managed Postgres. That database is hosted by PlanetScale. Supabase holds a read-only copy of our database from before 23 October 2026, kept only as a rollback safeguard. Files you upload (logos, fonts, avatars, and bug-report screenshots) are stored in Cloudflare R2, not in the database. Data at rest is encrypted with AES-256 at the database provider, and files in R2 are encrypted at rest by Cloudflare. All connections between Vercel and our database providers use TLS 1.2 or higher. Access to merchant and customer data is enforced in the application: every query is scoped to the organisation (org_id), and a merchant can only reach its own workspace. We do not rely on database row-level security for this on PlanetScale. Internal GDPR compliance audit logs use service-role-only access and are not merchant-accessible.

Meta Ads (Facebook and Instagram) data deletion

Keel's current Meta Ads sync stores aggregate advertising performance for a merchant's selected ad account: campaign, ad-set, and ad names and identifiers; ad status; spend, impressions, clicks, purchases, and return-on-ad-spend figures; and related aggregate snapshots and classification tags. These records are merchant business data, not end-consumer data.

We do not collect or store Meta, Facebook, or Instagram user personal data through the current sync, including Meta user identifiers or the authorizing person's name. We also do not receive or store end-consumer personal data from Meta Ads.

Keel does store one credential for the connection: the Meta system-user access token issued when a merchant connects. It is encrypted at rest, is used only to read insights for the one ad account the merchant selected, and is never shown in the dashboard. Disconnecting Meta Ads in Settings deletes the token.

Meta-derived aggregate records are retained indefinitely while there is no user-facing retention control. To request deletion of data associated with a Meta Ads connection, email privacy@keelhq.io with the connected ad account's details. We will respond within 30 days.

Google Ads data

When a merchant connects Google Ads, Keel receives an OAuth token and reads the selected account's daily aggregate spend, conversion value, currency, account identifier, and account name. We use this information only to calculate platform ad spend, MER, CM3, and related financial views. We do not receive Google Ads end-user profiles, search queries, or customer data through this integration. OAuth tokens are encrypted at rest and are never exposed in the dashboard.

Who we share data with

We use a small set of third-party service providers to operate the site:

• Google — Google Ads is a merchant-authorized data source. Google processes the OAuth authorization and provides the selected account's aggregate advertising metrics described above.
• Vercel — web hosting and server logs.
• Supabase — Supabase holds a read-only copy of our database from before 23 October 2026, kept only as a rollback safeguard. It receives no new data and is scheduled for deletion. The copy includes the waitlist emails, merchant order data, and customer email fields described for PlanetScale below. Data is encrypted at rest (AES-256) and in transit (TLS 1.2+). Supabase operates under its own DPA.
• PlanetScale — our production database since 23 October 2026: managed Postgres hosting and backups for the waitlist emails, merchant order data, customer email fields synced from connected Shopify stores, and account and sign-in records. Data is encrypted in transit (TLS 1.2+) and at rest, and is hosted in the United States (AWS us-east-1). Access to merchant and customer data is enforced in the application: every query is scoped to the organisation (org_id), and a merchant can only reach its own workspace. We do not rely on database row-level security for this on PlanetScale.
• Fathom Analytics — anonymous page-view analytics.
• Cloudflare — bot protection for waitlist forms through Turnstile, which processes client signals to distinguish people from automated abuse; encrypted, off-site database backup storage through Cloudflare R2, which receives only backups encrypted before upload; and file storage through Cloudflare R2 for merchant-uploaded logos, custom fonts, profile avatars, and bug-report screenshots, which may contain whatever those files show. Logos, fonts, and avatars are publicly served from our files domain; bug-report screenshots are private and reachable only by authenticated staff through short-lived links. R2 encrypts stored objects at rest. Files copied from Supabase Storage during the migration remain there until we retire it.
• PostHog — product analytics and error tracking for the Keel HQ app, never for these marketing pages. PostHog receives your user and organization identifiers, your role, the page paths you visit with query parameters stripped, Core Web Vitals, a named event when you take certain actions (signing up, signing in, signing out, connecting an integration, generating or publishing a report, asking the AI assistant a question, reaching your AI spend cap, a scheduled job sending you an AI-spend alert, completing a key action in a section of the app, seeing an empty “no data yet” screen, a failed integration connection, sending a team invitation, and sending a bug report), metadata describing each of those actions (which month a report covers, which integration, which sign-in method, an internal record identifier, which section and kind of action, which empty screen and why, an error status, the invited role — never the invitee's address), figures about your AI usage attached to those events (AI provider, model, token counts and cost per assistant question; configured cap or threshold, month-to-date AI spend, and alert recipient count), and the stack traces of errors — including errors from the server-side and scheduled processes we have instrumented, recorded against the workspace or against your user identifier depending on which the failing process had in scope. Never your email address, never your customers' data, never revenue figures. Session replay and automatic click tracking are both disabled in our code. Data is stored in PostHog's US cloud.
• Basecamp — internal team notifications. When you join the waitlist, your email address is posted to a private Basecamp Campfire room so the team is notified in real time. The address is not stored by Basecamp beyond the message.
• Anthropic — AI features in the Keel HQ app, for workspaces that use Anthropic (the default; a workspace picks one AI provider in Settings → AI). Anthropic receives (a) aggregate business metrics such as revenue totals, inventory levels, forecast data, and Meta Ads performance (spend, return on ad spend, and per-ad recommendations, including ad and campaign names) for the AI-assistant surface, (b) merchant-uploaded documents such as debt-statement screenshots for the debt-extraction feature, (c) merchant-provided creative and marketing inputs — the product, format, hook, and objective fields you enter in Ads Studio, and the topic and brand-voice rules you configure for carousel generation — (d) campaign history such as your flash-sale send records for flash-sale analysis, and (e) the full monthly-report dataset — aggregate revenue, margin, and customer metrics plus product, inventory, email, and paid-ads report sections (including product and campaign names) — for the automated monthly-report narrative. These app-supplied data flows never include Shopify customer PII — customer email addresses, names, and addresses are not sent to Anthropic. Note that free-text prompts you type into the AI assistant are forwarded to Anthropic verbatim, so avoid pasting customer PII (such as a customer's email, name, or address) into chat messages. Anthropic's Enterprise API does not use API request data to train models.
• OpenAI — AI features in the Keel HQ app, for workspaces that choose OpenAI instead of Anthropic in Settings → AI. A workspace uses one AI provider at a time, so each request goes to OpenAI or to Anthropic, never both. OpenAI receives the same categories of data listed for Anthropic above, (a) through (e), and the same limits apply: these app-supplied data flows never include Shopify customer PII — customer email addresses, names, and addresses are not sent to OpenAI. Free-text prompts you type into the AI assistant are forwarded to OpenAI verbatim, so avoid pasting customer PII into chat messages. Keel HQ sends every request with OpenAI's response storage turned off. OpenAI does not use API data to train its models, and keeps API abuse-monitoring logs for up to 30 days.
• Help Scout — in-app support widget (Help Scout Beacon) for signed-in users. On every signed-in dashboard load, your account email address and display name are sent to Help Scout to identify you — so support replies reach you and your conversation history is attached to your record — not only when you open the widget. Only loaded on authenticated app surfaces, and only when the Beacon is configured for the environment.
• Resend — delivery of account and product emails: Supabase Auth emails (sign-up confirmation, workspace invites, password resets, magic-link sign-in, and email-change confirmations), the welcome email, workspace-invitation emails to existing accounts, and the AI-usage spend alert sent to workspace owners and admins. Resend receives the recipient's email address and the message content needed to send those emails from no-reply@mail.keelhq.io. Resend also holds our product-update contact list, only for people who opt in: when you tick “Email me product updates (about once a month). Unsubscribe anytime.” while requesting demo access, creating an account, or accepting a team invitation, Resend stores your email address and subscription to the “Product updates” topic. For account holders, Keel also records the choice, its source, when it was made, and the copy version they saw. Leave the box unticked and your address is never sent to Resend for product updates. You can turn updates on or off in Profile → Email preferences, or use the unsubscribe link in every update. Product updates are sent fromhello.keelhq.io, separately from transactional mail on mail.keelhq.io. Data is processed in the United States.
• Stripe — subscription billing for workspaces that sign up directly with Keel. Stripe receives the billing contact and payment, tax, and invoice details needed to create subscriptions, collect payment, calculate applicable tax, and provide the customer billing portal. Keel does not store card numbers.
• GitHub — bug-report intake. When a signed-in user submits an in-app bug report, the reporter's email address, the description they wrote, the page URL, and browser context (user agent, screen and viewport size, platform, language) are filed as a GitHub issue in our private tracker so the team can triage it. If you attach an optional screenshot, the image is stored with Cloudflare R2 (including screenshots copied from Supabase during the R2 cutover). Issue links for R2 screenshots require staff authentication. Screenshots uploaded before the cutover also remain in Supabase's public bucket, so links already embedded in older issues may be accessible to anyone with the link; avoid capturing customer PII. Only used when bug reporting is configured for the environment.

Each provider acts as a sub-processor under their own privacy policies, linked above. We do not share your data with anyone else. We do not sell your email address. We do not share it with advertisers. We do not transfer it for cross-platform behavioral profiling.

How long we keep it

• Waitlist email addresses: until Keel HQ launches to general availability. At that point we'll send you an opt-in to continue receiving updates, and remove your address if you don't opt in.
• Merchant order data and customer emails: active while the shop's Shopify integration is connected. On app uninstall, all storefront-scoped Shopify data (orders, customers, inventory, sales snapshots) is deleted within 30 days of Shopify firing the shop/redact webhook (Shopify fires it 48 hours after uninstall). Org-scoped derived data such as historical monthly reports and product-meta rollups is retained indefinitely because it is aggregated/derivative business data, separate from Shopify's storefront rows. There is currently no user-facing retention control for these tables; email privacy@keelhq.io to request deletion. Per-customer deletion requests (customers/redact) are fulfilled within 30 days — the customer_email field is nulled on all matching order rows. A GDPR compliance audit log entry is retained indefinitely, containing the customer's original email address, the shop domain, the customer identifier, and a timestamp. This log is service-role-only, not merchant-accessible, and exists solely to prove we processed the redaction request; issue #496 tracks migrating it to a hashed identifier for a stronger privacy posture. When Shopify fires a customers/data_request webhook, we likewise retain a GDPR compliance audit entry indefinitely in gdpr_data_requests, containing the customer's email address, a timestamp, and the webhook payload. It is service-role-only, not merchant-accessible, and exists solely to prove we processed the request — the same posture as the customers/redact audit log described above. Supabase PITR backups expire on a 7-day rolling window.
• Product-update contacts: if you opted in to product updates through demo access, sign-up, or your profile, your email address and topic subscription are kept as a Resend contact (tagged with the capture source) until you unsubscribe or ask us to remove it. Unsubscribing from the link in any update, or turning it off in Profile → Email preferences, stops the emails; email privacy@keelhq.io to have the contact deleted. If you didn't opt in, the address you enter lives only in the signed demo-access cookie in your own browser (7 days); we don't store it.
• Help Scout support records: your Help Scout customer profile (email address and display name) and conversation history are retained for the life of your active workspace and for up to 24 months after account deletion, so we can reference past support history. Email privacy@keelhq.io to have your Help Scout profile and conversations deleted sooner.
• Bug reports: the GitHub issue created from an in-app bug report — and any screenshot linked from it in the bug-screenshots storage bucket — is retained indefinitely as part of our engineering history. On request we will redact the reporter's email address from the issue and remove the attached screenshot from the storage bucket; email privacy@keelhq.io.
• Server logs: retained by Vercel per their data-retention defaults (around 30 days).
• Analytics events: Fathom aggregates events and does not retain individual session data. PostHog product events and error reports from the signed-in app are retained on the retention schedule of our PostHog plan, per PostHog's data-storage policy. Email privacy@keelhq.io to have the PostHog records tied to your user identifier deleted.

You can ask us to delete your waitlist entry at any time — see “Your rights” below.

Your rights

You can:

• Access — ask what data we have about you.
• Correct — ask us to fix any inaccuracy.
• Delete — ask us to remove personal data we hold about you, including your waitlist entry, your product-update contact, your Help Scout support profile and conversations, and the email address on any bug report you filed (along with its screenshot). See “How long we keep it” above for what applies to each.
• Opt out — unsubscribe from any future communications.

Send a request to privacy@keelhq.io. We will respond within 30 days.

If you're in the EU, EEA, or UK, the same rights apply under GDPR, plus a right to object to processing and to data portability.

If you're a California resident, the same rights apply under the CCPA / CPRA.

Cookies

The marketing site (keelhq.io) sets no cookies. Fathom Analytics is cookieless, and we don't load third-party advertising or social-media scripts that set cookies.

The Keel HQ dashboard (app.keelhq.io) sets HTTP-only session cookies via Supabase Auth when you sign in. These are strictly necessary to keep you authenticated and can't be disabled while using the app — they don't track your browsing behavior across sites.

The dashboard also stores a PostHog analytics identifier in your browser's local storage (not a cookie) so product events from the same browser can be grouped into one session. It is confined to app.keelhq.io and is not readable by any other site. Clearing your browser's site data for the app removes it. Signing out clears it, and if a different account signs in on the same browser it is replaced rather than reused — so two people sharing a computer are never joined into one analytics profile.

International data transfers

Lindahl LLC, doing business as Lindahl Studios, is based in the United States. If you submit your email from outside the US, your data is transferred to and processed in the US by our sub-processors listed above. Each sub-processor has its own data-transfer agreements that comply with EU/UK adequacy frameworks.

Children

Keel HQ is a B2B product for adult business operators. We do not knowingly collect data from anyone under 16. If you believe a child has submitted information to us, email privacy@keelhq.io and we'll delete it promptly.

Requests from public authorities

If a court, regulator, or other public authority asks Lindahl LLC for data, we will:

• Review each request for legal validity before we respond.
• Challenge requests we think are unlawful or overbroad.
• Disclose only the minimum data the law requires.
• Keep a record of each request, its legal basis, our response, and who handled it.
• Tell the affected merchant, where the law allows.

Questions about this section: privacy@keelhq.io

Changes to this policy

We may update this policy as we add features or services. When we do, we'll change the “Last updated” date at the top. For material changes, we'll notify waitlist subscribers by email.

Contact

Questions about this policy or your data: privacy@keelhq.io

For the legal terms governing your use of this site, see our Terms of Service.