Data subject requests

As soon as a site links visits to people (signed-in visitors or measurement cookie), it must be able to respond to access and erasure requests. eodia analytics handles them site by site.

Finding a person

A request targets a person by one of two things:

• their identity on your side (user_id), if the site accepts signed-in visitors;
• the identifier of their measurement cookie (_eoa), if they are not signed in: they can provide it, and the site can display it on its privacy page.

// Display the cookie identifier on the privacy page
const id = document.cookie.match(/(?:^|;\s*)_eoa=([^;.]+)/)?.[1]

The request also covers matched visits: those from the same cookie before sign-in (see the person).

No cookie, nothing to link

Data measured without a cookie or an identity carries a daily hash, whose salt is destroyed the next day: it is not linked to anyone, and there is nothing to export or erase. If a person makes such a request, that is the answer to give them.

Exporting

An export request gathers all the raw data rows for that person on that site (page views, events, clicks, zones), matched visits included, in a JSON file. It can be downloaded from the request’s page for 7 days.

Erasing

An erasure request deletes the same rows, in batches, as a background task. The number of rows erased is recorded on the request. It is one of only two deletions in the raw data, along with the retention period.

What remains

The request keeps a fingerprint of the identifier, never the identifier itself, its type, its status, the number of rows and its dates. The audit log records who made it.

Three ways to make a request

From the screen: Site settings › Personal data › New request. The list shows the status of each one.

Through the API, with an eoa_… integration token:

curl -X POST https://stats.example.com/api/v1/sites/$SITE_ID/privacy-requests \
  -H "Authorization: Bearer $EODIA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "kind": "export", "user_id": "client-1042" }'

kind is export or erase; one of the two, user_id or visitor. The export is then downloaded at GET /api/v1/sites/:id/privacy-requests/:request/export.

With the site’s sending key, to connect the requests received by your site directly:

curl -X POST https://stats.example.com/collect/server/erase \
  -H "Authorization: Bearer $EODIA_SERVER_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "visitor": "3f9c0d2e8b7a4c1d9e0f1a2b3c4d5e6f.20260912" }'

The sending key can only erase, not export: it never has the right to read.

What about eodia insights?

The views read the raw data: an erased row disappears from the views, and therefore from insights, at the next query. A result cached by insights may survive until it expires.