…And why is “with tags” almost always the wrong answer?
There’s a lot of buzz and excitement around segmenting your email list. Hop into just about any online community made up of email marketers, and you’d be hard pressed to find a discussion not touching on segmentation.
But most of us are really screwing up when it comes to how we segment our lists. Like, really screwing up.
And it’s usually not our fault. Email marketing software, who all promise the ability to send “the right email to the right person at the right time”, are teaching us – their customers – how to segment using their tool. And they all advocate using tags.
Tags have their uses, sure.
But, chances are, if you’re using tags to segment your list you’re doing it wrong. And it’s going to end up biting you in the future.
Tags are a collection of attributes (a hierarchy-less folksonomy) that you can apply to your email list.
What people like about tags is how simple they are, both to understand and to use.
If you want to figure out who your customers are, you apply a “customer” tag to each subscriber who’s also a customer. Want to email your customers? Simple! Send a broadcast email to everyone tagged “customer”.
Tags are binary. You’re either tagged “customer” or you’re not. But the use-cases for segmentation are rarely binary, as you’re about to see.
Consider the following business model:
To get customers for your membership site, you’ve built an email list that’s made up of: free subscribers who have never signed up for your membership site, people currently trying your membership site, active customers of your membership site, and former customers.
Still with me?
Here’s where things get icky…
Let’s say you want to do a big email promotion to all non-customers on your email list. Because you’re tagging customers, this is easy to accomplish: you just target people who don’t have the “customer” tag.
As a result of this promotion, you get a bunch of new trials. Awesssome! You’re tagging people who sign up with the “trialing” tag.
A bunch of trials convert. And a few months later, many of them have canceled. You add a “canceled” tag to anyone who canceled.
Now we’re getting considerably more complex…
Want to email anyone who started a trial but never converted? You’d target people with the “trialing” tag but not the “customer” tag.
How about people who have canceled? Email people with the “canceled” tag…
But hold up! What if someone canceled and then came back and signed up again a few months later?
Tags are atomic. This means that if someone already has the trialing and customer tag (which they would have – remember, they got those applied when they first signed up) those tags wouldn’t be reapplied. They’d just… still be there, and nothing would happen when your membership site tries to add “trialing” and “customer” again to a previous customer.
You’ve got a problem.
Here’s someone who had an account, canceled, and signed up again for another account. They have the “trialing”, “customer”, and “canceled” tags.
If you want to email everyone who canceled their account, you probably wouldn’t want to email this person. After all, they’re no longer canceled.
…So, how do you solve this problem?
Gah, I bloody hate tags.
OK, so we’ve absolutely wreaked havoc on the integrity of our list segmentation with this membership site.
And it’s a bit of challenge to accurately know whether someone is, say, currently going through a 7-day trial, as I alluded to above (maybe they previously had an account?)
“A-ha!”, you think. “I’ll just remove the “trialing” tag when someone becomes a paying customer, and remove the “customer” tag when someone cancels.”
This is exactly what you’d want to do.
Now there’s no ambiguity. If someone doesn’t have the “customer” tag they’re not a customer – which makes a heck of a lot of sense.
But now you’ve created three new automation rules: one that removes the “trialing” tag when someone converts, another that removes the “customer” tag after someone cancels, and then one to remove that “canceled” tag when someone starts a trial (just in case!)
And you’re starting to slowwwly inch toward a lot of unmanageable complexity.
In mathematics, there’s this concept of Finite State Machines.
The idea behind a finite state machine is that some things, like a subscriber-as-they-relate-to-your-membership-site, can only have a single “state” at once.
For example, cars are either off, in accessory (battery) mode, or on. You can’t have a car that’s both on and off.
Subscribers on your list can’t be both trialing, paying, and canceled simultaneously. They can move from state-to-state, like from trialing to paying. Or from paying to canceled. But they can’t exist in multiple states at once.
Tags allow multiple states to exist at once. There’s nothing built into tags to keep subscribers from having “trialing”, “customer”, and “canceled” all at once.
However, there is a data type built into every email database that allows for exactly this: custom fields!
That’s right, those things you probably think are just for totally custom data like first names 😉
Custom fields are pretty epic:
Our membership site tag soup becomes really simple and straightforward:
How mind blowing-ly easy is that?!
Emailing anyone who’s canceled their account (and hasn’t come back for more) is as simple as firing off an email to “membership_status” equals “canceled”.
In the above example, I hope I did a good job at covering why tags for finite state machines aren’t ideal.
Consider even simple things, like “did this person buy my course?” Presumably people can get a refund of your course, or they’re paying in installments vs. paying entirely up front.
All of these possible states (non-customer, installment customer, paid in full customer, refunded customer) lead me to think that having a “bought course” tag isn’t what you probably want.
You know, the sort of stuff that allows you to personalize emails?
If you’re segmenting your list by interest, demographic, or whatever else and have followed the standard advice, you’re probably using link triggers to tag people:
Tagging here can also lead to segmentation paralysis. Here’s why…
Let’s think about the nuanced difference between the following two questions:
“What is your favorite food?” and “What food do you like?”
On the surface, similar questions – right? However, favorite food implies one selection, whereas “what food do you like” might be none, some, or all of the available options.
When we’re talking about email personalization and the segmentation data behind it all, we’re almost always thinking of one-of-many and not many-of-many.
One-of-many segmentation has one possible outcome: they either best like pizza, ice cream, or hamburgers.
If someone chooses “pizza”, we can then send them a sequence of emails about pizza. Ditto for the other options.
But with many-of-many segmentation, we risk overwhelming our subscribers with too many options. Should somebody get an avalanche of food-related emails because they happen to like a lot of different types of food? Probably not.
So when you’re thinking through list segmentation around who someone is and what they want from you, you’re most likely expecting a single answer that you can use to precisely change something about how you communicate with them.
Remember: tags are wild and undomesticated beasts.
There’s nothing keeping someone from clicking ALL THE LINKS and ending up with a ton of tags applied. And there’s zero referential integrity with tags (outside of you creating your own “If A, then remove B and C tags if they exist” rule.)
Custom fields should be used for one-of-many segmentation.
Rather than having link triggers that write tags when link triggers are clicked, you could instead just change the behavior of your link triggers to set a custom field instead of a tag.
To the end user, there’s absolutely zero difference.
But your contacts will be much happier, because you can email people in confidence without the risk of there being any segmentation mixed messaging or overwhelming people with reckless automation.
There are two scenarios where tags should be used:
This person has submitted this opt-in form, or they haven’t.
They have finished this email course, or they haven’t.
Exercise caution, however: even though plenty of things do look binary, like whether someone’s attended a webinar or completed your email course… are they really?
Think about webinar attendance. That’s a finite state machine, right? They’ve registered, they’ve attended, and they either stayed to the end or bailed early. You’d absolutely want to use a custom field to track this.
Or with email courses, they’ve either not started your email course (the “email_course_status” field is blank), or they’re currently in it (that field is set to “active”), or they’ve finished your email course (the field is set to “completed”.)
The more you start thinking through things that appear binary and might lend themselves to being tracked with tags, the more likely you are to doubt that binary is the way to go.
I use tags to track binary actions like:
Remember how I mentioned above that, as marketers who want to deliver great and personalized experiences, we tend to really mean one-of-many vs. many-of-many?
But there are very legitimate reasons sometimes to store multiple choices. And, in those scenarios, you’ll want to use tags.
For example, I might want to know what blogs a subscriber reads.
Not only could this be useful for reporting (the subject of another, future article), but I could also quickly do AND/OR email targeting. “Find me everyone who reads Mixergy or Hacker News.”
In this example, I’m totally fine using tags to track this stuff.
Segmentation sophistication, like with just about everything in life, is a spectrum.
Don’t read this article and think that you’re doing it all wrong and that your readers are going to send you hate mail because your segmentation game is less than ideal. Your subscribers are clueless about how you go about segmenting them.
But, hopefully, you’ll come back to this article when you add some new automation and decide to refactor how you’re segmenting your email list.
At RightMessage, we want to help people better segment and personalize their list. And many new customers are confused by our bias toward custom fields (“how do I tag people after they answer a survey question…?”), and our hope is that you now see the risks associated with an over-reliance in tagging.
