Detect fraudulent app installs

WHAT THIS TESTS This evaluates feature engineering for adversarial detection: knowing the common fraud types and which signals distinguish them, then combining signals robustly.

A GOOD ANSWER COVERS Name the fraud types: click injection, where a fake click is fired just before install to steal attribution; click flooding or spamming, mass low-quality clicks hoping one converts; and device farms or emulators generating fake installs. Signals at install: click-to-install time, where injection shows suspiciously short times and flooding shows long flat distributions; device fingerprint, OS, model, emulator markers, reset-advertising-id churn; IP reputation, datacenter ranges, and IP clustering of many installs. Signals after install: depth of engagement, sessions, key events, day-1 and day-7 retention, since fraudulent installs typically never engage; conversion to revenue. Aggregate at the publisher and campaign level to spot a source with anomalous time distributions or near-zero retention. Feed these into a model or scorecard rather than one threshold.

COMMON WRONG ANSWERS Using a single rule such as block short click-to-install. Ignoring post-install behavior, the strongest signal that an install is real. Looking only at individual installs rather than clustering by publisher, IP, and device. Treating emulator detection as sufficient by itself.

LIKELY FOLLOW-UPS How does the click-to-install time distribution differ for injection versus flooding? Why is post-install retention such a strong feature? How do you handle the adversary adapting to your detection?

ONE CONCRETE EXAMPLE A publisher delivers thousands of installs with click-to-install times clustered under a few seconds, many sharing a handful of datacenter IPs, and essentially zero users reaching day-1 retention or any key event. The model scores this source as high-risk for click injection plus a device farm, and you withhold payout and investigate.