Behavioral Layer
A program gives itself away by how it acts, not by what it does
Every visit produces motion: a cursor travelling toward a button, keys held and released, a page scrolled, a screen touched. TRACIO scores that motion continuously and tells you whether it came from a hand or from software.
What We Watch
Four channels of input, weighted by the device in the visitor's hands
Each channel is scored on its own and then combined. The weights are not fixed — they follow the device the visitor is actually using. On a phone, touch carries the verdict and a missing cursor means nothing. On a desktop, the cursor is the strongest channel and an absent touch stream is simply expected.
Mouse and cursor
Desktop primarySpeed and how much it varies, direction changes per stretch of travel, how the path curves toward a target, acceleration and braking before a click, and the fine tremor of a human hand that a scripted move does not reproduce.
Keyboard rhythm
Timing onlyHow long each key stays down, the gap between one release and the next press, overlap when the next key goes down before the previous one comes up, bursts and pauses, corrections and backspaces. Timing — never the characters. See the privacy section below.
Scroll
Both form factorsVelocity variance, how often direction reverses, momentum that decays the way a physical flick decays, and pauses that line up with how much text is actually on screen.
Touch
Mobile primaryContact area and how it changes through a tap, reported pressure where the device exposes it, the small drift of a finger that never lands twice on the same pixel, and the timing between multiple contacts.
The same session, weighted two different ways
Mouse and keyboard carry the weight. No touch stream is expected here, so its absence costs the visitor nothing.
Touch and device motion carry the weight. A visit with no cursor movement at all is normal on a phone, not suspicious.
Absence is not evidence
A channel the device never offered is excluded from the score rather than counted against the visitor. This sounds obvious and is the single most common way naive behavioral scoring turns real customers into suspects: a phone has no mouse, a screen reader user has no smooth cursor path, and neither fact says anything about being a bot.
The Evidence
Three things software does that hands cannot
These are examples rather than the full rule set, but they show the shape of the evidence we act on. Each one is a physical impossibility for a hand, and each one is gated so that a single odd moment never becomes a verdict.
Metronome key holds
What we measure
Every key held down for almost exactly the same number of milliseconds across the whole input.
Why a hand can't do it
How long a finger stays on a key depends on which key it is, which hand it belongs to, and how tired that hand is. Human hold times scatter. Injected keystrokes are generated from a constant, and the scatter collapses to nearly zero.
What keeps it honest
The rule needs enough keystrokes in the window before it counts at all. A four-character input is not a sample, and it is not scored as one.
Clicks that teleport
What we measure
A click lands on a control the cursor never travelled to — the pointer simply appears at the coordinates and fires.
Why a hand can't do it
A person approaches a target: the path curves in, speed drops near the end, and there is usually a moment of hover before the press. Automation sets coordinates and dispatches an event; there is no approach because nothing physically moved.
What keeps it honest
A single teleporting click is a plausible keyboard-navigation or trackpad artefact. It only counts when it is the majority of clicks in a session that had enough clicks to judge.
Typing into a hidden tab
What we measure
Keystrokes keep arriving while the page is in the background and has never been brought to the front.
Why a hand can't do it
A person cannot type into a page they are not looking at. Farm software drives dozens of tabs in parallel and does not bother to focus each one before it starts filling forms.
What keeps it honest
One event at the instant of a tab switch is a race between browser events, not evidence. It counts on repeated input with the page still never visible.
Privacy
We measure the rhythm. We cannot reconstruct the text.
Behavioral collection runs everywhere on the page, including password, email, and card number fields. That is a deliberate decision, and it deserves to be explained in full rather than buried in a policy document.
Why sensitive fields are the ones that matter
Credential stuffing, card testing, and account takeover all happen inside exactly those inputs. A detector that switches itself off there is blind in the one place the attack actually lives. That was the previous behavior: collection was disabled wholesale in sensitive fields, so the highest-risk seconds of a visit produced no measurements at all.
What is kept
Timing. When a key went down, how long it stayed down, how long until the next one, whether two presses overlapped. That is enough to tell a hand from a generator, and it is all the detector ever asked for.
What is not kept
Which key it was. Inside sensitive fields the identity of every keystroke is replaced with a coarse surrogate in the browser, before anything leaves the page — one of a small handful of buckets, not a character. There is no mapping back. The stream that reaches our servers contains no text, no partial text, and nothing that can be reassembled into text.
The consequence we had to handle
Because key identity is genuinely gone in those fields, any rule that depends on telling keys apart has to exclude those keystrokes from its own count — otherwise a normal password would look like one key struck over and over, and we would flag people for typing correctly. Timing-based rules are unaffected and keep working on the full stream.
Turning collection off never protected the content
The characters were never collected in either design. All the old blanket exclusion removed was the evidence — it made the detector blind without making anyone more private. The surrogate approach keeps exactly the same guarantee about your text and gives the detector its measurements back. Stronger detection and better privacy came out of one decision, which is rare enough to be worth stating plainly.
How Rules Ship
A new rule runs blind before it is allowed to touch a verdict
Detection gets worse the moment it gets clever without evidence. Every behavioral rule is added in shadow first: it is evaluated against live production traffic and its result is recorded, but it contributes nothing to the score anyone sees.
Shipped in shadow
The rule evaluates on real traffic from the first day. Its output goes to analytics only — no customer's verdict moves because a rule was added.
Measured against both populations
We watch how often it fires on sessions independently judged human and on sessions independently judged automated, over enough live traffic to mean something.
Two thresholds decide
It has to separate at least ten to one — firing at least ten times more often on automation than on people — and it has to stay under a 0.5% firing rate on live human sessions.
Promoted, or left in the dark
A rule that clears both gates gets weight in the score. A rule that does not stays in shadow or is removed outright. Promotion is a deliberate, reviewed change — nothing is switched on automatically.
This is what protects you from a detector that got clever overnight and started turning away your own customers. Your false-positive rate does not move because someone had an idea on a Friday afternoon.
What You Receive
Three fields, delivered with the identification event
The behavioral verdict arrives alongside the rest of the event — no second call, no polling, no separate endpoint to integrate.
Event Excerpt
{
"visitorId": "X7fh2Hg9LkMn3pQr",
"behavior": {
"score": 87.4,
"verdict": "human",
"confidence": 0.82
}
}Available on the Business plan and above. Delivered in webhooks and available through the Data API.
The behavioral block is a signal, not an action. It blocks nothing on its own — you combine it with the rest of the event and with your own policy, which is where the decision belongs.
Limits
What behavior does not tell you
Behavior answers one question well: human or program. It does not answer "which human", and we do not sell it as though it does.
It is not an identity signal
We do not claim to recognize a returning individual by their typing or their mouse. We measured it on live traffic: matching a specific person across two browsers they both use performed no better than chance. Any vendor selling "behavioral biometrics that identifies the user" should be asked to publish that same number.
It does not replace identification
Who the device is comes from the device and browser layer. Behavior tells you what kind of actor is driving that device. The two answer different questions and neither substitutes for the other.
It needs input to work
A visitor who lands and leaves within two seconds produces almost nothing to score. The honest output there is "uncertain" with low confidence — not a guess dressed up as a verdict.
Frequently asked questions
See the behavioral verdict on your own traffic
Install the agent, watch the score arrive with every identification event, and decide for yourself what it is worth.