CarpeMessaging
Request early access

Help · Content

What a form collects

What a form may write

A form fills blanks. It does not overwrite what you already know.

The reason is one sentence. A form can be filled in by anybody, about anybody — they type an address and press a button — so what a form is trusted to tell you is what you did not already know, and never something different about somebody you do. Consent is the one exception, and it is deliberate: the most recent thing a person said about hearing from you is the thing that counts, so typing their address into your form is treated as their answer, whatever was recorded before. Consent sets out where that stops.

Catch-all addresses

A catch-all domain accepts mail for any name, so nobody outside it can tell whether a mailbox exists. By default, somebody on such a domain who browsed your store before signing up is accepted, and you can email them straight away. The switch is the Catch-all addresses card in Settings → Email.

Some email domains are set up to accept mail sent to anything at all — a made-up name at that company is answered exactly like a real person's address. Those are catch-all domains, and because the mail server says yes to everything, nobody outside that company can tell which mailboxes actually exist. Work addresses are the common case, so this is not a rare corner: a good share of the people who sign up with a business address are on one.

When somebody submits your form, their address is checked at that moment — see Verified identity. On a catch-all domain that check has nothing useful to say, so what happens next depends on one question: was this person actually on your store?

The same goes when the check says an address on such a domain has "low deliverability". On a domain that answers yes to every name, that label mostly means the check could not see the mailbox, so it is treated as a catch-all too — unless the domain is a throwaway email service or the address is flagged as harmful, which are never accepted.

By default, somebody who browsed your store and then signed up is accepted, and you can email them straight away. Their pages loaded, your form appeared in front of them, they typed their address into it. That is a person, and their company's mail settings are not their doing.

It is recorded for what it is. The profile says it was accepted because the person browsed your store — not that a mailbox answered. Those are two different facts and the app never lets one stand in for the other, so a mailbox that really did answer still means exactly what it always meant.

Browsing means browsing. Pages of your store opening in somebody's browser, products being looked at, something going into a cart, your form appearing in front of them. A checkout on its own is not browsing — an address that turns up at checkout with no visit behind it is the shape automated traffic takes, and it is not accepted on this rule. Without a visit, the profile is not confirmed yet: their consent is recorded, they are thanked like everybody else, and no email you send reaches them until an order confirms them.

The setting

In Settings → Email, one switch, on when you start, on the card headed:

Catch-all addresses

Disable it and these signups are treated like any other address the check could not confirm — consent recorded, the person thanked, and not emailed until an order confirms them. The line under the switch changes with it, so what you read there always describes the store you are actually looking at. An owner or a manager can change it; a marketer and a viewer can read it.

The trade. Some domains accept mail for any name, so the mailbox can’t be checked. With this on, you can email such an address when the person browsed your store first, and a back-in-stock request that passed the “I am human” check with a first name gets its back-in-stock emails. A few may turn out not to exist and may bounce; a bounce marks the address “Do not email”.

The numbers beside it

Under the switch, the app keeps count for you:

N profiles accepted this way · M of them have bounced since

The first number is what the rule won you: profiles you have that would otherwise be sitting unconfirmed. The second is what it cost: how many of those addresses turned out to be nobody.

Read them as a pair. While the second stays a small share of the first, the rule is doing the job it was put there for. If it ever grows into a real share, disable the switch — the profiles you already have keep everything they have, and only new signups change.

Asking for a telephone number

Add a Phone number block, under Fields in the Add list, to ask for a number beside the email address or on a later step. Text messages have to be enabled first, and until your number is approved your number approval form is the only form with a phone number you can publish.

A form can ask for a telephone number beside the email address, or on a step after it. Phone number is in the Add list, under Fields, next to Email address. It takes the label and the placeholder you write, and whether it is required is yours to say — a form that asks for both usually wants one of them optional. One panel asks for a number once: a panel that already has the block is offered it grayed out, with the reason beside it.

