How to Handle
Data Deletion Requests
A developer's guide to handling user erasure requests when your app uses Respectlytics analytics
This is not legal advice
This guide is provided for educational and technical purposes only. Privacy regulations vary by jurisdiction, app category, and user base. Consult your legal team to determine your specific obligations regarding data deletion requests.
1. Do I need to delete analytics data?
When a user asks you to delete their data, you need to consider: does the analytics data in Respectlytics qualify as "their data"?
event_name— e.g. "button_clicked"session_id— anonymous, rotates every 2htimestamp— when the event occurredplatform— ios, android, webcountry— derived from IP, IP discarded
- No user IDs or account identifiers
- No device IDs (IDFA, GAID, IDFV)
- No email addresses or names
- No IP addresses (discarded after geo-lookup)
- No persistent cookies or device storage
The bottom line: Respectlytics cannot determine which analytics entries belong to which person. It is technically impossible for us to fulfil a per-user deletion request on our side, because we have no way to identify which rows are "theirs." This is by design — our Return of Avoidance (ROA) principle means we avoid collecting the data that would make such identification possible.
2. When deletion may still be appropriate
While Respectlytics cannot identify users, you — as the app developer — potentially can. Here's how:
Cross-referencing scenario: If your own database records show that user "Alice" signed up on January 15, uses iOS, and is located in Germany, you could narrow down analytics entries by those filters. The matching entries might include Alice's activity — along with events from other users who share those characteristics.
The larger your user base, the harder this correlation becomes, and the more other users' data falls within the same filters.
Some legal teams may determine that:
- → The analytics data is sufficiently anonymous and no deletion from Respectlytics is required
- → A best-effort deletion using available filters is appropriate to be thorough
- → The over-deletion trade-off is acceptable — deleting more than needed is better than deleting less
⚖️ Over-deletion is the safer path. When filter-based deletion removes entries belonging to other anonymous users alongside the requesting user's data, this is an acceptable consequence of a privacy architecture that avoids storing personal identifiers. Deleting too much anonymous data is always better than failing to honour an erasure request.
3. Two ways to delete data
Respectlytics provides filter-based deletion through both the dashboard and the REST API. Both methods create an automatic audit trail via a DeletionLog entry and a security event log.
In your app's dashboard, click Delete Events in the sidebar. A modal lets you:
- • Set date range, platform, country, and event name filters
- • Preview the exact count of matching events
- • Type the count to confirm, then delete permanently
- • Charts refresh automatically after deletion
For programmatic or automated workflows, use three API endpoints:
- •
POST /delete/preview/— count matching events - •
POST /delete/— permanently delete them - •
GET /deletions/— retrieve audit trail - • Returns a
deletion_idfor compliance records
Both methods require the same filters and produce the same audit logs. Choose the dashboard for one-off requests, or the API if you need to automate deletion as part of your data subject request workflow.
4. API reference for deletion
All endpoints require authentication via the X-App-Key header (your app's UUID key).
a Preview what will be deleted
Always preview first. This returns the count of matching events without deleting anything.
-H "X-App-Key: your-app-key-uuid" \
-H "Content-Type: application/json" \
-d '{
"date_from": "2026-01-01",
"date_to": "2026-01-31",
"platform": "ios",
"country": "DE"
}'
Available filters
| Parameter | Required | Format | Description |
|---|---|---|---|
date_from |
Yes | YYYY-MM-DD | Start of date range |
date_to |
Yes | YYYY-MM-DD | End of date range |
platform |
No | String | ios, android, web, or other |
country |
No | String | ISO country code (e.g. "US", "DE") |
event_name |
No | String | Specific event name to delete |
b Execute the deletion
Once you've confirmed the scope, execute the deletion. This action is irreversible.
-H "X-App-Key: your-app-key-uuid" \
-H "Content-Type: application/json" \
-d '{
"date_from": "2026-01-01",
"date_to": "2026-01-31",
"platform": "ios",
"country": "DE"
}'
"events_deleted": 1523,
"deletion_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}
c Retrieve the audit trail
Every deletion — whether via the dashboard or API — is logged automatically. Retrieve your full deletion history via the API to document compliance. Use the deletion_id as proof of fulfilment.
-H "X-App-Key: your-app-key-uuid"
"deletions": [{
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"deleted_at": "2026-02-10T14:30:00Z",
"events_deleted": 1523,
"filter_date_from": "2026-01-01",
"filter_date_to": "2026-01-31",
"filter_platform": "ios",
"filter_country": "DE",
"filter_event_name": null
}]
}
5. Understanding over-deletion
Because Respectlytics stores only anonymous session data, filter-based deletion is inherently imprecise. Here's what that means in practice:
Example scenario:
User "Alice" asks you to delete her data. From your own records, you know Alice used your iOS app from Germany during January 2026.
You set filters: date_from: 2026-01-01, date_to: 2026-01-31, platform: ios, country: DE.
This deletes all iOS events from Germany in January — including events from other German iOS users. The more users you have, the more "bystander" data is included.
- • The deleted data is anonymous — no personal impact
- • Over-deletion honours the spirit of the erasure request
- • Aggregate analytics remain meaningful from remaining data
- • Full audit trail documents the action taken
- • No user IDs means no per-user precision
- • Session IDs rotate and cannot be traced across sessions
- • This is a feature, not a limitation
- • You cannot accidentally under-delete if you use broader filters
🔑 Key principle: The reason precise per-user deletion is impossible is the same reason your analytics data is privacy-safe in the first place. You cannot have both perfectly targeted deletion and anonymous analytics — and we chose anonymity. Read more about the over-deletion principle →
6. Recommended workflow
-
1
Receive the deletion request
Document when it was received and what the user is asking for.
-
2
Consult your legal team
Determine if anonymous analytics data falls within scope. If not, you may be done.
-
3
Build your filter criteria
Use your own records to determine date range, platform, and country. Narrower filters reduce over-deletion; broader filters ensure completeness.
-
4
Preview, then delete
Use the preview endpoint or dashboard modal to check scope. When satisfied, execute the deletion.
-
5
Document for compliance
Save the
deletion_idand timestamp. UseGET /api/v1/events/deletions/to retrieve your full deletion history as proof of fulfilment.
Frequently asked questions
Can Respectlytics identify which data belongs to a specific user?
+
No. We store only 5 anonymous fields per event. Session IDs rotate every 2 hours and are hashed server-side with a daily rotating salt.
It is technically impossible for Respectlytics to determine which entries belong to which person. This is by design.
If a user requests data deletion, do I need to delete data from Respectlytics?
+
It depends on your legal team's assessment. Since Respectlytics data is anonymous and cannot be linked to individuals by us, some legal teams may determine that no deletion is required.
However, if you can correlate analytics entries with a specific user using your own records (timestamps, platform, country), you may choose to delete those entries to be thorough.
Consult your legal team to determine your specific requirements.
What if deletion removes other users' data too?
+
This is expected and acceptable. Because Respectlytics uses anonymous session-based data, filter-based deletion may remove entries belonging to other users who share the same time window, platform, or country.
Over-deletion is the safer trade-off: deleting more anonymous data than strictly necessary is always better than failing to delete data associated with someone who requested erasure.
Can I also delete data from the dashboard?
+
Yes. The Respectlytics dashboard includes a Delete Events modal (accessible from the sidebar) with the same filter-based preview and confirm workflow. Every dashboard deletion creates the same audit log as the API.
Use the dashboard for one-off requests, or the API endpoints documented above for programmatic and automated workflows.
What about automatic data retention?
+
All analytics data is automatically deleted after 24 months. If you close your account, all data is purged within 30 days.
You don't need to manage retention — it's handled by our system automatically.
Need the full API documentation?
Legal Disclaimer: This information is provided for educational purposes and does not constitute legal advice. Regulations vary by jurisdiction and change over time. Consult your legal team to determine the requirements that apply to your situation.