Skip to main content

Recognising email recipients on your landing page

How the prefill link lets a page greet someone who arrived from one of your emails — and why their email address no longer travels in the link.

Written by Domonkos Horváth

When you send people from an email to one of your landing pages, you usually already know who they are. The page can use that: greet them by name, skip the email field, and file what they do onto the right contact instead of creating a second one.

The way to do that is the prefill link. This article explains what it does, what the supporter sees, and what changed for links that used to carry an email address.

Adding it to a link

In a campaign email or an automated email, add the placeholder to the link address:

https://your-page.org/sign?{{ var:prefill_link }}

That is the whole setup. There is nothing to switch on, and it works on every landing page you already have.

The placeholder expands to one parameter — cbp=… — carrying a signed token. The token is meaningless to anyone but CamBuildr: it identifies the person on our servers, and nothing about them can be read out of the link itself.

What the supporter sees

Someone arriving through a prefill link is greeted by the block they land on:

  • their first and last name are filled in,

  • their email address is shown maskedj***@example.com — so they can tell it is really them without the address being exposed on screen,

  • a That's not me option sits next to it.

The email field itself stays hidden while the card is shown. When they submit, the signup, donation or answer is matched to the right contact on our servers.

Choosing That's not me clears the recognition completely: the fields come back empty and whatever the visitor types is used instead. An address someone types in always wins over the recognised one, so a shared device or a forwarded email cannot file one person's signup onto another.

The cbp parameter disappears from the address bar once the page has read it, so it is not left in the browser history or passed on to the next site the visitor opens.

What it fills in, and what it does not

The token carries the name and identifies the person. That is all. It deliberately does not carry the ZIP code, the phone number, custom fields or anything else.

If you want those pre-filled too, add them as ordinary parameters alongside it:

https://your-page.org/sign?{{ var:prefill_link }}&zip={{ var:zip }}

The full list of parameter names is in Prefilling Forms in Apps.

Where it works

Recognition is understood by the blocks that collect a person: the form block, donation and purchase blocks, surveys and votings, user posts, commitments and the login block. A survey with Automatic Submission for Known Persons switched on submits straight away for a recognised visitor.

The recognition also carries from one page of your own site to the next within the same visit, so a visitor who moves from a landing page to your thank-you page is still known there.

Two situations where no card appears, both intentional:

  • Test sends. A test email carries a dummy token that resolves to nobody — a test send reaches a real inbox and must never carry someone else's identity. To see the real behaviour, send the email to a target audience containing only yourself.

  • Automated emails that deliver to a fixed internal address. The placeholder stays empty there, for the same reason.

How long a link keeps working

A prefill link stays valid for 18 months. That is long enough for someone to come back to an email they kept, and short enough that an old link does not stay usable forever.

It also stops working earlier in two cases: when the contact's email address is changed, and when you ask support to invalidate a person's links. In both cases every link already sent to that person stops being recognised, and visitors simply see an empty form instead.

The warning on emails that put data in a link

Writing ?email={{ var:email }} into a link still works, and emails you built that way keep running unchanged. What is new is that the editor shows a warning when you save such an email, and the same warning appears on the email's detail screen.

Nothing is blocked and nothing is rewritten. The warning is there because a value in a URL is readable by the site it points at, by that site's analytics tools, by its server logs and by the referrer of every page it opens — and because Google's and Meta's advertising policies forbid passing personal data through a URL their tags can read.

So: use the prefill link for links to your own CamBuildr pages, and keep a personal placeholder in a link only where an external system genuinely needs the raw value.

The same reasoning applies to the form option that forwards submitted values to the redirect URL. Leave it off unless the target really needs the data, and never use it for sensitive fields.

Unsubscribe links changed too

For the same reason, the unsubscribe links in your emails no longer carry the recipient's email address. They now identify the contact the same opaque way.

What a supporter sees is slightly different as a result: instead of being asked to type their email address, the unsubscribe page shows their address masked and a single button to confirm. It is one click fewer, and their address is no longer sitting in a link that anyone forwarding the email could read.

Unsubscribe links you have already sent keep working, and the per-tag unsubscribe links used with multi-consent behave exactly as before.

What you need to do

For existing campaigns: nothing. Old links keep working, old parameters keep working, and existing pages understand the new links without being touched.

For new emails: use ?{{ var:prefill_link }} when you link to one of your own landing pages, and reach for named parameters only when you need to fill more than the name.

Did this answer your question?