A form can ask for a phone number and no email address at all — your number approval form does, and so can any form you build for texts only. A person who signs up on one is found by their number: if one profile in your store already has that number, the sign-up is recorded on it; if none does, a new profile is made with the number and the first name they typed; and if more than one profile shares that number, nothing is recorded, because there is no way to know which person it was. A number that has been blocked from your texts is not recorded either. Once your number is approved, a new person is texted the six-digit code, and typing it back confirms both their agreement to your texts and their profile.

The first name can sit on a panel before the number. A text-only form that asks for the name on one panel and the number on the next keeps the name and stores it with the number, on the same terms as a form that asks for both on one panel: a new profile gets the name they typed, and a profile that already has that number keeps the name it has.

A panel that asks for a number needs a consent sentence on that panel, the same way a panel asking for an address does, and it should be about text messages rather than email. The words are yours. The two-step starting point Email, then phone number ships one worth starting from.

Text messages have to be enabled first. Until they are, a form carrying a Phone number block will not publish. The editor says so under the preview, before you press Publish, and it names the panel and where the switch is.

And then one form goes first: your number approval form. The evidence a carrier asks for when they approve your number is a published form asking for one, so your store has a form made for that — Number approval form, made under Settings → Text messages and nowhere else, which also makes the page it sits on, your store's Text sign-up page — and before your number is approved it is the only form with a phone number you can publish. Every other form with a Phone number block says, where its Publish is:

This cannot be published until after your phone number is approved.

Build them in the meantime; they publish like any other form once your number is approved. If a carrier turns your number down, your number approval form can still be published — fixing it is how you answer the carrier — and every other form with a Phone number block waits. If texting is paused, none of them can be published, the number approval form included. Resume and going back to an earlier version follow the same rule as Publish. Forms already live stay live.

Easy Opt-in

Once a carrier has approved your own number, a telephone number on a form is confirmed before the sign-up finishes: we text a six-digit code, the form shows a box, and the person puts the code in on the same page. On an iPhone the code is usually offered above the keyboard; on a Mac that gets the iPhone's texts, it is an AutoFill suggestion under the box; anywhere else it is typed. The form confirms it as soon as all six digits are in. Only then do they see the thank-you panel and get the discount code, if your form hands one out.

There is nothing to set up and nothing to disable. Wherever your forms can show the code box, this is how a telephone number is collected, and it is what lets you text the people who give you one — a theme still drawing an older version of our form blocks collects the number without the code. There is more about it under Text messages.

The words on the screen that asks for the code are yours, once your number is approved. Until then the Phone number block shows one line in place of the card — The code is enabled when your number is approved. — because there is no code to ask for yet. After approval the heading, the line under it and the button are on the block’s Confirmation code card, and you can write your own — put {{last4}} in the line where you want the last four digits of their number. Leave one empty and the form uses ours: Enter the code we texted you, We sent a six-digit code to the number ending 1234. and Confirm. The lines for a new code, a different number and a mistyped code stay ours.

On an iPhone, or a Mac that gets the iPhone's texts, nobody has to type the code. On an iPhone it is offered above the keyboard, and one tap puts it in the box. On a Mac it is an AutoFill suggestion under the box, and one click does the same. Anywhere else it is typed. However it gets there, the form confirms it as soon as all six digits are in. A wrong code says so under the box and leaves it ready for another try.

You can see the screen that asks for the code in the editor. Once your number is approved, open the Phone number block and choose Confirmation code beside Preview, above the preview: it draws that screen in your words with a sample number, and sends nothing. Choose Number box to go back. This only changes what the preview shows — the six-digit code is always part of a form that asks for a number once your number is approved, with nothing for you to change.

Before your number is approved, the only form asking for a number is your number approval form, and it still collects numbers and still writes down that the person agreed — there is just no code, because there is no number to send one from, and its words promise none. Those people show as Awaiting confirmation on their profile and are excluded from every marketing text until they confirm.

