Docs/Tracking Script

Building forms we track accurately

How to structure a form so every submission is captured, and what breaks capture.

The tracking script captures most contact forms with no configuration. This page explains how it reads a form, how to structure yours so every submission is captured cleanly, and the specific patterns that reduce accuracy so you can avoid them. It is written for whoever builds or maintains the site.

How the script reads a form

On each page the script watches for form submissions. When a visitor submits, it reads the fields at that moment, maps them to a lead (name, email, phone, message, and any extra fields), and attaches the marketing source it has been tracking for that visitor. The values a visitor sees are the values captured, so an accurate form produces an accurate lead.

The reliable pattern

A form is captured most reliably when it is a real <form> element that the browser submits. Give the script clear signals and every submission lands:

  • Wrap the fields in a <form> element and submit it with a real submit control (<button type="submit"> or <input type="submit">).
  • Give every field a meaningful name or id, and use the correct input type: type="email" for email, type="tel" for phone. Correct types and names are how the field values reach the right lead fields instead of the notes.
  • Show a clear success state after submitting: a confirmation message, or replace the form with a thank-you view. This is the signal that the submission went through.
If your form is a standard <form> with named fields and a submit button, there is nothing else to do. Everything below is for forms built in less standard ways.

Forms without a <form> element

Some hand-built forms and page builders place the fields in a plain container and send them with custom JavaScript, without a real <form> element. The script still captures these: it reads the fields when the submit button is clicked and records the lead once the page confirms the submission succeeded. For this to work reliably, two things matter:

  • The submit control should read as a submit action. A button labelled Send, Submit, Request a Quote, Get Started, or similar is recognized. A generic element with no such label may not be.
  • The page must show a success state: hide the form, clear the fields, or display a confirmation message. Without one of these, the script cannot confirm the submission and will not record a lead, exactly as it would not record a submission your own validation rejected.
The most durable fix for a custom form is also the simplest: wrap the fields in a real <form> element. You keep your custom submit logic, and capture becomes immediate and unconditional.

Patterns that reduce accuracy

  • Fields with no name or id. An unnamed field cannot be mapped, so its value is dropped or lands in the notes. Name every field you want on the lead.
  • Selection controls with no state marker. Buttons or chips used to pick a service are read from their selected styling. This is best-effort. To make it exact, mark the selected option with aria-pressed="true", or data-selected="true" or data-selected="1" (only those two values are recognized, not merely the presence of the attribute), or back the choice with a real checkbox or radio input.
  • A visible or mislabeled honeypot. Anti-spam honeypot fields must be hidden from people with CSS. The script treats a filled hidden field as a bot and discards the submission, so a honeypot that is visible to real visitors will cause real leads to be dropped. Name it something that is not a real contact field: a honeypot named with name, email, phone, or company is treated as a genuine field, and the trap will not work.
  • Fields outside the form container. Keep every field that belongs to the submission inside the same form or container as the submit button. A field placed elsewhere on the page may not be read.
  • No success state on a custom form. As above, a formless form that never hides, clears, or confirms after submitting gives the script nothing to confirm against. Add a success state.

Multi-step forms

Multi-step forms are supported. Keep each field named, and make sure the final step contains the real submit action and a success state. If an earlier step is hidden as the visitor advances, that is fine: the values are still read at submission.

A form that captures cleanly

Recommended structure
<form id="quote-form">
  <input type="text"  name="name"    placeholder="Full name" required />
  <input type="email" name="email"   placeholder="Email" required />
  <input type="tel"   name="phone"   placeholder="Phone" required />
  <textarea name="message" placeholder="How can we help?"></textarea>

  <!-- honeypot: hidden from people, catches bots. Name it something that is
       NOT a real contact field (avoid name, email, phone, company, etc). -->
  <input type="text" name="url"
         style="position:absolute;left:-9999px" tabindex="-1" autocomplete="off" />

  <button type="submit">Request a Quote</button>
</form>
If a form on your site is not showing up as leads, the usual cause is one of the above: no <form> element with no success state, unnamed fields, or a honeypot that is visible. Send us the page URL and we will tell you exactly which one it is.