Rovenue SDK
Integrations

Subscriber Identity Attributes

Reserved subscriber attributes for third-party vendor ids (AppsFlyer, Adjust, Firebase, Mixpanel, Amplitude, OneSignal, Braze, Iterable, Airbridge, Singular) used to resolve identity across outbound integrations.

Subscriber Identity Attributes

Rovenue reserves a set of $-prefixed subscriber attribute keys for well-known identity and attribution fields. Reserved keys are validated on write (each value is capped at 500 characters) and are available to outbound integrations for identity resolution.

Set them the same way as any other attribute, via the SDK's setAttributes call or from your backend by calling POST /v1/subscribers/:appUserId/attributes with your secret key (the path segment is your app user id, or the device's rovenueId).


Vendor-id attributes

These six keys mirror the reserved attribute names used by RevenueCat, so a migration from RevenueCat can carry the same attribute keys over unchanged:

KeyPurpose
$appsflyerIdAppsFlyer's device-level appsflyer_id, used to attribute revenue back to an AppsFlyer campaign.
$adjustIdAdjust's adid device identifier, used to attribute revenue back to an Adjust campaign.
$firebaseAppInstanceIdFirebase/Google Analytics' app_instance_id, used to join subscriber events with a Firebase Analytics or BigQuery export.
$mixpanelDistinctIdMixpanel's distinct_id, used to associate revenue events with an existing Mixpanel user profile.
$amplitudeDeviceIdAmplitude's device_id, used to associate revenue events with an anonymous Amplitude device profile.
$amplitudeUserIdAmplitude's user_id, used to associate revenue events with an identified Amplitude user.

All six accept any non-empty string value up to 500 characters — Rovenue does not validate vendor-specific id formats.

These five keys extend the same convention to the Wave-2 outbound integrations (OneSignal, Braze, Iterable, Airbridge, Singular):

KeyPurpose
$onesignalIdOneSignal's internal user id (OneSignal ID), obtained via OneSignal.User.onesignalId, used to target push notifications for this subscriber.
$brazeAliasNameBraze's alias name, used to resolve this subscriber to an existing Braze user profile without an external user id.
$iterableUserIdIterable's userId, used to associate revenue events with an existing Iterable user profile.
$airbridgeDeviceIdAirbridge's device identifier, used to attribute revenue back to an Airbridge campaign.
$singularDeviceIdSingular's device identifier, used to attribute revenue back to a Singular campaign.

All five accept any non-empty string value up to 500 characters — Rovenue does not validate vendor-specific id formats.


Advertising ids

KeyPurposeLeaves Rovenue toward an integration
$idfaApple's Identifier for Advertisers.Only when $attConsentStatus is authorized.
$attConsentStatusApp Tracking Transparency status: notDetermined, restricted, denied or authorized (any other value is rejected on write).Read by the gate, and sent to Singular as att_authorization_status.
$gpsAdIdGoogle's Android advertising id.Never. No Rovenue SDK or API carries an explicit Android opt-in or "limit ad tracking" signal.
$idfvApple's identifier for vendor. It is not an advertising id.No integration sends it.

Advertising ids are default-deny: an ad id travels only with an explicit authorization signal. A missing status (the ATT prompt was never shown, or an older app build never reported it), notDetermined, restricted and denied all keep $idfa inside Rovenue. ATT is an iOS permission, so an authorized status does not let $gpsAdId through. The ids are still stored on the subscriber and appear in its data export. They are removed only from integration deliveries. To keep attributing users without an advertising id, set the attribution vendor's own device id ($adjustId, $singularDeviceId, $appsflyerId, $airbridgeDeviceId).


Notes

  • Setting a vendor-id attribute does not, by itself, forward any data anywhere — it only makes the id available for integrations (such as the Wave-1 AppsFlyer/Adjust/Firebase/Mixpanel/Amplitude outbound integrations) to read when resolving a subscriber's identity on the destination platform.
  • An unrecognised $-prefixed key is still treated as reserved and rejected, so typos in a vendor-id key name fail the write instead of being silently stored as an unknown attribute.
  • Subscriber attributes deliberately never appear in outbound webhook payloads — vendor ids and other attributes are read only at delivery time, by the integrations that need them. See Outbound Webhooks for the PII-free payload contract that keeps them out.

On this page