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.

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

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.

It only works on pages hosted on CamBuildr. Only CamBuildr can read the token, and it is not part of the public API, so no other website or tool can create or decode one. A link to your own website, a petition tool or any other external system gets nothing from it — use ordinary placeholders such as {{ var:email }} or {{ var:firstname }} there instead (see below).

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

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.

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:

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

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:

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.

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 a reminder that the value is personal data: in a URL it 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 Google's and Meta's advertising policies forbid passing personal data through a URL their tags can read.

So:

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.

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.

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 CamBuildr pages, and reach for named parameters when you need to fill more than the name or when the link points at any other website.