Customer.io Forms Can Now Capture a Visitor Before You Know Who They Are. Don't Rip Out Typeform Yet

Britain counted itself four times before anyone in London wrote down a single name. Four censuses ran under John Rickman, in 1801, 1811, 1821 and 1831, and as The National Archives records, lists of names "were not collected centrally". The ONS describes how those early counts worked: an enumerator filled in figures for local areas rather than households completing forms for themselves. Their object, in the National Archives' words, "was not to obtain detailed information about individuals, but to provide information about the population as a whole".

Then came census night, 6 June 1841. The form went to the household, the household filled it in, and every person in the country was recorded by name. The National Archives calls 1841 the first census "to list the names of every individual". ONS calls it the first "modern" one. Same exercise, same enumerators, same clipboards... what changed was that an anonymous count became an identified record.

Customer.io shipped its version of that transition on 8 June 2026.

If you run Customer.io and you still bolt a Typeform onto your product to collect feedback, this post is the decision you've been putting off. It is not the decision you think it is, though. Customer.io has two separate forms systems, and almost everybody conflates them. One is native and lives inside the SDK. The other ingests third-party forms, Typeform included. Getting the difference right determines whether a submission arrives as a profile with an event trail, or as a row in someone else's database.

What actually shipped on 8 June 2026

Customer.io added plain text fields to anonymous in-app messages. The release note is specific: you can "add plain text fields in anonymous messages to collect feedback from visitors you haven't identified yet". Customer.io gives the reason too. It "can help you gather feedback from users who might not be comfortable providing their name or email addresses".

Submissions land in a Form Submissions tab on the message's Overview page. You can browse them there or click Export all for a CSV.

That's the whole feature. No webhook, no Zap, no intermediate form provider. A visitor who has never logged in types a sentence into your product, and the sentence arrives in your messaging platform.

What goes in that open field matters more than the plumbing. One good question beats five mediocre ones, and if you need a starting point, the one question worth asking is a better default than an NPS score nobody acts on. Ruler Analytics makes a similar case for a single open field on lead forms: "Try self-reported attribution. Add an open field to your forms (How did you hear about us?) and use the answers alongside your analytics data. People's responses can be surprisingly revealing."

Customer.io has two forms systems, not one

This is the distinction that decides everything else, and the docs keep the two apart in different sections of the site. Most teams find one, assume it's the whole story, and make the wrong call.

Native in-app forms: SDK-bound, text-first, built for feedback

Native forms are in-app messages with form components dropped into them. You drag a Form element into the message, then add inputs inside it. The in-app forms documentation is precise about the field set and the limits: Short Text is single-line with a 255-character maximum, Long Text is multi-line and expandable with a 500-character maximum. In anonymous messages you can add Buttons inside the form as well, which is the one place the docs list them as a form component. Anything you drop outside the form element won't be captured on submit.

Three components matter, and they arrived on three separate dates.

The Lead Form came first, on 6 October 2025: a drag-and-drop component collecting names and email addresses from anonymous visitors. Customer.io's own release note called it "our first release of a component that captures form data like this" (release notes).

General in-app forms followed on 26 January 2026, with the pitch stated plainly: "You can capture feedback from your audience directly through Customer.io—without using a third-party form provider" (release notes).

Anonymous forms completed the set on 8 June 2026, extending open text to visitors nobody has identified.

Because these are in-app messages, everything true of in-app messages is true of them. The same docs page walks through the message settings: Page Rules "determine the pages where a person can see your message", and Display and Position determine where on the page it appears. A feedback prompt does not have to interrupt anyone, either. You can build it inline rather than as a modal and let it sit in the product UI.

Note what native forms are not. They are not hosted pages. There is no public URL you can put in an email signature or a LinkedIn post. The SDK has to be running in your app or on your site for the message to render at all.

Connected forms: Customer.io ingests Typeform rather than banning it

The second system does the opposite job. It takes forms that already exist, on public web pages, and pulls the submissions in.

The docs are direct about the native connectors: "We directly integrate with Jotform and Typeform. But you can use our custom forms JavaScript snippet to support virtually any form provider" (Customer.io connected forms guide). Two providers get a direct integration. Everything else goes through the snippet or the API.

That "everything else" list is longer than most people expect. Customer.io says it has tested the snippet and its form-scanning service with Formstack, Instapage, Netlify, Squarespace Form Blocks and Newsletter Blocks, Unbounce landing pages, Webflow, WordPress forms, and your own HTML forms. Note the qualifier on Unbounce: landing pages, not pop-ups or sticky bars.

For anything server-side, there's a /forms API. Customer.io's recommendation is to use it "for backend integrations—anytime you want to capture submissions outside of our client-side JavaScript snippet". If you're already building against the platform, that sits alongside every other route in the complete guide to integrating data sources with Customer.io.

