Evolution of the Segment Editor

Problem Statement: As a non-programmer, I just want to select a subset of people from a database. However, when I try it’s either really hard requiring SQL editing, or the UI is so difficult that is makes me want to puke. Therefore, I will just not do it very often.

Competitive Context

When I started working on this problem in 2006, I first looked at the approaches of different programs and services. Salesforce used a report builder UI that had over 8 different pages with hundreds of scattered details and options. It took 15 minutes to do even the most basic selection. I knew this could be dramatically improved.

Eloqua had a slightly better system, but it was pretty hard to understand. It assumed the user was more of a programmer than a layman. Lastly, a programmer could use SQL to program a query, but this obviously wasn’t easy for a non-programmer. I read a book on SQL to help me understand the “system model“.


When I was conceiving of a solution, I thought about different interfaces that connected to this problem. One influence was an old software suite I previously used from IBM called Rational Rose and Rational ClearQuest. I remember it being used for bug tracking, like JIRA. At the time, it had this interface where you could drag and drop a filter into an area to create a filter set. It was segmentation of bugs. The drag and drop had struck me as a cool interface with potential.

I was also influenced by the movie Minority Report with Tom Cruise. He had this crazy 3D holographic interface. It’s actually terrible to use because you have to have your arms raised over your head all the time. It’s exhausting!

Tom Cruise was exhausted using this UI

Despite it being horrible to use, I loved the idea of a kinetic UI. Something you manhandled and shoved pieces around. I told the engineers that I wanted it to feel this way. (They didn’t get it at first)

The last piece of influence was iTunes. It was new at the time and had a concept of a “list” and a “smart list” to segment artists and songs. A list was just a bunch of songs with no rules. A smart list was a dynamic rule-based set of songs, such as “All songs where genre = jazz”. These were my UI influences for my first attempt at a new solution.

First Attempt

At Marketo, we borrowed the term from iTunes and called it a Smart List. I extended the filter style system from IBM Rational and made it feel like Minority Report. The first attempt was slow and buggy, but it was pretty cool.

When I onboarded the first 50 customers of Marketo, I always showed them the Smart List functions first. Basically I said, “Let’s get to know your data.” Usually by the end of the first session, they were thrilled with their purchase. Segmentation was a hit right away. Whew!

To be fair, it was also slow and very buggy. But the interface worked, so I count it as a victory!


The next big innovation was triggering. This came very quickly after the basic “Batch” smart lists. The specifics of triggers were that they occurred one lead at a time. The functionality of triggers vs batch was important and had specific nuanced differences. I used a system of past and present tense to differentiate between:

  • Fills out form (present tense, happens now)
  • Filled out form (past tense, happened before)

Combining this with filters created a meta-language for marketers to describe a set of people in various different use cases.

Anonymous Filters

A big update added the idea of anonymous and known records. An anonymous lead was someone visiting a website. I described them as footprints in the snow. You could measure the footprints, see where they are going, even guess certain truths about them, but you didn’t have a name or email address.

By using some clever engineering, we could infer lots of data like city, state, and even company using reverse IP lookup tables.

An anonymous lead became known when they filled out a form or clicked a link in an email. This concept was later adopted by most marketing tech vendors.

Qualification Rules

Once you had triggers and anonymous leads, you needed to control how often someone would qualify for the segment.

Qualification rules became very important to control flow

At this point, Marketers were becoming visual programmers. They were controlling the flow of mini-programs that were quite complex. This would lead to serious problems like “traffic cop“.

Special Filters

Things got a little meta with filters like Member of List, or Member of Smart List. You could basically nest smart lists in a way that created sophisticated cascading functions. This was good for complex situations, but also made the system harder to understand.

Random Sample is another special filter that was really useful. It would grab a percentage of the segment rather than all of it. Unfortunately, this function was extremely slow. The engineers hated it.

Advanced Logic

At first, the segment editor had ANY (OR) or ALL (AND) filters only. Eventually, we added Advanced which combined AND/OR and parentheses. You could say (1 or 2) AND (3 or 4). Some interfaces I have seen have tried to represent the and/or logic nesting visually. I think this is a mistake because it becomes too confusing after 3 levels of nesting. Many systems try, but I have not seen a deep nesting visual UI look sensible to me. I used the parentheses based on how spreadsheet formulas worked. One truism is that marketers understood and loved their spreadsheets. More on this later…

The Relationship Segment Editor

I had a chance to rethink segment editing at Engagio, but unfortunately, it never got built. Up until this point all segments resulted in people/leads. This new idea I designed let you decide what you wanted to output. You could for example say “Show me all the support tickets where the reporter was from Japan”. You could then switch to the people, or even opportunities for those accounts. To be able to pivot easily would have made a great exploration tool for marketing. Unfortunately, it was consigned to the shelf and has never been built. Startup idea, maybe?

Hybrid Nesting Model

One of the problems with segments was that they often got confusing when one segment referenced another. Also, when segment rules became too long, it made the whole thing hard to read. My latest design (shoutout to Alexis for an amazing collaboration!) tries to improve on that issue. We created one level of nesting that allowed you to put human descriptions on chunks of segment rules. it also allowed for 2 levels of advanced logic. This tried to find the balance between too flat and too nested.

I would put pictures here, but it’s not fully released. Sorry.

Feedback and other Innovations

There are several innovations in the works to give even more feedback to users and innovate how a segment is used. I’ve seen segments used for automation, reporting, quickly getting a headcount of leads, dynamic logic rules, and more. Segments are the foundation of any automation system.

It’s been 15 years since I first started looking at this problem and I think I still haven’t shipped the perfect segment editor. This is the life of a designer, you don’t ship everything you design, but you still have to give your all and make the best design you can. Today, I am proud of my contribution and innovations and hope I can make something even better tomorrow.

Sorry this post is so long. I was just thinking about segments and wanted to write a history for myself. I won’t blame you for skipping some of it. 😊

Whatya think?