Segment Logic and Operators

A segment that could only ask whether a value equals something would be barely more useful than the Excel dropdown from Understanding Segments. Pick a value, see the rows that match it, done. Real questions are rarely that blunt. They sound more like: pages whose address starts with /checkout, visitors who saw the pricing page but not the demo, sessions that included a video play and an add to cart. Answering those needs two things a dropdown does not have: a range of ways to match a single value, and a way to combine conditions. Those are the operators, and they are where a segment earns its name.

Two kinds of operators

It helps to separate them from the start, because they do different jobs. Comparison operators decide how a single condition matches a value: equals, contains, starts with, and the rest. Logical operators decide how conditions combine into one segment: And, Or, and Then. Get the comparison right and each condition is precise. Get the logic right and the conditions add up to the question that was actually meant.

Comparison operators: matching a single value

The comparison operators read almost like plain English, and that is deliberate. The people who ultimately consume these reports are business users, and a condition that says Page URL starts with /checkout needs no manual. The table below shows the common ones against a single value, a Page URL of /products/winter-boots, so the difference between them is concrete.

Metrics, being numbers, take numeric operators instead: is greater than, is less than, is greater than or equal to, and so on. Revenue is greater than 100 is a metric condition, not a string one. And three operators handle whole lists at once: equals any of matches a value that exactly equals any item in a list, contains any of matches when the value contains any listed item, and contains all of requires every listed token to be present. They save building long chains of Or conditions by hand.

Negation has two forms, and they are not the same

Segment Containers introduced the Exclude container, which removes everything matching its rule at the container's scope, and left one question open: how is that different from just using a "does not" operator on a condition? The two read alike in English and diverge sharply in practice.

Consider trying to find visits with no order in them. The tempting build is a Visit-scoped condition of Orders does not exist. It returns almost every visit on the site. The reason is scope: a visit qualifies if it contains any hit where an order does not exist, and nearly every visit has such a hit, the page views before and after a purchase. The condition is true somewhere in almost every visit, so almost every visit comes back.

The correct build is an Exclude container at Visit scope holding Orders exists: include all visits, then throw out the whole visits in which an order happened, and what remains is the visits that never contained one. Condition-level negation asks whether a single hit fails to match. Container-level exclusion removes an entire qualifying visit or visitor. At Hit scope the two can look identical. At Visit and Visitor scope they answer different questions, and reaching for the wrong one is a common way to ship a number that looks plausible and is wrong.

Logical operators: combining conditions

Two conditions can relate in two basic ways. And requires both to be true, which narrows the result to where they overlap. Or requires only one, which widens the result to everything in either. The names say exactly what they do, and that simplicity becomes a trap only when a segment grows and the basics slip out of mind.

A segment of Mobile and Purchased returns only the people who are both on a mobile device and bought something, a smaller group than either condition on its own. iOS or Android returns everyone on either platform, a larger group than either alone. Narrowing and widening: that is the whole of it, until both are needed at once.

One container, one logic, and how to combine both

Here is the rule that catches people out. Within a single container, all the conditions share one logical relationship. Join three conditions with And and every one must be true. Switch the join to Or and any one will do. A single container cannot hold some conditions joined by And and others by Or at the same level.

But real questions mix them constantly. Take this one: a visit in which the customer saw page ABC and played a video, or, separately, simply saw page XYZ. That is an And pair sitting inside an Or. The way to express it is the nesting from Segment Containers, where a container holds another container: group the And pair inside its own nested container, then join that container to the remaining condition with Or.

Without the nested container, three conditions at one level would all share a single And or a single Or, and neither expresses the question. The nesting is what lets the And bind tightly around its pair while the Or governs the whole. That is the general move: group the conditions that belong together, then relate the groups.

From whether to when

And and Or answer one kind of question: whether conditions are all true, or any true. They say nothing about order. A segment of viewed pricing and started a trial fires whether the trial came first or the pricing did, or whether the two happened weeks apart. Often that is fine. Sometimes order is the entire point: viewed pricing and then started a trial, in that sequence, describes a different and more meaningful group. Expressing order needs the third join operator, Then, and the sequential segments it builds. That is Sequential Segments.