Help · Audience

Profile properties

Profile properties are the things you know about the people on your list that we do not collect for you — a skin type, a birthday month, a size, a pet's name. They arrive when someone fills in a field on one of your forms.

Once a property is on your profiles, you can do two things with it. You can put it in an email — "Your sensitive-skin routine is 20% off" — and you can build a segment from it: anyone whose skin type is sensitive. It is the same property both times, so the email you write and the people you send it to cannot drift apart.

You do not create properties here. They appear as soon as your profiles have them.

Where they come from

One thing writes them today: a form field. When you add a question to one of your forms — what is your skin type? — the answer lands on the profile as a property, named by the field's key. That is how a property starts existing, and for now it is the only way.

Importing a spreadsheet and letting an integration write one are both coming; neither exists yet, so nothing outside your own forms can put a property on a profile right now.

Nothing declares a property in advance. The menus you see are built from what your profiles actually carry, ordered by how many of them carry it — so the property you use most is the first one offered, and one that was typed onto four profiles by mistake sorts to the bottom where it belongs.

Building a segment from one

In the builder, choose Who they are. The pulldown offers the four details we keep our own column for — First name, Last name, Email, Phone — then First seen, and then your own properties, spelled the way your data spells them.

Anyone whose skin type is sensitive.

The same comparisons the rest of that menu entry uses: is, is not, contains, does not contain, starts with, is set, is not set. Capital letters do not matter — VIP and vip are the same answer, so a value you type by hand matches the data you already have.

"Is not" and "does not contain" include everyone who never answered. This is the one behavior worth knowing before you write a rule, because it is the opposite of what some other email tools do. Anyone whose skin type is not oily catches the people who told you sensitive and the people who never told you anything, which is nearly always the group you meant. If you want only the people who answered, add a second condition on the same property: is set. Starts with works the other way — it asks for something that is there, so a blank answer never matches it.

"Is set" means there is something we can print. A property that is there but empty, or that holds a whole list rather than a word, counts as not set — which is the same test the email side applies, so a person who is in the segment is a person whose email shows the real thing.

The pulldown shows your 200 most-used properties. If you have more than that, choose Something else… at the foot of it and type the name. It builds, counts and saves exactly the same way.

In an email

A property in an email is a variable, the same as a first name: you write it once and each person receives their own.

Every property you put in an email needs a fallback — a word to show for people who do not have that property filled in. That is most people, most of the time, and a sentence with a hole in it is worse than a sentence with a general word in it.

This is why it is required rather than suggested. A property usually arrives through one form field, so a store with 40,000 profiles and a question that has been on its signup form for three weeks might have the answer for 900 of them. "Your daily routine is 20% off" reads fine to the other 39,100. "Your routine is 20% off" reads as a mistake in your store.

A few things print the fallback even when the property is there. A property holding a whole list, or a yes-or-no, or an answer longer than 500 characters, shows the fallback instead — those belong in a segment rule, not in the middle of a sentence, and a very long answer would break the layout of the email around it. A property that is there but blank counts as not being there at all.

A preview with nobody chosen shows your fallbacks. That is honest rather than flattering: the fallback is what most people receive, so it is what an unprimed preview should show. Choose a real profile to preview and you will see that person's own answers.

What we do not do yet

Properties have no type. A birthday month is text to us, which means you can ask whether it is November but not whether it falls in the next thirty days. Dates are the first thing we will add, and doing it wrong is worse than waiting — a date read as text sends a birthday email a day early for half your list.

There is no rename, no display label and no way to hide a property from the menus. The name your form field gave it is the name it has. Sorting by how many profiles carry it is what keeps the menu useful in the meantime.

The Building a segment page covers the rest of the builder, and Forms covers adding the field that starts a property existing.