A number that texted STOP

Somebody who once texted STOP to your number and now types that number into a form is not thanked as if they had joined. The form shows them how to text START, waits for it, and then texts the six-digit code. The code earns the thank-you and the discount, exactly as for anybody else.

What they see first is This number asked us to stop texting it. Text START to rejoin. and a Text START button. On mobile, the button opens their messages with your number and the word START already typed; they press send. On desktop the form shows From your phone, text START to your number, with a code they can scan with their phone's camera to do the same. Your number and the word START are always on the panel as plain text too, so they can type it themselves if the button does nothing on their phone; on mobile, Check again is on the panel from the start, and pressing it after they send starts the wait.

Then the panel reads Waiting for your text…. When their START arrives the form texts the code, and the rest is Easy Opt-in. If nothing arrives in about ten minutes the panel says No text yet. You can text START any time to rejoin. and offers Check again.

Only their own START counts. A START from another phone, to another store's number, or sent before they filled in the form does not move the form on — a form can be filled in by anybody, and STOP was that person's own word from that handset. A START on its own is not enough for the discount either: anybody can type a number into a form, and the code is how we know the person at the form is holding that phone.

Closing the page does not lose their START. If they close the page before the code comes, filling in the form again within a day picks up where they left off, with the same discount, on this device or another one, such as the phone they texted from; they are not asked to text START again. That includes a browser that blocks your store's cookies, once their START has reached us. After a day, the discount needs a new visit to the form.

A number marked as not wanting your texts, without a STOP from the phone, is shown the same panel, with Text START to get our texts. as its first line, when a START from that phone is what gives that consent back. When it is not, the form never asks them to text START.

A STOP that never reached us still counts. If their STOP reached the carrier but was never passed on to us, the carrier refuses the code text. The form notices, shows them the same panel, and their profile shows text messages as Unsubscribed until they text START and the form sees it: while the page is open and waiting for their text (on mobile, once they press Text START or Check again), otherwise the next time they fill in the form with that number. That holds even if they had your texts before: the carrier's word about the phone is the one that stands. That next form goes straight to the code — they are not asked to text START again.

The email half of the form is unaffected. If the form also asked for an email address, that signup is recorded exactly as it would be without the number.

Discount

A form can hand a discount code to whoever signs up through it. You say so in the form itself: add a Discount code block to a panel, open it, and choose what it gives away.

It goes on a panel people reach after signing up, never the first one. The first panel is where somebody is still deciding; a code there would be a code for nothing. So the entry panel will not take a Discount code block at all — not even one that names no discount, because somebody who adds one there is about to name one, and meeting that at publish is worse than meeting it now. The Add list will not let you, and says why:

A discount code cannot go on the first panel — nobody has earned one yet when they arrive.

It also refuses a button that is not a Sign up button leading to a panel that carries a discount block giving something away.

A form may give a different discount away on each thank-you panel. If your form asks a question and sends one answer to one thank-you and another answer to another, each of those panels can carry its own block and its own discount. Whichever panel the person you are looking at actually arrived on is the one whose code they get. One panel, one discount: a panel that tried to give two away is refused.

If one person reaches two panels that each give a code away, the later code replaces the earlier one. A panel that shows a code can ask something more — a telephone number, a question — and its Sign up button can lead straight to a second panel with a better offer. When that second code is handed over, we ask your store to delete the first one; the deletion usually lands within a few minutes. It is not guaranteed in every case — if the person's page has been open for a long time, or they are on another browser, the first code can stay usable. A code they already used at checkout is left alone, and so is a code you made yourself and give to everybody — only a code made for that one person is deleted. The later code is always given, even if they already spent the first. What the second panel says about it is yours to write.

