For the complete documentation index, see llms.txt. This page is also available as Markdown.

Form Tile

Analytics metrics and events for Form Tiles

Form Tiles render an author-defined form and emit a drop-off funnel to product analytics. They render on two surfaces and emit the same events on both:

  • Embed — the form embedded in an Imprint via the Web SDK.

  • Standalone — the form rendered as a dedicated public page.

Every form event carries a form_surface property (embed or standalone) so the two surfaces can be segmented. A form moves through up to three screens — intro (optional), content (the fields) and final (confirmation) — and the events map onto those transitions plus the submit outcomes. All events fire client-side only.

Common properties

These properties appear on every form event:

Property

Type

Notes

tile_id

String

The Form Tile id. Primary per-form identifier.

form_surface

String

embed or standalone.

form_tag_analytics

String

Present only when the Tile has an author-set analytics tag.

Surface-specific additions:

  • Embed events also inherit the Imprint super-properties on the Web SDK client, including imprint_id and team_id (team_id is embed-only).

  • Standalone events also carry form_slug (the public page slug), and the page emits $pageview and $pageleave.

No user-entered values are ever sent. Payloads are a fixed allowlist of field metadata only — never field contents, including no answer values.

Events captured

Event Name

Definition

Frequency

form_intro_viewed

Intro screen renders. Only emitted if the form has an intro screen.

Once per visit

form_viewed

Content/fields screen renders. The funnel denominator — fires for both intro and intro-less forms.

Once per visit

form_started

First field loses focus, regardless of whether a value was entered.

Once per visit

field_filled

A field is completed: text/email/date on blur with a value; checkbox/choice on change; media on upload complete.

Once per field

form_submit_blocked

Submit is blocked client-side before any mutation runs. Carries reason.

Per attempt

form_submitted

Submit mutation resolves successfully.

Per success

form_submit_failed

Submit mutation rejects (server or network error).

Per failure

form_completed

Final/confirmation screen renders. Roughly 1:1 with form_submitted on the happy path.

Once per visit

form_resubmitted

Visitor starts a second pass via the resubmit action. The once-per-visit view events do not re-fire.

Per resubmit

Event-specific properties

field_filled adds, in addition to the common properties:

Property

Type

Notes

field_id

String

The field id.

field_type

String

For example text, email, date, checkbox, choice or media.

field_label

String

The field's author-defined label.

field_required

Boolean

Whether the field is required.

field_position

Numeric

The field's index/position in the form.

form_submit_blocked adds:

Property

Type

Allowed values

reason

String

missing_required, invalid_email, media_uploading or empty_form

Reading the funnel

The primary drop-off funnel is:

Segment by form_surface, tile_id or form_slug, and form_tag_analytics. Submit failures, client-side blocks and silent abandonment are distinguishable through form_submit_failed, form_submit_blocked and the absence of form_submitted.

Measurement caveats:

  • form_started and field_filled rely on blur, so autofill or Enter-to-submit without a blur can under-count.

  • The funnel localizes drop-off to the last completed field, not the last reached field — a focused-but-empty field emits nothing.

  • An embed Frame reopen (remount) re-fires the once-per-visit events; dedupe is in-memory per mount.

Example event: field_filled

Last updated