What you get from a connected form is the part people miss when they wire a form to nothing. Customer.io identifies the submitter, maps the form fields to profile attributes, and records a form_submit event on the Profile activity page. Click the event and you see the form_id and the values the person submitted.

There are real limits. Form scanning fails on JavaScript-rendered forms, because the docs state that Customer.io does "not yet support pure JavaScript forms". Forms must use the <form> tag, so <div>-based forms won't scan. HubSpot forms are named explicitly as unsupported.

What an "anonymous submission" actually does

An anonymous form submission is open-text feedback from someone you haven't identified. It is not lead capture. That misreading is doing a lot of damage in the wild, and it will cost you a lead if you act on it.

The retention rule is the part to internalise. The anonymous in-app forms page states it twice: "We retain anonymous form submissions for 30 days—unless you identify the person who submitted the form within that period." And: "We keep anonymous form submissions for 30 days. After that, we delete them."

Identify the person inside those 30 days and the submission attaches to their profile. The docs are explicit about what that buys you: "because these submissions are no longer 'anonymous', we'll retain the event." Miss the window and the feedback is gone from the platform. The docs add a useful piece of framing: "This is no different from other anonymous data."

Which means the export button is not a convenience. It's your route to keeping a submission beyond 30 days if the person never identifies themselves, and the docs are blunt about the alternative: "After that, we delete them."

Reconciling an anonymous visitor to a known profile is acquisition work, not analytics housekeeping. The 30-day clock gives you a window and a deadline in the same sentence.

The Lead Form is the lead-capture component, and it has its own catch

If you want a name and an email from an anonymous visitor, that's the Lead Form, not an open text field. Submit it and Customer.io adds the person to your workspace so you can message them.

Here's the catch the Lead Form documentation spells out and most readers skim past: "When someone submits the form, we'll add them to your workspace, but we won't automatically identify them in the browser. We'll capture their anonymous activity up to that point, but anything they do after they submit your form will remain anonymous."

Read that twice if you're planning a coupon-for-email trade. You get the profile. You get their history up to the submit. You do not get an identified browser session, so everything they do next arrives as anonymous activity unless you identify them yourself.

Two more operational details. The Name field writes a name attribute. If you already split names into separate first and last attributes, the docs suggest you "may want to disable the Name field and capture names some other way". And the Tracked Name on the submit button is what generates response metrics, including the percentage of people who submit the form. Skip it and you've built a form you can't measure.

Why the handoff is the real problem

A raw form wired to nothing severs capture from two things you're already paying for: the identity graph and the event trail.

The mechanics are dull and that's exactly why they get skipped. A Typeform posting to a spreadsheet produces a row with an email address in it. Customer.io never sees the submission, so there's no form_submit event, no attribute mapping, no segment, and nothing to trigger. Six weeks later someone asks which onboarding cohort complained about the same thing twice and the answer lives in a CSV nobody owns.

The volume argument makes it worse, not better. Unbounce's 2024 Conversion Benchmark Report, drawn from more than 57 million conversions across over 41,000 landing pages, puts the median conversion rate across all industries at 6.6%. Those are pages built for one job, by teams who optimise them for a living, and even there the large majority of visitors leave without filling anything in.

Ruler Analytics, working from 110 million-plus sessions and over 5 million conversions across 13 industries, reports an overall average of 5.13% for 2026, with software at 7.6%. Ruler also found that 88.6% of software-sector conversions arrive by form rather than phone call, which makes the form the primary signal and the primary place to lose it.

So the handful of people who do type something into your product are not a data-volume problem. They're a small, self-selected group telling you what's wrong. Routing that into a system with no identity graph attached is the expensive choice, however convenient the embed code looked.

How submissions land as data

Native and connected forms produce different shapes, and mixing up the vocabulary will waste an afternoon.

Native in-app forms give you three things on submit. Customer.io captures the feedback "under your automation, broadcast, or one-time send's Form Submissions tab". It adds the person to a segment named after the form: "We automatically create a segment for each in-app form using the Name of the form." And you can start an automation with the Form submission trigger, choosing the Name of the form component.

To use the values, reference the field names in Liquid as {{event.submissions.<field_name>}}. A field called favorite_color becomes {{event.submissions.favorite_color}}. Use a space in the field name and you're into bracket syntax: {{event.submissions["Favorite Color"]}}. Customer.io recommends snake case, camel case or kebab case for exactly this reason, and the same discipline that keeps your event schema usable applies to form field names.

Connected forms give you a profile plus attributes plus a form_submit event. The field-to-attribute mapping is the bit worth checking on day one. Customer.io scans your form and guesses, and the guesses are literal: the docs' own example shows a Jotform field arriving as a q4_name attribute when what you wanted was name. Fix the mapping before you build segments on top of it.

