Privacy policy

pisi.to is a product of Beaglo Labs S.L., registered in Spain, VAT B-00000000. Write to privacidad@pisi.to about anything on this page.

We are a Spanish company and all of the infrastructure lives in the European Union.

Worth separating, because the obligations are not the same.

When someone visits a site measured with pisi.to, the controller is the owner of that site and we are the processor: we process the data on their behalf and on their instructions. The contract for that is the DPA, signed from the dashboard.

When you sign up as a pisi.to customer, we are the controller: we process your email, your name and your billing details to run the service and to keep the tax office happy.

You have it field by field, with examples, on the data page. In short: the URL with no query string except the utm parameters, the referrer, the browser language, the window size, the country, region and city, and the browser, OS and device type derived from the User-Agent.

The IP and the full User-Agent are read in memory, used for the country and for the daily identifier, and discarded. They never reach a table or a log.

Processing rests on the legitimate interest of article 6(1)(f) GDPR: understanding how a website is used is necessary to keep it running, and doing so without identifying anyone is the least invasive way to get there.

We have documented the legitimate interest assessment (LIA) and hand it to any customer who asks. The three legs of it, briefly:

The key writes nothing into a visitor's browser: no cookies, no localStorage, no sessionStorage, no IndexedDB, no fingerprinting cache.

There is exactly one read of localStorage and never a write: the pisito_ignore key, which a flat owner can switch on from their dashboard so their own visits stop counting.

With nothing stored on the user's device, article 5(3) of the ePrivacy directive does not apply: no consent to ask for and no banner needed. On pisi.to itself we do use a session cookie to keep you signed in; that one is strictly necessary.

To count unique visitors we generate a number from a SHA-256 hash of the daily salt, the flat identifier, the IP and the User-Agent, truncated to 64 bits.

The salt is 32 random bytes that rotate every night at 00:00 UTC, and the previous one is destroyed. Without that salt the number cannot be reversed or recomputed, so the same person coming back tomorrow counts as a new visitor.

That is a loss of precision we accept on purpose: it is exactly what makes following someone over time impossible.

Raw events are deleted after 30 days by dropping the whole day's partition. Hourly and daily aggregates are kept for 24 months.

Edge logs do not keep IPs beyond 24 hours, and error logs never include the request body. When you delete a flat it is marked as deleted and fully purged 30 days later.

This list is public and we update it when it changes. All of them process data inside the European Union.

There are no transfers of visit data outside the European Economic Area. Ingest, database and aggregation all sit in the EU.

Stripe and Resend may have administrative access from outside the EEA under the European Commission's standard contractual clauses; in both cases they only touch customer data, never visitor data.

You can exercise access, rectification, erasure, objection, restriction and portability by writing to privacidad@pisi.to. We answer in under 30 days.

You can also complain to the Spanish data protection authority (AEPD) if you think we got it wrong.

Here we have to be honest: we cannot answer an individual access or erasure request, because we cannot tell which of our data would be yours.

We do not store your IP, there is no cookie carrying your identifier, and the number we use to count visitors is computed with a salt that is destroyed every night. There is no field to look you up by, not even if you hand us your own details: the salt for the day you visited no longer exists.

This is not an excuse, it is article 11 GDPR: where the controller cannot identify the data subject, it is not obliged to keep extra information just to be able to. The way not to appear in our data is never to appear identifiably, and that is already solved by design.

They are ignored by default, as Plausible and Fathom do: with no identifiable personal data and no cross-site tracking, there is nothing for these signals to protect against.

Even so, every flat can switch on "respect DNT and GPC" in its settings, and then those visits are not counted.

Everything travels over TLS. Customer tables carry Row Level Security at the database level, not only in the application. API keys are stored hashed. We back up daily and test the restore once a month.

If we change anything meaningful we email customers at least 30 days in advance, and we leave the date of the last update here. We do not change the rules retroactively.