Capturing name and phone from the form in the pixel, without taking passwords or IDs
The site form knows who the person is the second they click submit. Most pixels discard that. Capturing name, e-mail and phone on submit — and never password, card or document — is what makes the lead born identified and gives Meta an event worth something.

There is one instant when the site knows more about the person than any other system will ever know: the form submit. Name, e-mail and phone are typed, on screen, ready. A second later they go to the CRM or the e-mail tool — and the pixel, which was there the whole time, keeps treating the person as “anonymous visitor 4f3a”.
That waste has a price in two places. In your CDP, the lead enters without identity and only matches their purchase by luck. On Meta, the Lead event goes out without e-mail or phone, and optimization works blind. Capturing the form in the pixel fixes both at once.
How capture works
The pixel watches the submit of every form on the page. On submit it reads the fields, decides which is e-mail, which is phone and which is name, and stores that in the visitor’s identity — a cookie on your domain. From then on every event that browser produces carries the identity: the next page, the video watched, the checkout opened.
The “which field is what” decision is the part that needs care. Website forms rarely have standardized field names: the phone is called “whats”, “celular”, “fone” or only has a placeholder like “(00) 0 0000-0000”. Capture needs three layers.
- 01Field attributes: name, id, autocomplete and placeholder, with a Portuguese and English dictionary. “nome” matches; “nome_da_empresa” does not, because the anchor requires the whole word.
- 02Project rule: when the site is yours, you say “the field with placeholder X is the phone”. It outranks the dictionary.
- 03Value: if the content looks like an e-mail or a Brazilian phone, it is an e-mail or a phone, even if the field is called “field3”.
The name gets extra treatment: it is split at the first space into first and last name, the way Segment does it and the way Meta expects in the fn and ln fields. “Douglas Matos Nascimento” becomes Douglas + Matos Nascimento.
What is NEVER captured
The exclusion rule lives in the pixel code, not in configuration — on purpose. No project rule can reopen what is closed there: password, credit card, CVV, tax IDs (CPF and CNPJ), and any field marked “do not capture”. If a site has a login form and a signup form on the same page, the pixel reads the signup e-mail and ignores the password on both.
Capturing identity means taking on responsibility. The list of what stays out has to be stronger than the list of what comes in.
Blur is not submit
A detail that cost real money before it became a rule: the pixel must not emit an event when the person leaves a field (the blur), only when they submit the form. A normal fill — type e-mail, type phone, click — generated three Lead events, and Meta counted three. Today blur only persists the identity in the cookie; the submit is what emits, and it emits once, with the whole form. It is the same family of defect we describe in deduplication beyond event_id.
Logged-in apps: beware of someone else’s form
If the pixel is installed in a product with login — a SaaS, a members area — automatic capture should be OFF. The “invite a colleague” form carries someone else’s e-mail, and the pixel would store that identity in the inviter’s session. In that case identity comes from the app itself, through an explicit identify call, not from the form. We tell how we did it in our own product.
What changes afterwards
- The lead is born identified and their Hotmart purchase matches by e-mail — even if the session marker gets cut at checkout.
- The Lead sent to Meta carries e-mail, phone and name; match quality goes up.
- The lead profile shows the name, not the e-mail.
- The audience “filled the form and did not buy” starts to exist.
In CrazyLeads capture is on by default for website pixel sources, with the pt/en dictionary, per-project rules configurable on screen or through the MCP connector — which also suggests rules by reading the page HTML — and the exclusion list closed in code.