In this article, you will learn about tags, events, and custom fields. These data points are the most common criteria used when creating Segments in Drip. They allow you to better understand your subscribers, which in turn gives you more leverage in determining how to communicate with them through their customer journey.

Here’s a brief overview of each:

  • Tags attach a visual representation of what someone has done. They are commonly used to segment or bucket groups of subscribers.
  • Events are similar to tags, but also record timestamps and how often an event is performed
  • Custom fields hold data in name/value pairs.

Tags

A Tag is a piece of data you can apply to a subscriber.

For example, you might apply a tag like “monthly newsletter” to any subscriber that submits your newsletter sign up form. Perhaps they download a whitepaper, so you apply a “Downloaded Example Whitepaper” tag to easily identify their interests. A tag like “customer” might represent an entire segment that purchased one of your products.

Naming tags

You can name tags anything you’d like, but it is best practice to keep them as descriptive as possible.

And if you adhere to descriptive naming conventions when applying tags, you should be able to see, at a glance, how engaged the subscriber is:

tags-at-a-glance

The subscriber’s profile above tells you that they are a customer, have opted in to a weekly newsletter, and that they have downloaded a whitepaper.

Applying tags

The most common way of applying tags is through automation features, such as Workflows and Rules. They should be applied as a result of something that has happened, like becoming a customer. You can also apply tags using bulk operations, form rules, and the REST API or JavaScript API.

Here’s an example of how tags are applied in Workflows:

apply-customer-tag

You’ll notice that a tag of “Customer” gets applied to subscribers that make a purchase.

In Rules, you will apply tags in the action step of the automation:

apply-tag-in-rule

With Bulk Operations, you can apply an overall tag to all the subscribers involved. For instance, if you are migrating from another email service provider (ESP), you might apply a general tag when uploading your CSV file — so that you can differentiate those subscribers from the rest of your list:

bulk-op-apply-tag

You can even apply tags to individual subscribers through their subscriber profile:

manually-adding-tags-sub-profile

Tags are applied once to the subscriber.

This means that automation triggered by a particular tag will only happen once for the duration that the tag is held by the individual subscriber. The only way the same tag can get applied to the subscriber again (and repeat those automations) is if it is removed, then applied again.

If you are using our REST API or JavaScript API, you can apply tags to subscribers in your API calls.

When to use tags

Tags should be used to track generalized information about the subscriber, such as them becoming a prospect or a customer. Tags should be used in situations where recording a date is not a vital piece of information (you will learn that Events should be used for this in the next section).

 

Events

Events are similar to tags. The biggest difference is that they record the date and keep track of how many times the event has occurred. Events can be recorded multiple times, as opposed to tags which are applied once for the duration it is held by the subscriber. Some events are built into  Drip, such as “Replied to an email”, but can also be configured using integrations, rules, or API calls.

Let’s say you are using a payment integration such as Gumroad, which sends in the “Made a purchase” event. You can use that event to search for subscribers that have purchased something within the last 3 months.

Here’s how that filter might look:

actions-performed-filter

Events can be added by default by the Drip app, but very commonly you’ll see that events are also added through integrations. For example, if you set up the Leadpages integration, your custom event would be “Submitted landing page.” If a subscriber purchased a product from SamCart, the custom event would be “Made a purchased.”

Naming events

Events are best used to describe something that your subscribers have done. Just like naming tags, events can be named anything you’d like and should be descriptive.

For instance, if you run a Software as a Service (SaaS) product, you can send events into Drip to record and track essential customer milestones through REST API calls.

Here’s an example of how you would trigger a workflow via an event being sent in from another platform:

performed-custom-event-trigger

It is also important to note that naming convention and case sensitivity is crucial if you are using integrations that send events to Drip. For example, if the integration sends in an event called “Made a purchase”, but it was entered into the trigger as “made a purchase” (note the failure to capitalize the word “made”), Drip will not recognize that this event should’ve been recorded.

When to use Events

Events should be used to track when a subscriber performed an action, or when something happened to them.

For a Software as a Service (SaaS) product, and you might want to track the critical stages of onboarding. Sending events are going to give you the most concise information along with a date that the event happened. Check out an example of how you might use events in Workflows to track user onboarding in this blueprint.

For more advanced use cases, you can access an event’s properties via Rules. For more information, please see this article.

Recording Events minus the API calls

You can record your own custom events without API calls using Drip’s built-in “Record an event” action:

record-event-action

The above rule records an event when a subscriber visits a particular URL.

In some cases, Drip will automatically record events for you.

When a subscriber completes an email campaign, Drip records the “Completed a campaign” event. If they submit a Drip form, the “Submitted a form” event is recorded. Additionally, all of this data is visible on the individual subscriber’s timeline.

To see a list of events that are native to Drip, go to Reports > Events:

event-reports-view

Select an event, and Drip will return some stats for you. Keep in mind that Drip will not be able to return any calculated analytics for events that have not been triggered in your account thus far.

 

Custom Fields

Custom fields store data in identifier/value pairs. They are used to maintain data that is unique to an individual subscriber, such as their first name.

Here’s an example of a custom field identifier and its value:

cust-field-example

As you can see, this subscriber has a “first_name” custom field identifier that holds “Rob” as its value.

When creating custom field identifiers, always use an underscore to separate two or more words that would normally be separated by a space. When using Liquid for email personalization, take note of how you create your custom field identifiers, as they are case sensitive. Learn more about using custom fields in your personalization shortcodes here.

Note: Custom field identifiers should only contain letters, numbers, and underscores.

To see a list of custom fields that are currently in your Drip account, go to Subscribers > Custom Fields:

custom-fields-view

Allow subscribers to update their subscription information

Go to Subscribers > Custom Fields to select the custom fields you would like your subscribers to be able to update on their own. To make a particular custom field manageable by the subscriber, click the blue drop-down to the right and check off the “Allow Subscriber to edit” option. Click the “Save” button to finalize the change.

Since subscriber data is stored in custom fields, any custom field you allow your subscribers to edit can be managed through the subscription management page. This page is accessed when the subscriber clicks the “Unsubscribe” link, then clicks the “Update my Subscription Details” link.

Here’s an example of what the subscriber will see when managing their subscription settings:

 

The difference between public and private custom fields

Setting custom fields to public will expose those fields and their values. Therefore, they can be accessed through developer tools such as browser consoles and Drip’s JavaScript API. If you are dealing with custom fields that hold sensitive information, like a password or user ID, it would be advised to set those custom fields to private.