How scoring works¶
The DEA SDK decides, on the device, whether a session comes from a real person. Every platform guide relies on the same few ideas: sessions, actions, evidence, the model and the classification. This page explains them once.
Capture¶
From init, the SDK listens to the input your app already receives. There is nothing to wrap or
register: touches, pointer movement, presses and releases, scrolling and, where the platform reports
them, key presses and device motion. What each platform captures, and what it never reads, is on
Privacy and network.
Capture runs until you pause it, end the session or dispose of the SDK. Keep a screen out of it with the platform's Sensitive Screens page.
Actions¶
The SDK groups raw input into actions: a tap, a drag, a scroll, a run of key presses. Scoring reads actions, not individual events, and keeps the most recent 64 of them. Older actions drop out, so the score describes how the user is interacting now, not an hour ago. On phones and tablets, an app that stays in the background for more than five minutes starts collecting evidence again from nothing when it returns.
Evidence¶
A score means something only once there are enough actions behind it, which these guides call sufficient:
| Where | Sufficient when |
|---|---|
| Phones, tablets, and browsers on them | The session has at least the number of actions the loaded model asks for: 8 with the model built into the SDK |
| Desktop and laptop browsers | The session has at least the number of actions the loaded model asks for, 20 with the built-in model, and they come from at least two kinds of input (pointer, scroll, keyboard) with at least three actions each |
A model DEA publishes later can ask for a different number. The classification's actions field
says how many actions the score has so far.
Until then, the classification is insufficient on Flutter, Android, iOS and React Native, with no
score (value is null), and undetermined with sufficient set to false on the Web. Either
way the SDK signs no proof for the session. Right after the app or page opens there is never enough evidence: read the classification at a decision point the user reaches by interacting, such
as submitting a form, not at load.
The model and its thresholds¶
A model turns the actions into a score: higher means more like a person. The model also carries the two thresholds the score is compared with:
On Flutter, Android, iOS and React Native the SDK answers by this rule, in order:
| Result | When |
|---|---|
insufficient |
The SDK is still loading, or the session does not have enough actions yet. value is null |
human |
The score is at or above the human threshold |
bot |
The score is below the bot threshold |
human |
The model sets no human threshold: the bot threshold is the one bar |
undetermined |
The score is between the two thresholds |
The thresholds come from the loaded model only; nothing in your configuration changes them. A model without a bot threshold cannot classify, and getClassification() reports
ThresholdMissing instead of guessing.
Each package embeds a model. The SDK can also download newer models that DEA publishes: only from
DEA's release host, only a version newer than the one it has, and only after checking the file's
integrity. A downloaded model replaces the embedded one, sometimes in the middle of a session. The
classification names the model it came from in modelVersion. Which platforms update the model,
and whether each embedded model is ready to act on, is on
Going to production.
Reading the classification¶
getClassification() returns one snapshot:
| Field | Meaning |
|---|---|
result |
human, bot, undetermined or insufficient (Web: the first three) |
value |
The score, or null while the result is insufficient |
sufficient |
Web only: whether there is enough evidence behind the score |
actions |
How many actions the score is based on |
botThreshold, humanThreshold |
The loaded model's thresholds |
modelVersion |
The version of the model that produced the score |
The read is local and makes no network request: the score is kept up to date as the user
interacts. Your app decides what each result allows. Give undetermined a fallback path, such as
a challenge, rather than treating it as bot, and treat insufficient as "too early", never as
bot.
Sessions¶
A session starts at init and lasts until you reset it or dispose of the SDK. Reset it when the
person using the app changes, on logout or an account switch, so one person's evidence never
counts for another. A reset clears the actions and the score and keeps a downloaded model. See the
platform's Sessions page.
Proofs¶
The classification stays on the device. When a decision has to be checked by a server, the SDK can
sign a proof of the score with a key held by the device and send it to DEA: Attest registers that
key, and Ads attaches proofs to ad impressions. What these requests carry is on
Privacy and network, and the appId and appKey they are sent under on
Accounts and keys.