Introduction

Fraud signals are the building blocks of Dynamic Defense rules. Each signal describes a specific, observable indicator of fraudulent or invalid traffic. This could be a device claiming to be an emulator, an impossible OS version, an IP address from an anonymizing network, or a number of other suspicious behaviors. An event matches a rule when it matches any of the rule's signals.

This page defines the fraud signals used by Branch-created rules, grouped by the rule they belong to.

Bot signatures

Detects traffic generated by automated bots rather than real devices.

Fraud signal	Definition
Android Lazy Bot Signature - SDK Missing or Old Version	SDK version is null/blank AND OS version is a consumer marketing string ("9" - "16"). Legitimate Branch SDKs always report a version string, and real Android devices report OS as API level (for example, 35), not the marketing name (for example, "15"). Bots use the wrong format and forget to spoof the SDK version.

Data completeness

Detects events whose payloads are missing data a real device would always provide. This is a sign of bots, broken integrations, or unusable matching signals.

Fraud signal	Definition
Android OS - Empty or null version	Tags Android events where the OS version is null or empty.
Android Hardware Metrics Missing	The Android WindowManager requires brand, screen dpi and width to render an app on a physical screen. A null means the payload didn't come from a real device.

Emulator & virtual-device detection

Detects events originating from emulators and virtual devices rather than physical hardware. A common tool for install farms and automated fraud.

Fraud signal	Definition
Android Emulator - Combined Signatures	Flags Android events whose device build signature (brand, build, or model) matches a known Android emulator signature.
Android x86 CPU Emulator (ChromeOS Excluded)	Tags Android native-SDK in-app events where the device CPU architecture is x86-family (x86_64, amd64, x86, i686), excluding ChromeOS devices. Catches emulators leaking host CPU architecture.

Device spoofing and operating system integrity

Detects devices misrepresenting what they are. This includes mismatched build signatures, impossible brand values, and OS versions that don't agree with themselves.

Fraud signal	Definition
iOS Brand Not Apple	Real iOS devices always report "Apple" as brand. A missing or non-Apple brand suggests the event didn't originate from a genuine iOS device.
Samsung API 34/35/36 Build Signature Mismatch	Flags Samsung-branded Android events on API levels 34, 35, and 36 where the build signature doesn't match expected manufacturer values. Indicates a spoofed device build signature. Excludes clicks, impressions, and web session starts as non-SDK or non-mobile events.
Android API / OS Version Mismatch	Flags Android events where the reported OS API level and OS version are inconsistent with each other. On a genuine device, the operating system sets these two values together, so a mismatch indicates an emulator or spoofed device. For mobile SDK events.

Outdated or unsupported environment

Detects events from operating system versions so old that genuine new activity from them is implausible.

Fraud signal	Definition
iOS OS Version <= 12	iOS 12 reached end-of-life in 2023. New installs from OS version 12 or below are suspicious and likely spoofed.
Android Old OS - Version below 5.0.2	Tags Android events where the OS version is below 5.0.2. Devices this old are end-of-life and are a common emulator or install spoofing signal.

Network & anonymization

Detects traffic from autonomous systems (ASNs) associated with suspicious install activity.

Fraud signal	Definition
Suspicious ASN Install/Reinstall	Tags install and reinstall events originating from autonomous systems (ASNs) associated with suspicious install activity.

Ivy Advanced Persona

Ivy Advanced Persona is an event analysis rule built on Branch's user device graph. Rather than judging each event on its own, it evaluates that event in the context of the user's wider behavior, so it can still flag a purchase that looks unremarkable in isolation once it weighs the purchase against the user's history.

In practice, the rule uses the device graph to resolve activity to a single user across devices, then flags users whose event volumes sit in the extreme tail of the distribution for your app, for example, above the 99th, 99.9th, or 99.99th percentile.

The rule has three signals:

Fraud signal	Definition
Suspicious Click Activity	Tags clicks from users with an abnormal click rate.
Suspicious Open Activity	Tags open events from users with an abnormal open rate.
Suspicious Reinstall Activity	Tags reinstall events from users with an abnormal number of reinstalls.

Note: Ivy Advanced Persona vs. Ivy Intelligent Protection

These are two different things. Ivy Advanced Persona is an event analysis rule with the signals listed above. Ivy Intelligent Protection is Ivy's always-on detection layer: it analyzes your post-attribution data and generates its own rules when it detects an emerging fraud pattern. Those rules appear in your Rules list labeled Generated by Ivy and use their own distinct set of signals, which appear in Ivy Intelligent Protection below.

