AAdback Docs

Reference

SDK privacy and data collection

The SDK is attribution-focused. It collects a narrow allowlist for install matching and event delivery, and avoids default advertising ID or behavioral surveillance collection.

Allowed SDK data

The SDK sends only the data needed to register installs, run attribution matching, return attribution params, and deliver customer-triggered events.

  • SDK key, install_id, adback_id, platform, bundle/package, app version/build, SDK version, event_id, and timestamps.
  • OS version, runtime/kernel version when available, locale, timezone, device family/model, screen dimensions, screen scale, and WebKit/browser engine version when available.
  • Android Play Install Referrer metadata when available.
  • Apple AdServices token only when Apple Ads attribution is enabled.
  • customer_user_id and user_match_data only when the app developer explicitly supplies them.

Not collected by default

Adback is not a behavior-surveillance SDK.

  • No IDFA by default and no ATT prompt from Adback.
  • No precise location, contacts, photos, clipboard contents, installed-app list, serial number, IMEI/MEID, MAC address, Android ID, OAID, or carrier identifiers.
  • No automatic screen view, tap, email, phone, name, or date-of-birth collection.
  • No SDK-side purchase, subscription, StoreKit transaction, or manual revenue APIs in the MVP.

Retention and redaction

Raw high-entropy match inputs and direct user match values should not become durable dashboard data.

  • The backend derives internal match signatures and returns only safe trace handles by default.
  • Raw Apple AdServices tokens are short-lived and not persisted.
  • Raw user match data is redacted from logs, traces, dashboard output, and normal error payloads.
  • If raw match values must survive queue/retry, they should be encrypted with short retention and normalized hashes kept long term.