AppActor treats several kinds of customer data differently. Keep customer profile context separate from attribution.

​
1. Developer custom attributes

Use the custom attribute APIs for app-defined keys like:
  • favorite_category
  • signup_source
  • trial_variant
  • onboarding_persona
Common rules across SDKs:
  • reserved prefixes such as $, appactor., or integration. are not allowed for plain custom keys
  • unsetAttribute() is the explicit delete path for custom fields
  • values must follow the platform’s supported primitive or typed-value contract

​
2. Reserved profile helpers

Use helper methods for AppActor-owned profile fields such as:
  • email
  • display name
  • phone number
  • push token
These are not the same thing as arbitrary custom attributes.

​
3. Integration identifiers

Use integration-ID APIs for external IDs like:
  • AppsFlyer IDs
  • Adjust IDs
  • Firebase app instance IDs
  • custom provider identifiers
These go through their own backend path, not the custom-attribute list.

Integration identifiers and events

See how partner IDs attach to subscription events and downstream integrations.

​
4. Attribution belongs on its own surface

Campaign attribution, Apple Search Ads, and Google Play Install Referrer are separate from plain customer attributes.

Attribution System

Choose the right API for campaign fields, integration identifiers, ASA, and Install Referrer.

​
Device identifiers and privacy

Additional device identifiers are generally opt-in. If your app turns on APIs like collectDeviceIdentifiers() or platform attribution helpers, the docs should also point developers to:
  • the privacy implications
  • the matching App Store privacy disclosure expectations
  • the platform-specific setup order