Five fields per event. The API refuses everything else.
Respectlytics stores the event name, a rotating session ID, a timestamp, the platform and the country. Any other field is refused, so a user ID or a custom property added by mistake never lands in your analytics.
14-day free trial, no credit card. The demo runs on sample data, no signup.
The five fields
Everything Respectlytics keeps about an event, and why each field is there.
event_name
What happened, such as paywall_viewed. You choose the names.
session_id
Groups the events of one session. The server stores a hash salted with your app and the date, never the ID the app sent.
timestamp
When it happened, so steps can be put in order and timed.
platform
iOS, Android or another platform name, so you can compare them.
country
A two-letter country code, looked up from the IP address. The IP address is discarded right after.
What the API refuses
Checked on every request, before anything is stored.
- Any extra field. A user ID, an email, a device ID or a custom property gets 400 Bad Request, and nothing is saved.
- Session IDs that look like something else. Values shaped like a device ID or a UUID, a plain number, or a numbered ID such as user_123 are refused, so a session ID cannot quietly become a person ID.
- Old fields from old SDKs. app_version, os_version, device_type, locale, region and screen are accepted for compatibility and dropped without being stored.
The one thing the API cannot check
Event names are yours, so keep people out of them.
The API cannot tell whether a name such as signup_completed is safe and a name built from someone's email is not. Name events after actions, keep them to a fixed list, and never build them from user input.
The event schema linter shows, in your browser, which fields of an existing analytics payload a five-field schema would refuse.
Shorter privacy forms, simpler requests
Less data in analytics means less to explain about it.
Your analytics adds a short, explainable list to your App Store privacy label and your Google Play Data Safety form. The privacy label generator and the Data Safety generator walk you through both.
No stored field names a person, so a request to see or delete one person's data has no record in your analytics to point at. The data deletion guide covers how teams answer such requests.
Questions buyers ask
Straight answers, including the ones that might send you elsewhere.
What happens if my app sends an extra field?
The API answers 400 Bad Request and stores nothing. A few fields that older SDK versions sent, such as app_version, are accepted and dropped without being stored.
Can personal data still get in?
Only through the event name, which the API cannot judge. Name events after actions, such as signup_completed, never after people or their details.
How does this help with privacy labels?
Your analytics adds a short, explainable list to your App Store privacy label and Google Play Data Safety form. What you declare overall depends on everything else your app collects.
The other design choices
Each one removes something else from your privacy work.
Try it on your own app
14-day free trial, no credit card. Unlimited apps on every plan.
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.