Mobile App Events

When events are sent from the Datafly mobile SDKs (iOS, Android, React Native, Flutter, etc.), the server-side pipeline automatically detects the source platform and adjusts vendor payloads accordingly. No separate integration configuration is needed — the same blueprints work for both web and mobile events.

How platform detection works

Every event includes a context.library.name field that identifies which SDK sent it:

SDK	`context.library.name`	Platform
Datafly.js (web)	`@datafly/collector`	Web
iOS SDK	`@datafly/ios`	Mobile app
Android SDK	`@datafly/android`	Mobile app
React Native	`@datafly/ios` or `@datafly/android`	Mobile app
Flutter	`@datafly/ios` or `@datafly/android`	Mobile app

Cross-platform SDKs (React Native, Flutter, .NET MAUI, Cordova, Capacitor) delegate to the native SDKs, so the library name reflects the underlying native platform.

Vendor-specific behaviour

Meta Conversions API

Meta CAPI requires an action_source field on every event. The default blueprints automatically set this based on the source:

Source	`action_source`
Datafly.js	`website`
iOS / Android SDK	`app`

This is configured in the blueprint via a value_map on context.library.name:

source: context.library.name
target: action_source
default_value: website
value_map:
  "@datafly/ios": app
  "@datafly/android": app
  "@datafly/collector": website

You can override this in your blueprint to use a different detection strategy (e.g., based on user agent or custom properties).

TikTok Events API

TikTok requires an event_source field. The default blueprints set this automatically:

Source	`event_source`
Datafly.js	`web`
iOS / Android SDK	`app`

Pinterest Conversions API

Pinterest uses action_source with the same auto-detection:

Source	`action_source`
Datafly.js	`web`
iOS / Android SDK	`app`

Snapchat Conversions API

Snapchat uses action_source with values WEB and MOBILE_APP:

Source	`action_source`
Datafly.js	`WEB`
iOS / Android SDK	`MOBILE_APP`

GA4 Measurement Protocol

GA4 processes web and mobile events identically via the Measurement Protocol. No action_source field is needed. Mobile-specific context (device model, OS version) is automatically included in the event payload via the mobile SDK’s context enrichment.

Customising platform detection

The action_source / event_source field is fully configurable in blueprints. You are not limited to the default context.library.name detection. Some alternatives:

By event type

source: type
target: action_source
value_map:
  screen: app
  page: website
  track: website

By user agent

Use a conditional mapping when you need fine-grained control:

source: context.user_agent
target: action_source
condition: "context.user_agent CONTAINS 'DataflySignal'"
mode: static
value: app

By custom property

If your app sends a platform property:

source: properties.platform
target: action_source
value_map:
  ios: app
  android: app
  web: website

The blueprint’s field mapping always takes priority. If a blueprint sets action_source, that value is used. The delivery worker’s fallback detection (based on context.library.name) only applies when the blueprint doesn’t explicitly map the field.

Mobile device identifiers

The mobile SDKs automatically collect device identifiers that are included in the event context:

Identifier	iOS	Android	Available in blueprints
IDFV	`context.device.idfv`	—	Yes
ANDROID_ID	—	`context.device.android_id`	Yes
IDFA	`context.device.advertising_id`	—	Yes (after ATT consent)
AAID	—	`context.device.advertising_id`	Yes (after consent)
Device model	`context.device.model`	`context.device.model`	Via user agent
OS version	`context.device.os_version`	`context.device.os_version`	Via user agent

Attribution integrations

For mobile app attribution, Signal already supports server-to-server delivery to:

AppsFlyer iOS — with SKAdNetwork support
AppsFlyer Android — S2S event API
Adjust — mobile attribution (beta)
Kochava — mobile attribution

Same blueprints, both platforms

The key principle is that the same blueprint handles both web and mobile events. You don’t need separate integrations or pipelines for mobile. The context.library.name value_map handles the platform-specific differences automatically.

If you have a use case that requires completely different event mappings for mobile vs web, you can create separate pipeline integrations with filter expressions:

# Mobile-only integration
filter: "context.library.name = '@datafly/ios' OR context.library.name = '@datafly/android'"
 
# Web-only integration
filter: "context.library.name = '@datafly/collector'"

Overview Meta Conversions API (CAPI)