Record the browser device the caller is signed in from

The reCAPTCHA action the token was minted for (signup_password, signup_magic_link, signup_oauth, deposit, card_save). Already checked against siteverify's own action, which is what stops a token minted on the signup widget being replayed at the deposit endpoint.

Which threshold band the score fell in: "pass" (>= 0.7), "step_up" (0.3 to 0.7), or "step_up_strict" (< 0.3). The step-up the band demanded has ALREADY been satisfied by the time the request arrives, so this records how much friction the customer met; it is never an instruction. A deployment with the feature off sends no captcha fields at all rather than a band meaning "we did not look" (docs/architecture/signup-bot-defense.md).

reCAPTCHA v3 score for the action behind this request, 0 to 1 ("1.0 is very likely a good interaction, 0.0 is very likely a bot", https://developers.google.com/recaptcha/docs/v3). The dashboard's server layer obtained it from Google's siteverify and checked the action, hostname, and challenge age before sending it, so this is a VERDICT the control plane records rather than a token it re-verifies. Absent when the feature is off or nothing could be measured, and an absent score is not a zero.

Fingerprint event id for this identification. It is the half the server verifies with Fingerprint (the visitor id alone cannot be), so a visitor id sent without it is recorded but never clustered.

Fingerprint visitor id, the stable per-device identifier.