Chris McGinnis
Ever tried to run an analysis based on a “quick ask” — only to realize it’s way more complicated than it looks?
Business users love to slice their data every which way: “Can we look at sign-ups by month, then cohort by product type…and maybe also by first purchase channel?”
On the surface, it sounds easy. In reality, those requests can send data teams into SQL gymnastics: complex joins, CTEs, and other workarounds to get the data in just the right format for it to work.
That's because many of these "quick" analytical asks often require calculations at a different level of granularity, the level of data collected and stored in your database, than readily available for your analysis. Calculating and switching between those levels can actually be surprisingly painful, depending on your tool.
This is where Omni’s LOD (level of detail) fields can really help — making some of these “quick asks” actually quick. Inspired by Tableau’s LOD expressions, Omni’s LOD fields let you define exactly how a metric should be aggregated, no matter what other dimensions are in the query. This makes cohorts, retention curves, and other tricky calculations simple to stand up.
You can build LOD fields with just a few clicks in the UI — no complex syntax required. Then, if you’d like, you can promote it into your Omni shared model to make it reusable for future analyses.
Omni’s LOD Fields #
Part of what makes LOD fields so powerful is the ability to choose the type of aggregation. There are three types of LOD fields available in Omni: Fixed, Include, or Exclude. To understand the differences between each type, check out these examples using an eCommerce dataset below👇
Fixed LOD Fields #
Example: Calculating total customer orders
“Fixed” LOD fields group aggregations at your dimension of choice, but remain locked at a specific level of detail — meaning they ignore other dimensions that you have selected in your query.
If you want to calculate a customer’s total lifetime orders and keep that number consistent, no matter what dimensions are in the query, use a Fixed LOD field. For example, if a customer has 14 total orders, adding a dimension like Department won’t change that number. It stays locked — or fixed — to the customer level.
Include LOD Fields #
Example: Total customer orders that change with dimension selections
“Include” LOD fields perform calculations that include the other dimensions that you currently have selected in your query. I like to think of them as reflective — unlike fixed LOD fields, they reflect your existing dimension choices.
You may want a metric like Total Customer Orders to respond to the dimensions that are selected in your query. By using an Include LOD field, the aggregation will adjust to reflect whatever dimensions you select — so your totals are now broken out by Department, rather than repeating the total across rows.
Exclude LOD Fields #
Example: Calculating category totals while still at the product level
“Exclude” LOD fields also reflect your existing dimension choices, just like “Include” fields do. However, you can choose to ignore, or exclude, a value if it’s too granular for what you’re trying to accomplish. You can think of these fields as selective — they hide specific fields to keep your calculations relevant.
When adding the Brand dimension to our query, our Total Customer Orders field could suddenly become misleading — it would count orders where that specific brand was purchased. But what if a customer bought multiple brands in the same order?
By using an Exclude LOD field and excluding Brand, the totals will still respond to other dimensions in the view, but they’ll consistently ignore Brand. This gives us cleaner, more accurate customer-level totals — even in a highly detailed view.
Examples of using LOD fields in Omni #
Now that we know the difference between field types, here are a few examples of how using LOD fields can give you precise control over how your data is grouped and calculated in Omni.
Example: Calculating Lifetime Customer Orders
For retail companies, it’s common to want to know how often your customers order. Typically this requires creating a fact table per user with SQL, then joining that back to your orders table. With LOD fields, we can create a metric that counts lifetime orders, then easily turn that into a histogram – all in the UI. For this example, I used a Fixed LOD field because I want the orders to be fixed, or locked, to our customer ID.
Example: Creating a cohort analysis
One common analytical technique is cohorting — grouping users based on shared characteristics, like the year they first made a purchase, so you can track how behavior evolves over time. Without an LOD field, our logic could break if we added additional dimensions like Product Category to our query.
A Fixed LOD field ensures users stay grouped by the year of their first order, even if we add additional dimensions to our query.
Example: Creating a heatmap
Heatmaps are a quick and powerful way to visually compare values across groups or categories — perfect for spotting trends or outliers at a glance.
Without an LOD field, you can't build a heatmap to show total US sales alongside total state sales because your two total columns will end up being identical, since "State" has now been added as a dimension.
To create our heatmap, we’re going to use a Fixed LOD field again, but this time without locking it to a specific dimension. That means the calculation respects our filters, but stays steady as we drill deeper. That way, if we drill into a specific state and look at city-level performance, the LOD field will adjust to show total sales for that state — giving us a clean way to compare each city against the state it's in.
Quick asks shouldn't turn into time sinks. With Omni’s LOD fields, business users can create flexible aggregations on their own — directly in the UI — freeing up your data teams and speeding up answers.
Want more inspiration? Check out this guide on our Community site: Using level of detail functions for cohorting analysis 💡