Ivy Intelligent Protection

Ivy Intelligent Protection is Ivy's always-on detection layer. It analyzes your post-attribution data and generates rules when it detects an emerging fraud pattern; those rules appear in your Rules list labeled Generated by Ivy. The signals below are the ones Ivy Intelligent Protection uses. The exact set in any given rule depends on the patterns Ivy found in your data.

About install timestamps

Several of these signals compare timestamps captured at different points in the install journey:

• Click timestamp: When the attributed ad click happened.
• Store install timestamp: When the app store recorded the install.
• Binary timestamp: When the app binary was written to the device.
• Click-to-install time (CTI): The elapsed time between the click and the install.

Genuine installs produce a predictable ordering and spacing between these timestamps. Fraud techniques like click injection disturb that ordering, or compress the gaps into implausibly short intervals.

Signals

Fraud signal	Name in the UI	Definition
HAD_OPEN	Low post-install open event activity	Tracks whether an app open followed the install. Installs that are never opened are a strong indicator of fabricated installs, because no real user is behind them.
HAD_DOWNSTREAM_EVENT	Low post-install conversion activity	Tracks whether the install produced any subsequent activity at all. Fraudulent installs typically stop at the install itself and generate nothing afterward.
HAD_LIFECYCLE_EVENT	Low post-install lifecycle event activity	Tracks whether the user completed a lifecycle event such as registration or login. Real users progress through these steps; fabricated installs often skip them.
HAD_COMMERCE_EVENT	Low post-install commerce event activity	Tracks whether the user completed a commerce event such as a purchase or add to cart. A cohort that never transacts is unlikely to consist of genuine users.
HAD_CUSTOM_EVENT	Low post-install custom event activity	Tracks whether the user triggered any of the Custom Events you have defined for your app.
LIMIT_AD	High rate of limit ad tracking	The device has Limit Ad Tracking enabled, so its advertising ID is unavailable or zeroed. This traffic is harder to verify, and fraudsters over-represent it because the missing identifier conceals device reuse.
USER_DATA_IS_JAILBROKEN	High rate of device jailbreak	The device reports as jailbroken or rooted. These devices can spoof identifiers, automate interactions, and tamper with the SDK.
PERSONA_AGE_LESS_THAN_1_MINUTE	High rate of new users to device graph (M)	Branch first observed this user persona less than a minute before the event. A persona this new converting immediately points to a device farm, or to emulators resetting identifiers between installs.
PERSONA_AGE_LESS_THAN_1_HOUR	High rate of new users to device graph (H)	The same check across a wider window: Branch first observed this user persona less than an hour before the event.
NULL_STORE_INSTALL_TS	High rate of missing app store timestamp	The app store didn't report an install timestamp, so you can't verify the install against store records. Genuine store installs supply this value.
CLICK_TS_IS_AFTER_STORE_INSTALL_TS	Click Injection - Click and store timestamp order anomaly	The attributed click was recorded after the store had already registered the install. This is the signature of click injection, where a fraudster detects an install in progress and fires a click to claim credit for it.
CLICK_TS_IS_AFTER_BINARY_TS	Click Injection - Click and binary timestamp order anomaly	The attributed click was recorded after the app binary was already on the device. Another form of click injection, in which attribution is claimed for a download that had already happened.
CTI_BELOW_PERCENTILE	Click Injection - CTI metric anomaly	The click-to-install time falls below the normal range for your app. Implausibly fast installs suggest the click was manufactured rather than made by a real person.
INSTALL_STORE_DELTA_BELOW_PERCENTILE	Non-human traffic - Install to store timestamp delta	The gap between the store install timestamp and the Branch install event is implausibly short compared with your app's normal distribution.
INSTALL_BINARY_DELTA_BELOW_PERCENTILE	Non-human traffic - Install to binary timestamp delta	The gap between the binary timestamp and the Branch install event is implausibly short compared with your app's normal distribution.
BINARY_STORE_DELTA_BELOW_PERCENTILE	Non-human traffic - Binary to store timestamp delta	The gap between the binary timestamp and the store install timestamp is implausibly short compared with your app's normal distribution.

Learn more

• Dynamic Defense: How rules work, tagging vs. blocking, and managing your fraud protection.
• Dynamic Defense dashboard: Reporting on blocked and tagged events across campaigns and ad partners.

Some Dynamic Defense features require an upgrade. Please contact our Sales team to learn more.