A security team should evaluate threat analytics for mobile apps by testing three things: the signal schema, meaning which behaviour each check reports, with which fields, timestamps and severity; the operations around it, meaning how signals reach triage, feed response policy and escalate to your SOC; and data governance, meaning how detections are kept apart from confirmed attacks and how long anything is kept. This guide covers Android, iOS, Flutter and React Native apps. Otukan threat analytics turns runtime checks into trends your analysts can act on, while your team decides what counts as an attack.
What the product does is covered on threat analytics. Other evaluation guides are on solution guides.
Signal schema
Ask each option for a redacted sample of its signal schema and read it the way a detection engineer would.
Behaviour reported
- Which checks produce signals: hooking, debugging, emulation, root on Android, jailbreak on iOS, repackaging?
- Is each check documented separately for Android and for iOS, with its own scope?
- Does a signal say whether the app responded, and how?
Fields and time
| Field | Why it matters | What to verify |
|---|---|---|
| Check name | Groups signals by technique | Stable names across releases |
| App build and version | Ties signals to a release | Matches your release numbering |
| Platform and OS version | Keeps Android and iOS apart | Reported per signal, not inferred |
| Time the check fired | Orders signals within a session | Device time and receipt time both recorded |
| Severity | Drives triage order | Documented levels you can map to your own |
| Pseudonymous identifier | Links signals without naming a person | Rotatable, and separable from account data |
How Otukan answers. Each Otukan signal carries the check, app build, platform, OS version and the time the check fired. Every check maps to a small set of severity levels, which Otukan maps to your SOC scale before delivery starts. Android and iOS signals are reported separately, so a spike on one platform stays visible on its own.
Analytics operations
Analytics earns its place when it changes what your analysts and release managers do next.
Triage
- Can analysts filter by check, severity, app version, platform, OS version and time window?
- Can one signal be followed to the session, install and release it came from?
- Which views show trends and spikes, and which checks fire most?
Release and policy
- Can you compare signal rates before and after a release?
- How does a pattern in analytics become a change in the app’s response for a flow?
- Who approves moving a flow from observe to restrict?
Escalation
- Can high-severity signals go to your SIEM while routine ones stay in analytics?
- Which fields arrive in the SOC queue, and are they normalised?
- Who owns the runbook when mobile signals join other security alerts?
How Otukan answers. Otukan establishes a baseline range for each check on your app, then shows trends, spikes against that range and top-firing checks across users and releases. It compares signal rates before and after each release, shows where signals concentrate by build, including older builds, and groups signals by install age so a cluster of new installs stands out. Analysts filter by check, severity, version, platform, time window and pseudonymous identifier, then follow a signal to its session. Patterns feed the per-flow response policy, and Otukan delivers normalised signals and summaries to your existing SIEM or SOC platform, with high-severity signals sent on their own.
Data governance
Numbers in a security report are only as good as the labels underneath them.
Labels
- Does the product separate a detection from a confirmed attack and from a business incident?
- Who changes a label, and is the change recorded?
- Do dashboards count each label separately?
Retention and access
- Which fields leave the device, and is each one needed for a security decision?
- How long is each kind of record kept, and who agreed it?
- Who can link a pseudonymous identifier to an account, and can that access be restricted?
- Is the data flow documented for your privacy team before the pilot starts?
How Otukan answers. Otukan analytics keeps detections, confirmed attacks and business incidents apart and filters by each, so raw detections are not counted as attacks in your reports. Telemetry is limited to what a security decision needs and uses pseudonymous identifiers. Retention is agreed before collection starts, Otukan documents the data flow for your privacy review, and access to account linkage can be restricted.
Evaluation record
| Area | Evidence to keep |
|---|---|
| Schema | The redacted sample and your field-by-field review |
| Replay | A test signal traced from device to your SIEM |
| Operations | The runbook your analysts used in the pilot |
| Governance | The agreed labels, retention periods and access list |
For how signals leave the app, see runtime threat signals. If your app is already published, a free App Exposure Check reviews the public store release.