A form was submitted. The identity of the form, and nothing that was in it.
| Field | Value |
|---|---|
| Name | form_submit |
| Severity | 9 (INFO) |
| Written by | Browser tag. |
| Turned off by | data-auto-forms="false" |
On a submit event reaching the document, in the capture phase. Every form on the page counts, including one a framework handles entirely in JavaScript, because the browser fires the event either way.
Capture phase means we see the submit before the page's own handler has had a chance to cancel it. A form that fails validation therefore looks the same as one that went through, and that is a limit of the automatic measurement rather than a setting.
| Attribute | Type | What it holds |
|---|---|---|
| firstrun.form.id | string | The form's id attribute. Absent when it has none. |
| firstrun.form.name | string | The form's name attribute. Absent when it has none. |
Every entry also carries the resource its client sends once per batch: session.id, user.id once you have called user(), and the rest of the list on the overview. Anything you pass yourself lands in the same map, and your key wins on a collision.
No field, no value, no label, and not even a count of fields. The two attributes above are read off the form element itself, and there is no setting that makes anything else be read.
It does not say whether the submission succeeded. For that, write your own event once the request comes back: a signup having been created is a different question from a form having been submitted, and it is one only your code can answer.
A widget is a filter, a group by, an aggregate, a time bucket and a limit. These are those five parts written out, and every one of them is something you can build yourself.
| Question | The query |
|---|---|
| Which forms get used | Name is form_submit . group by firstrun.form.id . count of entries |
| Submissions over time | Name is form_submit . count of entries . bucket by day |
| How many people submit anything | Name is form_submit . count of uniques |