AudienceScience Helios Segment Creation

Project

As part of the transition from an internally used Data Management Platform product, to a client-accessible SaSS version, each section of our tools needed to be re-evaluated. Rather than just providing a new visual design, took and hard look at what was useful, confusing, or newly required to support the new direction.

The highest priority within the DMP was the segment creation and definition. It is the heart of the DMP, and the area where the user takes all of the ingested data points to define the logic that makes a useful audience for a future ad campaign.

Challenge

The value of the product is the ability to create highly custom segments with very custom logic where you use dozens of clauses that are joined by “and,” “or,” or “not.” The previous UI was functional, but made custom logic very difficult to set up, and nearly impossible to re-visit and be able to make sense of the rules that were previously created. As a result, during the user interviews we discovered that many segments in use were not actually working in the way the user expected.

Solution

The main improvement goals were:

1. Make the UI clear to reduce logic errors in the segment definition:

   Instead of supporting full custom logic, I defined a single logic structure that worked for most use cases. In this design, the segment rules are set up like a sentence: "People must have done AT LEAST ONE of these [rules] AND must have done ALL of these [rules], BUT not have done ANY of these [rules] in the last [timeframe]. This give a segment with the logic: (A OR B OR ...) AND (C AND D AND ...) AND NOT (E OR F OR...). By filling out some or all of these clauses, over 85% of existing segments could be setup.

   For the remaining segments that needed additional logic, I added the support for nested segments. A rule within a clause could be membership in another segment. By using the default logic in one segment and then using that segment in a rule of a larger segment, the user gets the effect of sophisticated logic, while all segments still have one logic pattern, and the user has far les on a single page that they have to be able to mentally process.

2. Improve ability understand what the segment logic is doing for users that did not build the segment:

   By making the structure of a segment a sentence rather than logical operators and lots of parentheses, the structure of the segment is much easier to understand.

   By also using nested segments for the most complex segments, it lets the complexity be broken up into bite-size pieces and be named. Having the name stand in for the lower set of logic, it is much easier to understand.

   For example, if I were to create a segment of "Parents that exercise," I would need a lot of rules about sites that user could have visited that indicate they are a parent, as well as sites that show that they exercise. This may end up being hundred of rules all together. If instead, I create a segment call parents which has all of the definition of what a parent is, I don't have to understand what each rule in the "parent" segment is, order to understand what that segment does in the "Parents that exercise" segment. I can then combine that with the rules for various sports sites, or create an additional segment that defines "exercisers." With this, the "Parents that exercise" would only have two easy to read rules that are and'ed together to make the full segment.