Written by Drip

Tags vs Custom Fields

This is a topic for people who are just getting started with a CRM that uses Tags & Custom Fields.

Tags and Custom fields are both great ways to store information on a subscriber. But they each have their strengths and best use cases. 

Starting out, I had tags for everything:

Interest in products, purchased products, pages visited.

I started with ConvertKit, which was all about tags, then I switched to Drip, and brought the tag everything methodology with me.

I quickly collected a few million tags and things were getting out of hand. Once I started seeing the workflows other Drip users were building with custom fields and Liquid, I did a 180° on tags.

Using tags is fine by the way, this isn’t a hit on people using tags, there is honestly no right or wrong way. I’m just giving you my opinion on the limitations of tags. All of this will sound totally obvious, but hey, as a newbie a few years back this might have helped me.

First up, here is what I like about tags:

Tags are great for describing where a customer is, in their journey.

If you break down your strategy and customer journey, you will have a bunch of steps you will want to hit: lead, subscriber, customer, referrer. If you break down your customer journey, you’ll probably find you don’t need so many tags.

If I was starting a new Drip account today, I’d probably have a few tags and almost everything else would be in custom fields. 

Why I don’t like to over use tags:

Some of the things I might want to track are: customer journey, interests, pages visited, physical location, gender, age, things in the shopping cart, products purchased, coupons, career.

Do you really want to mix all of that data together into a big soup of tags? It becomes messy real quick.

For me, tags work well for customer journey, and maybe high level interests, everything else should go into custom fields.

Why I prefer custom fields:

Custom field data can be sliced and diced, added to forever and be a really long string. Eg: Having a purchased field makes it easy to find who has purchased a product, with Liquid you just search that one field instead of checking a bunch of tags. 

This is how I create a string of purchased products:

So this purchase field can obviously be used in a decision tree workflow, but it could also be easily searched in Liquid.

{% if subscriber.purchased contains "thetour-" %}{% else %}
Get tour tickets!
{%end if%}

Having this purchased field lets me use liquid to search for the part of a SKU that defines a parent product like “thetour-syd” and return the purchasers of sub products like “thetour-syd” and “thetour-melb” “thetour-bris“. So instead of searching for a bunch of tags for each sub product, you can just searching for the parent product. 

It also lets me use liquid to search for part of the SKU that defines a sub product and return all purchases of sub products across different parent products. Eg: “syd” is in “newtour-syd” and “oldtour-syd“, so now I can find all of the people in Sydney that went to one of the past tours.

Again, this might sounds super obvious, but if you’re getting started hopefully this just gives you some insight before you create a million tags like I did ?.

Last modified: February 2, 2020