A code you give to everybody is never replaced, and never replaces one. If either of the two panels shows a code you made yourself for everyone, both codes stay usable. Whether a shopper can use them together at one checkout is up to the two discounts: set them to combine in Shopify, in each discount's Combinations section. The form's editor reminds you of this on both discount blocks when a form is built this way.

A form with no discount block hands nothing out, and its thank-you panel says whatever you wrote on it. The app adds no sentence of its own.

The code puts itself on their cart

Nobody has to copy it. The moment the code appears on the panel, it is already on that person's cart — the cart page shows the discount line, the totals come down, and there is nothing to paste at checkout. It stays there if they close the form, and it is remembered in their browser, so a code they read today still works when they come back tomorrow.

The code itself is not a link, and nothing about it is pressable. It is there to be read — and copied, if they want it for later. The way on into your store is a button, which looks like one.

A line under the code says so, in your own words. It reads Applied to your cart automatically. until you write something else in Words after the code is applied, on the block, just under Words before the date. It is one short sentence; leave the box empty and the standard one is used.

You choose the words. You do not choose when they appear. The line is drawn only after the cart has answered that it really has the code. If your store will not take it — it ended, it ran out, the cart does not meet its conditions — or if the cart cannot be reached at all, no line is drawn: not a blank space, no line at all, and nothing on the panel ever claims a discount that is not really there. The code stays on screen either way.

And a button can put them in your store with it. On a panel that gives a code away, Where it goes offers Your store, with the code applied, and a field for which page — leave it empty for your front page, or pick a collection to send them straight to the things the discount is for. It has to be a page of your own store. This is also the way out for somebody whose cart would not take the code: the button works whatever the cart said.

Or straight to checkout with one product. Where it goes also offers A product, at checkout: choose a product and the button adds one of it and opens checkout with their code on it. Its discount has to take that product off with nothing else needed — not "buy X, get Y", not free shipping, no minimum, and it must apply to that product by name, not through a collection — and the form checks that with your Shopify store when you publish. Somebody with no code to carry goes to the product's page instead, with nothing added.

While you are building, the line is always on screen. The preview has no cart to check with, so it shows you the sentence you wrote — which is the only way to see what you are writing. On a real storefront it waits for the cart.

What the block asks, in order.

The first three are the Which discount and Each person gets cards; the last three are Discount details. The email editor's discount block asks the same questions in the same three cards, so a merchant who has set one up has set both up.

A unique code for each person. Each person gets a code made just for them. It works once, it can have its own expiry date, and when it is used you can see who used it.

The same shared code for everyone. Everyone gets CARPE15, the code you set up in Shopify. It expires when the discount does, and an order that uses it cannot be traced to any one person. The block names your own shared code where this page says CARPE15.

Unique codes are a setting on the discount, not on the form. If a discount does not give each person their own code, that option is closed here and the block says so: enable unique codes from the discount itself — a marketer, manager or owner can do that — and then this form can give each person their own. The same holds the other way: a discount that mints per person cannot be handed out as one shared code.

Nothing you choose here takes effect until you publish the form. The block is part of your working copy, exactly like the words and the images beside it, so you can set an offer up on Tuesday and put it live on Friday. Taking the block out and publishing is how you stop giving it away — and codes already handed out keep working, because they are real codes at Shopify and nothing here withdraws one.

The two lines under the code. A thank-you panel can say more than the code itself. Discount details draws a line of terms under it: the Shopify default, exactly as it reads in your store, which is the answer most people want because it already matches what you set up there. Choose Your description to rewrite it, and it starts from that wording rather than from an empty box. Choose Do not show it and no line is drawn. Without a terms line, people write in to ask what the code is for.

Show the expiration date draws the day this person's own code stops working, in your store's clock, with the Words before the date you choose — "Use by" until you change it. Disabling it changes what the panel prints and nothing else: the code still stops working on the day Expires names. It is the person's own day, not the discount's: two people who sign up a week apart read two different dates off the same block.

