Crowd Analytics Segmentation Capabilities

Visit-based segmentations bring clarity to KPIs and reporting and help stakeholders think more deeply about the business (which is, after all, the point of analytics). As I mentioned in my last post, the demand for better segmentation has been slow to materialize in people-measurement, lagging far behind digital analytics. Fortunately, that demand is starting to grow, and we’ve been releasing continually improved capabilities into our DM1 people-measurement platform.

In today’s post, I’m going to walk through the Segment Builder capabilities. Then I’ll tackle Segment Sets, which play a special role in reporting, and, finally, I’ll wrap up this series by working through an example Segmentation Set for a traditional apparel retailer.

Let’s take a look at the DM1 Segmentation Builder and break-down some of the capabilities it provides:

The top part of the segmentation builder sets the global facts about the segment – including its name, description, how it should be displayed, what objects it applies to, and where it will be used. Name and description are self-explanatory, but each of the other three may require a bit of explanation.

Our people-measurement platform provides a number of different tools where you can see what’s happening or what happened in the location/store. By default, those views use basic shapes to represent core object classes (circles represent customers, squares represent Associates, and triangles represent vehicles. But you can use sprites or any of about fifteen different shapes in this playback. When you build a segmentation, you can choose a different shape (if desired) to represent this group. So, for example, you might represent TSA Pre-Check line goers as a STAR in the visualization. This capability makes it easy to visualize the behaviors of specific segments.

Because object-types are so fundamental (Employees/Customers/Vehicles), we don’t allow a segment to cross object-type boundaries. Sometimes that means you might have to create similar or identical segments for Employees and Customers, but we think it’s worth it from a clarity standpoint. Segments typically don’t apply across object types and we think it’s better to avoid any possible confusion by forcing a segment to pick a specific object type.

Finally, you can apply segments in three different ways. The most common is to have segments show up in the DM1 Analytics Workbench. That means a segment can be applied to any view and any tool including layout, pathing and funnels. You'd check this if you wanted to use the segment for general analysis and in-product reporting.

Checking Big Query means that the segment will be included as a Dimension in data exports and will be available as part of the data feeds. This is really powerful and guarantees that you don’t have to duplicate segmentation logic in an external data warehouse (which necessarily creates two different sources of truth with all the attendant risk).

Finally, you can specify that the Segment should be available in the playback and real-time tools.

Why not just make all of these available by default? Segmentation is fairly expensive and if an analyst is creating a lot of segments for an analysis, it doesn’t make sense to include all of them in data feeds or in real-time views. We see (at least) two big functions for segmentation. When doing an analysis, one-off segments can be incredibly powerful for researching specific questions. But segments, as discussed previously, also are core to a good report set. By giving configurable UI access to both the Workbench (research) and data feeds (typically used for reporting), it’s easier to use segmentation without getting bloat.

Now let’s take a look at the interesting part – what kind of behavior you can bake into a segmentation. A segment can have one or more criteria. There’s no upper bound on the number of criteria. Each criteria can use ANY defined map region (down to single square feet and up to the entire location) and can use any of the core behaviors generated by people measurement.

Maps are custom configured for every location, and in the Builder, you can use any map and any mapping level you’ve defined.

Here, I’ve picked the Section Level of mapping (which is usually the default) and then selected three different sections:

There’s no limit to the number of sections you can select. When you select multiple sections, a visit will qualify if it meets the criteria for any of the selected sections. Once I’ve picked the mapping area I care about, I can choose the behavior that qualifies:

Qualifying behaviors include any touch (the equivalent of a visit), a dwell (meeting a location-wide engagement threshold), spending more or less than X seconds in the area, and starting or finishing in the area. Here, I’ve chosen to qualify anyone who spent more than 30 seconds in this area:

When I add this criteria, it’s moved into the right hand Rules Column. I can use this segment as is, or I can add additional criteria:

Notice that by default, the join condition (in green to the right underneath the criteria I just built) is an AND. But that’s changeable. You can make it an OR a “Followed by” (what we call a Sequential AND):

The Sequential AND is critical in people measurement because so much behavior is about an order of events. Let’s change it, and add another criteria – that the visitor end up at the cash-register and spends at least 45 seconds there:

Note that while I used the same Mapping Level as before, I didn’t have to. You can define Segments that use multiple mapping levels and even multiple maps.

Bottom line, you can build segments that capture behavior at any level of a location. Behavior can represent a visit, spending a certain amount of time, or starting or ending at a certain point. And you can have as many behaviors as you desire chained together to form a segment. Best of all, you can chain segments together with the requirement that they be in a particular order – so you make sure you get customer behavior you’re expecting. And because the DM1 platform lets you apply multiple segments to a view, you can cross one segment with others; allowing you effectively build compound segments simply by applying one or more existing segments.

In other words, if you have segment of apparel shoppers and another segment of home-goods shoppers, applying both segments will give you apparel and home-goods shoppers.

Are there segments you can’t build with the segment builder? Sure. That’s why we have programming languages and ML engines. But if you can describe a segment in logical rules and if it only requires traditional people-measurement metrics, you can almost certainly build it with the Builder. It’s pretty damn powerful.

In my next post, I’ll explain the concept of Segment Sets and how individual segments can (optionally) be combined to form a Set and why that’s an important capability.