One trap in the middle. The form name is not the message name. Segments and triggers both key off the Name of the form component, and metrics key off the Tracked Name on the submit button. Leave the form name blank on an anonymous message and the docs warn that "it'll get set to 'In-App Form'", which makes it hard to tell which form anyone submitted. Start an in-app message from a previous message and you inherit its form name, which the docs flag as a reason to rename the form so you can tell your submissions apart.

The rule to adopt

Three lines, and they cover almost every case.

Capture in-product intent with native in-app forms. If the person is inside your app or on a page where your SDK runs, use a Form, a Lead Form, or an anonymous form. The submission arrives as an event, the segment is created for you, and you can trigger a follow-up.

Capture public web leads with connected forms. A pricing-page enquiry, a webinar signup, a gated PDF: keep the form you've got, connect it, and let Customer.io identify the profile and fire form_submit. If it's Jotform or Typeform, Customer.io integrates with it directly. Otherwise it's the snippet or the API.

Never leave a form unwired. This is the one that actually costs money. A form that reports nowhere is a decision to discard identity and event history, made by default rather than on purpose.

Where those captured profiles go next is a separate build. Once someone is in the workspace with a name, an email and a submission attached, a subscription centre is what stops your first follow-up from being their last.

Honest limits worth knowing before you build

Plain-text inputs only, plus buttons in anonymous messages. Customer.io's January release note states the position: "We support forms with plain-text inputs and plan to add support for other inputs in the future—like checkboxes and radio buttons." No date attached, so build for what exists. If you need a dropdown or a rating scale now, that's a connected form.

Plan gating is uneven. Anonymous in-app forms and the Lead Form both carry Premium and Enterprise badges. General in-app forms and connected forms carry no plan badge.

The Lead Form needs a Workspace Admin. Each form component creates a new Form integration on the Integrations page, "and the ability to create integrations is limited to Workspace Admins today". The docs are useful on the symptom: if the lead-form component is disabled, it's likely you don't have the role, rather than a bug.

Test sends create real submissions. Submit during a test and Customer.io captures it, attributed to your preview profile rather than the test recipient. It can also fire downstream automations. Put dependent automations in draft before you start testing.

Your form is only as visible as the message carrying it. In-app messages fail silently. Nothing bounces, nothing errors, nothing appears. When a form doesn't show up, work the in-app message decision tree rather than rebuilding the form.

Read the metrics carefully. In-app "opened" means displayed, not read, so a form message's open rate is reach. If you're reporting on form performance, know what each in-app metric actually counts before it reaches a slide.

AI won't read your open text for you. Customer.io's Analyze Survey feature sounds like the answer to 400 free-text responses. It isn't. The in-app survey analysis docs describe it analysing Tracked Responses on a live automation or API-triggered broadcast, which are button interactions. It also needs Customer.io AI switched on by an Account Admin plus Survey Analysis enabled under Experimental Features, and that second toggle is a personal setting rather than a workspace one.

Where this leaves you

The 1841 census didn't invent counting people. It put the form in the household's hands and started recording who filled it in. Customer.io's anonymous forms do the same trick from the other end: capture first, identify later, and the platform reconciles the two if you close the loop inside 30 days.

The mistake isn't choosing Typeform. Customer.io ships a Typeform connector. The mistake is choosing a form that reports to nothing, and then discovering the gap when you need the trail.

If you'd rather this got built properly the first time, we do Customer.io work for SMBs day in, day out. Tell us what you're trying to capture and we'll tell you which of the two systems it belongs in.

Frequently asked questions

Does Customer.io have its own forms, or do I need Typeform?

Both, and they do different jobs. Customer.io has native in-app forms delivered by its SDK, which are in-app messages with form components inside them, and a separate connected-forms system that ingests submissions from third-party and web forms. Customer.io integrates directly with Jotform and Typeform, so it isn't a replacement for them on public web pages. Use native forms inside your product and connect the third-party form on your site.

What types of forms does Customer.io offer?

There are two systems. Native in-app forms cover the general Form component for feedback, the Lead Form component for names and email addresses, and anonymous forms for visitors who haven't logged in. Connected forms cover third-party providers and your own HTML forms, via direct Jotform and Typeform integrations, a JavaScript snippet, or the /forms API. The two are documented in different sections of the Customer.io docs and behave differently.

What is an anonymous form submission in Customer.io, and is it lead capture?

It's open-text feedback from a visitor you haven't identified, and no, it isn't lead capture. The 8 June 2026 release added plain text fields to anonymous in-app messages so you can gather NPS comments, feature requests and bug reports from people who haven't logged in. If you want a name and an email address, that's the Lead Form component instead.

