You’ve got thousands of SKUs, hundreds of store locations, or a growing list of offers, and none of it lives inside your CRM. Your platform knows plenty about your users: their purchase history, their app sessions, their email opens. But the products they might want? The store nearest to them? 

That data sits somewhere else. And every time a campaign needs it, someone’s stitching together a workaround.

Sound familiar?/

That’s exactly the gap Braze Catalogs exist to close. A catalog is a structured, non-user dataset that lives inside Braze. Most teams stumble into it through a single use case, usually product recommendations or a store locator, without ever understanding the structure underneath.

In this post, we’re breaking down how catalogs actually work. Then we’ll walk through the newest capability: geolocation filtering, which shipped in Braze’s May 2026 release. We’ll use a retail “nearby inventory” example to show exactly how it plays out. 

Let’s cut to the chase. 

What is a Braze Catalog, really?

A catalog is a lightweight database that lives inside Braze, and you access it through Liquid, Braze’s templating language. Instead of storing information about your users, it stores information about the things your users care about: products, store locations, offers, or content.

Here’s how it’s structured. Each catalog item is a row, and every row has a unique ID. Each field is a column, an attribute of that item, like name, price, category, image URL, store hours, or availability. Think of it as a spreadsheet your Liquid tags can reach into.

Getting data in works one of two ways. You can upload a CSV for a manual, one-off use case. Or you can use the Catalogs API for production-grade data that syncs continuously from a product database, CMS, or data warehouse. Manual uploads work fine for testing and early pilots. They don’t scale.

And catalogs do scale. They support up to 1,000 fields per item and can hold millions of rows, with storage capped at 500 MB on the free tier and expandable from 5 GB to 50 GB on Catalogs Pro.

Here’s why this matters for a CMO. A catalog isn’t a one-off campaign hack. It’s part of your data activation architecture. It separates message logic from item data, so one template can serve thousands of variations without your team rebuilding it every time inventory changes.

Catalog data types and why they matter 

Catalogs support several data types: string, number, boolean, time, object (nested JSON), and array. Each one maps a little differently between CSV upload and the API, so it’s worth knowing which fits which field before you build.

One data type deserves its own mention: geo. A geo field stores a coordinate pair, formatted as longitude and latitude. It’s a small addition on paper. It’s also the field type that makes geolocation filtering possible, which we’ll get into shortly.

One practical note if you’re setting up boolean fields: capitalization rules for True/False values in CSV uploads have shifted across Braze releases, so confirm current dashboard behavior before you build your import file. It’s a small thing. It’s also exactly the kind of detail that breaks an upload at 4 PM on a Friday.

Start from your use case, and design the catalog around it. Don’t dump every column you have access to just because you can. Unused or poorly typed fields don’t just clutter your dashboard. They make your Liquid logic unreadable once your team starts building selections on top of it. 

Selections: Turning catalog data into targeted content

A catalog on its own is just data. A selection is what turns that data into something you can actually send.

A selection is a filtered, sorted, limited subset of catalog items, personalized for each user, instead of pulling your entire catalog into every message. Here’s how it works. You can apply up to 10 filters in the dashboard, or up to 4 through the API. You choose a sort field and order. And you cap the results at up to 50 items per selection.

You don’t need to hand-write any of this. Braze auto-generates the Liquid for a selection right from the message composer’s personalization window, so your Liquid doesn’t have to live in your head.

Here’s where it gets interesting. Selections can use Liquid to personalize filters per user. You could reference a user’s most recent location, for example. That single idea sets up everything in the next section.

The May 2026 update: Geolocation filtering explained

As of the May 28, 2026 release, catalogs support distance-based filtering through the new geolocation field type and new Catalog Selection operators.

Before this, teams approximated location targeting with city or region codes. It worked, sort of. But city-level targeting can’t tell you which of your 40 stores in a metro area is actually closest to someone. It can’t express true proximity or power “nearest to me” logic. It’s a blunt instrument for a precise question.

Here’s how the new approach works. A geolocation filter surfaces catalog items based on proximity to a center point. Once that filter is applied, Braze automatically sorts results nearest-first. You don’t have to build that sorting logic yourself.

The center point can be static or dynamic. You can set it per user with Liquid, using an attribute like a user’s most recent location, so “nearby” gets calculated relative to each individual person instead of one fixed radius for everyone.

Braze points to a few scenarios this makes possible: showing each user their nearest restaurant or store, filtering open real estate listings within 50 km, or targeting stores near a specific event.

One caveat worth flagging to your team. Location data quality depends entirely on how you captured it. A most recent location pulled from device GPS or Wi-Fi signals behaves differently than a manually set attribute. Your results are only as good as the location input feeding them. 

Use case walkthrough: The ‘nearby inventory’ store locator

Let’s make this concrete.

Picture a retail brand with 200 physical stores. They want to tell each app user which nearby store has their size in stock right now, instead of pointing everyone to a generic “find a store” page.

Here’s how the catalog gets built. A store’s catalog holds fields for store_id, store_name, address, a geo field for store_location, a stock status per SKU (or a linked inventory reference), and store hours.

From there, the selection does the work. Filter by geolocation proximity to a user’s most recent location. Combine that with an inventory-availability filter. Sort nearest-first. Limit results to the top 3 to 5 stores.

The resulting message practically writes itself: “Your size is in stock 1.2 km away at [Store Name].” That auto-sorted, nearest-first selection powers the entire line.

Compare that to the old approach: static store locator pages, city-level segmentation, manual list maintenance every time inventory shifts. This version is dynamic, per-user, and updates automatically as inventory or location data changes. Nobody’s manually refreshing a list. 

Where catalogs fit in the bigger picture: Agent Console and eCommerce

Catalogs aren’t just a personalization feature anymore. They’re becoming the data layer AI runs on top of.

Inside Braze’s Agent Console, Catalog Agents can enrich catalog data directly. Think auto-translating product descriptions for a new market, or standardizing a messy inventory feed that came in from three different systems. Canvas Step Agents can reference a catalog as grounded context too, so AI-generated copy references your real store names and product titles instead of guessing at something close enough.

On the eCommerce side, the classic use cases still hold: back-in-stock alerts, price-drop triggers, seasonal collections. Geolocation just adds a location layer on top of what you’re already doing. “Back in stock at your nearest store” hits differently than a generic restock email.

Here’s the throughline. Catalogs are the structured data layer that both classic personalization and newer AI agent workflows depend on. 

Wrapping up

Catalogs turn your non-user data into a structured, queryable layer. Selections turn that data into targeted content. And geolocation filtering adds true proximity logic on top of both.

As Agent Console matures, well-structured catalogs are going to double as the grounded data source your AI agents rely on. That makes catalog hygiene a bigger priority than it’s ever been, not a housekeeping task for later.

If you’re not sure whether your Braze catalog is built to scale, or you’re curious what geolocation filtering could do for your program, our team at Mavlers is always happy to take a closer look. Let’s talk.