Privacy & Data Handling
AppRefer is designed for privacy-first attribution. No IDFA required, no third-party SDKs, and all PII is hashed on-device.
No IDFA Required#
AppRefer does not use or request the Identifier for Advertisers (IDFA). Attribution works without the App Tracking Transparency (ATT) prompt.
On-Device Hashing#
All personally identifiable information (PII) is SHA256-hashed on the device before being transmitted to the AppRefer server. The server never receives raw PII.
| Field | Pre-Hash Format | Hash Input |
|---|---|---|
| user@example.com | SHA256(lowercase(trim(email))) | |
| Phone | +14155551234 | SHA256(E.164 format number) |
| First Name | John | SHA256(lowercase(trim(name))) |
| Last Name | Doe | SHA256(lowercase(trim(name))) |
| Date of Birth | 1990-01-15 | SHA256(YYYYMMDD) |
The same hashing is applied before forwarding to ad networks (Meta CAPI, Google Ads, TikTok), which require hashed PII for Advanced Matching.
IP Address Handling#
IP addresses are not retained long-term. Click records expire after 30 days.
Data Retention#
| Data Type | Retention | Purpose |
|---|---|---|
| Clicks | 30 days | Click-to-install matching |
| Attributions | 400 days | Device-to-campaign mapping (covers annual subscription renewals) |
| SKAN Postbacks | 90 days | Apple SKAN postback validation |
| Audit Log | 365 days | Compliance audit trail |
| Retry Queue | 30 days | Failed ad network forward retries |
| Webhook Events | 30 days | Webhook deduplication |
| Qualified Trials | 30 days | Trial qualification tracking |
Data is automatically expired via TTL policies. Historical analytics data persists for dashboard reporting.
Sandbox Isolation#
Events from pk_test_ keys are completely isolated from production. Sandbox events:
- Are never forwarded to ad networks
- Do not appear in production dashboard views
- Have separate attribution matching
- Can be freely used for testing without affecting real data
No Third-Party SDKs#
Both the Flutter and iOS AppRefer SDKs have zero external dependencies. No third-party code runs inside the SDK -- only standard platform networking and cryptography APIs are used. This eliminates supply chain risk and ensures full control over what data leaves the device.
Erasing a User (Account Deletion)#
When someone deletes their account in your app, your server calls POST /api/v1/apps/{appId}/users/erase with an organization API key that has the users:erase scope. Send { requestId, appUserId, deviceIds? }: the requestId is your deletion job id (8–64 characters; retries with it are safe and get 202 again, and reusing it for another user returns 409). AppRefer finds the user's devices itself, from setUserId and purchase events. A device id you send counts only when AppRefer already links it to that user.
It removes the user's attribution records, queued conversions, pending trials, support conversations and AppRefer Billing identity at once, and answers 202. Warehouse rows follow within a few hours, once BigQuery allows changes to recent rows. Rows that carry revenue are kept for your reports, with the user replaced by a one-way stand-in. Check progress with GET /api/v1/apps/{appId}/users/erase/{requestId}. App settings, links and integrations are never touched. Conversions already sent to ad networks can't be recalled.
Your Data, Secured