How long does Customer.io keep anonymous form submissions?

Thirty days. The docs state it plainly: "We keep anonymous form submissions for 30 days. After that, we delete them." Identify the person who submitted the form inside those 30 days and Customer.io associates the submission with their profile and retains the event. To keep submissions beyond the window, export them to CSV from the Form Submissions tab.

Does the Lead Form identify the visitor in their browser session?

No. Customer.io adds the person to your workspace and captures their anonymous activity up to the point of submission, but the docs are explicit that it "won't automatically identify them in the browser". Anything they do after submitting stays anonymous by default. Plan for a separate identify call if you need their subsequent behaviour tied to the profile.

What field types do Customer.io in-app forms support?

Short Text and Long Text, plus Buttons in anonymous messages. Short Text is single-line with a 255-character maximum. Long Text is multi-line, expandable, and capped at 500 characters. Buttons are listed as a form component on the anonymous in-app forms page specifically. Customer.io's January 2026 release note says it plans to add other inputs "in the future—like checkboxes and radio buttons", with no date given.

Which plans and roles do I need for Customer.io forms?

Anonymous in-app forms and the Lead Form component are both badged for Premium and Enterprise plans in the docs. General in-app forms and connected forms carry no plan badge. Separately, you must be a Workspace Admin to add a Lead Form, because the component creates a new Form integration and creating integrations is limited to Workspace Admins.

How do native form submissions trigger automations?

Start a new automation and set the trigger to Form submission, then select the Name of your in-app form component. Customer.io also creates a segment automatically for each in-app form, named after the form, which you can use as automation criteria later. Both features key off the form component's name, not the message name.

How do I use form answers in a message?

Reference the field name in Liquid as {{event.submissions.<field_name>}}. A field named favorite_color is available as {{event.submissions.favorite_color}}. Field names containing spaces need bracket syntax, so Favorite Color becomes {{event.submissions["Favorite Color"]}}. Customer.io recommends snake case, camel case or kebab case to avoid that.

Which third-party form providers does Customer.io integrate with directly?

Jotform and Typeform. Everything else goes through the custom forms JavaScript snippet or the /forms API. Customer.io says it has tested the snippet and its form-scanning service with Formstack, Instapage, Netlify, Squarespace Form Blocks and Newsletter Blocks, Unbounce landing pages, Webflow, WordPress forms, and your own HTML forms. Unbounce support covers landing pages, not pop-ups or sticky bars. Google Forms appears on neither list, so it needs the /forms API or a snippet setup you validate yourself.

Why does Customer.io say "No forms found under this address"?

Usually because the form can't be scanned. The docs give three causes. A page may contain a provider Customer.io doesn't support yet, such as HubSpot forms. Some forms are JavaScript-rendered, and the docs state that Customer.io does "not yet support pure JavaScript forms". Others are built from <div> elements rather than a <form> tag, which won't scan. Check the markup before assuming the URL is wrong.

Can I use the same connected form on more than one page?

Yes, and you only need to scan one URL. Customer.io identifies a form by its visible fields, so a form with identical fields on several pages is recognised wherever it's submitted. If you need to tell those pages apart, add a hidden field recording the page and filter on it. Working through the API instead, uniqueness is decided entirely by form_id.

Do test sends create real form submissions?

Yes. Submitting a form during a test send creates a real submission, and it's attributed to the profile shown in your preview data rather than the person receiving the test. Test submissions can also fire automations triggered by form submissions. Put those automations in draft or stop them before testing.

Can Customer.io's AI analyse my open-text form answers?

Not currently. The Analyze Survey feature reads Tracked Responses on a live automation or API-triggered broadcast, which are button interactions rather than free text. It also requires Customer.io AI enabled by an Account Admin and Survey Analysis switched on under Experimental Features, which is a personal setting rather than a workspace-wide one. For open-text answers, export the CSV.

Sources

• Collect plain text feedback in anonymous messages. Customer.io Docs, 8 June 2026.
• Anonymous in-app forms. Customer.io Docs, updated 15 July 2026.
• Lead capture. Customer.io Docs, updated 15 July 2026.
• In-app forms. Customer.io Docs, updated 15 July 2026.
• Get started: integrate form submissions. Customer.io Docs, updated 15 July 2026.
• Send forms with text inputs. Customer.io Docs, 26 January 2026.
• Capture leads from anonymous messages. Customer.io Docs, 6 October 2025.
• In-app survey analysis. Customer.io Docs, updated 15 July 2026.
• Conversion Benchmark Report. Unbounce, 2024.
• Conversion Rate Benchmarks 2026. Ruler Analytics, 26 May 2026.
• Census records research guide. The National Archives, updated 29 April 2026.
• Story of the Census. Office for National Statistics.