Digital Intelligence SDK FAQs

Digital Intelligence SDKs do not collect or expose hardware identifiers such as IMEI, SIM, or eSIM information.

• No IMEI or SIM/eSIM identifiers:
  Modern iOS and Android platforms restrict access to these identifiers. As a result, our SDKs neither collect nor expose SIM/eSIM details, and IMEI is not collected.

• No hardware MAC address:
  Mobile operating systems and modern browsers obfuscate or block access to hardware MAC addresses. Our SDKs therefore do not collect or expose a device’s hardware MAC. Instead, our signals rely solely on OS-permitted attributes to ensure privacy compliance and reliable device intelligence.

Each SDK platform (iOS, Android, Web) has access to different operating system APIs and browser capabilities. For example:

• Native mobile SDKs (iOS and Android) can access GPS, battery status, VPN state, and CPU architecture through OS-level APIs.
• The Web SDK collects browser-specific signals such as WebRTC IPs, user agent strings, WebGL renderer details, and HTML form submission events.

Because these capabilities are inherent to each platform, certain fields are only populated when the session originates from a compatible SDK. Server-side fields (network analysis, history, entity profiling, and velocity metrics) are always available regardless of the client platform.

Refer to the Data Dictionary platform availability section for a complete field-by-field breakdown.

WebRTC is a browser API that enables peer-to-peer communication and can reveal the user's real IP address even behind a VPN or proxy. Native mobile SDKs for iOS and Android do not use WebRTC, so these fields are only populated for sessions captured by the Web SDK.

For mobile sessions, use the device.network.connectionIp and device.network.realIp fields, which are available on all platforms.

The device.attributes.network.vpnStatus field relies on native OS APIs that report whether a VPN connection is active. Browsers do not expose this information to web applications.

For web sessions, use the server-side network analysis fields (device.network.isVpn, device.network.isProxy, device.network.isConsumerPrivacy) to detect VPN and proxy usage through IP reputation analysis. These fields are available on all platforms.

The device.computed.isTamperedAndroidBuild field detects whether the Android OS build differs from the manufacturer's original version (for example, custom ROMs). This check is specific to the Android operating system and has no equivalent on iOS or Web.

For iOS, jailbreak detection is available through device.attributes.iOSAttributes.isRooted. For web sessions, use device.computed.isVirtualMachine and behavioral signals to assess session integrity.

Location and battery data require specific conditions to be collected:

• Location requires explicit user permission. If your app hasn't requested location access or the user has denied it, these fields are omitted. You can suppress location collection by setting omitLocationData to true in SigmaDeviceOptions.
• Battery data depends on device state and OS-level access. In rare cases, the OS may restrict battery information.

Missing fields do not indicate an SDK error. Design your workflows to handle optional fields gracefully.

The behavioral.aggregations.submissionCount field counts HTML form submission events, which are specific to browser-based environments. Native mobile apps do not use HTML form submissions.

For mobile sessions, use other behavioral aggregation fields (clickCount, inputChangeCount, focusCount) to assess user interaction patterns. These fields are available across all platforms.

High null rates are common when analyzing Digital Intelligence data in aggregate across all platforms. There are three main causes:

1. Platform-specific fields return null on non-matching platforms. For example, androidAttributes.isRooted is null for every iOS and Web session. If your traffic is 80% Web and 20% Android, this field is null 80% of the time — by design. Filter your analysis by device.attributes.platform to see accurate null rates per platform.

2. Permission-dependent fields are null when permissions are denied. Location fields (device.attributes.location.*) require the user to grant location access. If most users deny the permission, these fields have high null rates on mobile. Battery fields have similar behavior.

3. Input-dependent fields are null when data isn't provided. Velocity metrics (such as velocityMetrics.historicalCount.surName) require the corresponding PII fields (surname, email, mobile number) in the Evaluation API request. deviceContext requires passing a context string to processDevice(). customerUserId and userId are optional fields that must be explicitly provided.

Refer to the Data Dictionary platform availability section for a per-field breakdown of which platforms support each field.

Several Digital Intelligence response fields are only populated when specific data is included in the RiskOS™ Evaluation request:

• Velocity metrics (velocityMetrics.historicalCount.*) — Requires the corresponding PII fields: firstName, surName, email, or mobileNumber. If you omit surName from the request, velocityMetrics.historicalCount.surName is null.
• Entity profiler (entityProfiler) — Populated based on the PII entities (phone, email, nationalId) included in the request.
• customerUserId — Optional. Only populated if provided in the evaluation request.
• userId — Optional. Only populated if provided in the evaluation request.
• deviceContext — Only populated if a context string is passed to processDevice() on the client.

Mainstream ad blockers (using default settings) typically do not block the Digital Intelligence (DI) Web SDK.

However, most SDK failures we observe are caused by:

• Enterprise firewalls
• VPN configurations
• Strict Content Security Policies (CSPs)
• Network restrictions that block SDK scripts or ingestion endpoints

Field availability differs across iOS, Android, and Web because each platform exposes different OS-level APIs and enforces different privacy restrictions:

• Operating system restrictions:
  Mobile platforms (iOS and Android) provide access to native APIs for telephony, battery, VPN interface inspection, and hardware integrity checks that are not available in browser environments. Conversely, browsers expose web-specific APIs (WebRTC, WebGL, user agent parsing) that native SDKs do not use.

• Privacy and permission models:
  Each platform enforces its own permission model. For example, GPS location requires explicit user permission on all platforms, but the mechanism differs — native SDKs use CoreLocation (iOS) or LocationManager (Android), while the Web SDK uses the browser Geolocation API. Some signals (for example, carrier name) require permissions that only exist on mobile.

• Platform-specific security signals:
  Certain fraud signals are inherently platform-specific. Root/jailbreak detection applies only to mobile devices. Tampered build detection applies only to Android. Browser attributes (WebGL renderer, hardware concurrency) apply only to web.

• All platforms share core signals:
  Network-level intelligence (IP analysis, ISP, ASN, proxy/VPN/Tor detection), device history, velocity metrics, and entity profiling are available across all platforms because they rely on server-side analysis rather than client-side APIs.