You can style both lines together. The Details text card under the code's own Text card sets their size, weight, color and alignment — one setting for the pair, because they read as one piece of small print. They keep the code's typeface, and until you change anything they are drawn small, in the code's own color and alignment.

Both lines are drawn only when a code is actually handed over. If no code could be given, the panel shows the words you wrote for that case and nothing under them — terms below a sentence that is not a code would describe an offer nobody received.

"Expires: 3 days" counts from the moment a person receives the code. A code handed out on September 6 with a 3-day window works until the end of September 9 in your store's clock — for the person who signed up on the 6th, and for nobody else. It has nothing to do with the day you saved the form or the day you published it, and it is the same day the "Use by" line on their thank-you panel names.

If the discount itself ends sooner, the code ends with it. A 30-day window on a discount that closes on Friday gives everybody a code that stops working on Friday — the window can never outlive the discount it comes from.

Some things cannot be settled while you are typing and are refused at the publish, in a sentence naming what to change: a discount that has ended, one that is no longer in your store, a window that would outlive the discount, a code for each person with no deadline anywhere to be found, the shared code with no code chosen, a code that is no longer on the discount, and a discount in a rollout in Shopify. If two panels are both wrong you are told about both, and nothing is published until they are fixed. There is more about all of it under Discounts.

People already on your list

When somebody who already has your consent fills in a form, they see your Already on your list panel instead of the ordinary thank-you, and get no new discount unless you say so. You choose what happens on the form, under When someone already on your list signs up.

Who counts as already on your list. For email: somebody whose consent to your email was already given before this signup, including people you imported. For texts: somebody whose number already consented and was confirmed, and has not texted STOP since. Somebody who started a text sign-up and never typed the code back is not on your list yet — they are sent the code, like anybody new.

The three choices.

It shows on screen, for email too. Anybody who types an address into your form can see whether that address is already on your list. That is the cost of never sending somebody away to check their inbox to find out what happened, and it is the reason the panel's words are general. A person in Do not email never sees it: they see your ordinary next panel with the words you wrote for when no code can be given — the same thing every shopper sees when your discount cannot be handed out — and no code.

For texts, the panel comes after the code. A number is only known to be on your list once the person types back the code we text them, so they see the code step first and the Already on your list panel after it.

A greeting by name, only when it is safe. If they confirm a code sent to their profile's own phone number, the panel greets them by first name and thanks them for their orders — Welcome back, Jane. Thanks for your 4 orders. Their own number is a phone number from your store's Shopify customer record, or one you entered on their profile — or, for somebody who only ever gave a number on a text-only form, that number once they confirmed it with the code. A number that came from a form beside an email, an import or another app does not count, even the next time: anybody could have typed it beside their address. Nothing else is proof enough. An email-only form always uses the general words, because typing somebody's address proves nothing about who is typing.

One offer per person

Each discount on a form is handed to an email address or a phone number once. Somebody who gets it, unsubscribes, and signs up again does not get a second code: while the first code is still unused and has not expired, they are shown it again; after that they see the Already on your list panel with no code. The same holds for a number, even typed beside a different email address.

A VIP gift follows the same rule. Somebody who comes back sees the same gift and the same code, and once that code is used or has expired, the panel shows the words you wrote on the gift's block for when no code can be given — Thanks for being one of our VIPs until you change them. A used code is never replaced with a fresh one.

A returning customer on a new device

Typing an address does not prove who is typing, so a form does not treat the person at the keyboard as the customer that address belongs to. When an address already belongs to one of your profiles, their signup and consent are recorded as always, but a later step of the same form does not save to their profile, and a phone number typed there is not added to it.

That protects your customers from a stranger who types their address. It costs something too: a returning customer on a new device who answers a second step of your form does not have that answer saved, and under Give them the offer, a discount that sits after a second step is not reached. A form that confirms a code sent to their profile's own phone number (see A greeting by name, above) treats them as themselves from then on.