Collected
- Event name, screen name, timestamp only the events your app explicitly tracks — there is no autocapture
- Event properties you choose to attach you control the contents; the integration rules forbid PII in properties
- One anonymous user ID per app a random UUID, shared with RevenueCat as the app_user_id
- Session ID and session length
- App version, OS version, device model e.g. 2.4.0 · iOS 26.1 · iPhone17,1
- Country from the device's region setting or derived at ingest — the IP address itself is not stored
- Purchase events from RevenueCat trials, renewals, refunds — via webhook, attached to the same anonymous ID
- Apple Search Ads attribution token result via Apple's AdServices framework; campaign-level, no ATT involved
- Feedback a user chooses to send, and an email if they choose to leave one only when your app offers in-app feedback; stored apart from events, never used for tracking
Never collected
- Names, phone numbers, contacts the SDK has no API that accepts them
- Email addresses except one a user types into your feedback form so you can reply
- IDFA — no ATT prompt, ever
- Device fingerprints or cross-app device graphs each app's ID is its own; your users are never tracked across apps
- IP addresses at rest
- Precise location
- Anything typed, photographed, or displayed no session replay, no screen recording, no heatmaps; the one exception is feedback the user writes and sends on purpose
- User-level data from ad networks paid-social measurement is aggregate SKAdNetwork only
- Pasteboard, photos, files, health data — anything outside the list on the left
Where the data lives
In a Postgres database (Supabase) in the EU (Paris). It stays there: your events are yours, exportable on request, deleted on request, and never sold or shared. FolioKit has no advertising business and no data partners — the only consumer of your data is your own dashboard and your Monday brief.
Your users vs you
Two different relationships, worth separating:
- Your end users are anonymous to FolioKit — the columns above. No PII by default, and the integration guide instructs agents to keep it that way.
- You, the developer, connect your own accounts: the RevenueCat webhook pushes purchase events in (one-way — nothing can read or change your RevenueCat account through it), and two optional keys (a read-only RevenueCat key and an App Store Connect Finance key) let FolioKit check who is paying and fetch your own downloads and proceeds. Those keys are stored encrypted on the server, never in your app (how they're stored and revoked).
The landing-page snippet
The optional web snippet for your marketing pages follows the same rules: an anonymous random ID in localStorage, page views, App Store clicks, and campaign parameters. No cookies, no fingerprinting, no personal data.
Crediting installs to a link
When someone taps an App Store link FolioKit gives you (a campaign link, or a store button on a page with the snippet), FolioKit keeps a salted hash of their network address for 3 days. If the app is first opened from the same network within 48 hours, that install is credited to the link. The hash can't be turned back into an address, the address itself is never stored, and the hash is deleted after 3 days.
What we don't have yet
No SOC 2, no signed DPAs, no compliance paperwork yet — FolioKit is a young product built and run by one developer. If your situation requires those documents today, we're not ready for you yet, and we'd rather say so than have you find out later. Questions about any of this: contact@foliokit.io goes straight to the founder.