--- title: Privacy and data handling description: What Dashies stores, how analytics work for you and for people who open your dashboards, and what deletion actually removes. updated: 2026-09-20 --- The [privacy policy](https://dashies.ai/privacy) is the governing document. This page explains the parts with a technical shape, so that the policy does not have to and so that the two cannot drift apart by both saying it. ## What Dashies stores about you Your account details, and the dashboards you publish. The dashboards are the interesting half, because a Dashies dashboard is a **materialized artifact**: its numbers come out of a copy we hold rather than out of a query re-run per view. So what we hold is not only metadata about your dashboards, it includes the results of the queries behind them. What that copy is follows from the shape of the statement: on a dashboard whose rows we hold the statement returns one row per underlying record, so the copy is those records rather than a summary of them. The reasoning, and what it means for how you write the statement, is in [the security model](/trust#dashies-holds-a-copy-of-your-numbers). Alongside them we keep the operational records that make the product work: version history, refresh run outcomes, and the administrative audit trail. Those are covered under [retention](#retention) below. The policy states plainly that we do not sell your data and **do not use it to train AI models**. The contents of your dashboards stay yours, and are never sent to an analytics provider. ## Analytics, and the people who open your dashboards Dashies uses **PostHog** for product analytics: pageviews, feature usage, and coarse signals like device type, browser, and approximate location. PostHog is a third-party processor, it processes in the United States, and it works for us under a signed data processing agreement. For visitors in the UK, EU and EEA that transfer relies on PostHog's certification under the EU-US Data Privacy Framework and on Standard Contractual Clauses. Three properties matter more than the list: - **We never send the contents of your dashboards, the SQL behind them, or anything from a connected warehouse.** What goes to PostHog is counts and shapes: which feature was used, how many datasets a dashboard has, whether a refresh succeeded. This is enforced in the type system rather than by convention, so an event carrying customer data does not compile. - **Your IP address is not stored.** Approximate location is derived from it when the event is received, and the address itself is discarded. - **A Global Privacy Control or Do Not Track signal is honored**, on the app and on shared dashboards alike, as is declining the in-app consent banner. When any of those is present, nothing is collected at all: no event, no identifier, no device, no location. Be precise about identity, because it is the one place we are less anonymous than we used to be. If you are **signed in**, your events carry your account identifier and email so we can support you, and that identifier is durable rather than daily-rotating. If you are **not signed in**, no person profile is created for you at all. Be precise about what honoring those signals leaves behind. **An aggregate view counter still increments.** It records that a dashboard was opened, and nothing about who opened it, so there is no per-visitor identifier to suppress. If your requirement is "no identifiers", that is met. If it is "no signal of any kind reaches the server", it is not, and a count of one is still a count. Inside the app, consent is asked for on a first visit and can be declined. **Views of a dashboard you shared honor the same signals.** This is the part worth knowing before you send a workspace dashboard's link to the rest of the team: the people who open it are **counted, not identified**. A visitor signalling a privacy preference drops out of the identified half entirely, and still lands in the count. One record does name the reader, and it is worth separating from the sentence above rather than leaving you to notice it: **each person has their own list of the dashboards they have opened**, which the app will use to show you the ones you keep coming back to. It is one entry per dashboard rather than a log of every visit, and it is readable by that person and by nobody else - not by the dashboard's author, not by a workspace administrator, and not by us through any product surface. It is enforced by a row-level policy keyed to the reader's own account rather than by a convention about who looks. It is deleted with their account, it can be removed on request, and a Global Privacy Control or Do Not Track signal or a declined banner stops it being written at all - like the identified analytics above, and unlike the aggregate counter, which still increments because it names nobody. The consequence for you as an author is unchanged by that: **Dashies does not give you per-viewer analytics on a shared dashboard**, and that is a design decision rather than a missing feature. There is no viewer list, and there is no way to find out who opened a link. The per-person list above is the reader's, not yours, and there is no surface anywhere that turns it around. ## Retention Dashies deletes very little on a timer. Two things are worth knowing. **Version history is capped.** The most recent 20 unlabelled autosaves are kept per dashboard, and older ones are pruned. A labelled version is never pruned, and a dashboard can hold up to 30 of them. See [Version history](/guides/version-history). **Audit and activity records have no expiry.** The workspace audit log, your dashboard activity feed, and refresh run history are kept for the life of the thing they belong to. There is no retention window to configure and no automatic purge. That makes deletion, not time, the thing that removes them. ## What deletion removes **Deleting a workspace** removes its audit log with it, permanently and with no export. If you need the record of a workspace you are winding down, read it first. See [Audit log](/admin/audit-log#retention). **Deleting a dashboard** is a soft delete: the activity feed records the deletion as a final entry, and further changes to it stop being recorded. **Deleting your account** removes the operational records tied to you personally, including your dashboard activity feed, your refresh alert history, and the record of your AI tool's connections. One deliberate exception: entries in a **workspace's** audit log survive, with the names they were written with. A workspace's history of who was invited, promoted, and removed does not develop gaps when someone leaves, which is the behaviour an audit trail has to have to be worth keeping. :::note{title="Deleting your account"} **Settings > Account > Delete account.** Before you confirm, the screen shows what the deletion removes and what survives it, including which of your workspaces get a new admin and which would be left with no members at all. It is immediate and there is no undo. The one thing that stops it is a workspace you are the only member of that is still on a paid plan, because deleting your account would leave that workspace with a plan nobody can manage or cancel. Switch to that workspace and cancel the subscription first, then delete your account. ::: ## Where to go next - [The security model](/trust) - what Dashies can and cannot see, and who can read a published dashboard. - [Warehouse credentials](/trust/warehouse-credentials) - handled differently from everything on this page. - [Dashboard isolation](/trust/dashboard-isolation) - what a published dashboard can and cannot reach.