Braze Catalogs: Complete Guide
Quick Summary:
Catalogs store structured reference data -- most commonly product catalogs -- directly within Braze, queryable by message templates for personalization without the live API dependency Connected Content requires.
What Are Braze Catalogs?
A Catalog is a structured data table stored directly within Braze, most commonly used for product catalog data -- names, prices, images, categories -- that message templates can query to build personalized content. Unlike Connected Content's live API calls, Catalog data lives within Braze itself, queried locally at send time without an external dependency. For reference data that changes on a predictable schedule rather than moment-to-moment, this tradeoff -- slightly less real-time accuracy in exchange for meaningfully greater reliability -- is usually the right one.
Catalogs vs Connected Content
| Consideration | Catalogs | Connected Content |
|---|---|---|
| Data location | Stored within Braze | Fetched live from external API |
| Best for | Reference data updated on a schedule | Genuinely real-time, live data |
| Send-time reliability | No external dependency | Depends on external API availability |
| Update method | File upload or API, on your schedule | Live at every single send |
The right choice depends on how genuinely real-time your data needs to be. A product catalog that updates once daily is a natural fit for Braze Catalogs -- reliable, no external API dependency, updated on a schedule that matches how often the data actually changes. Truly live data (current stock levels changing by the minute, live pricing) is better suited to Connected Content, accepting the tradeoff of external API dependency in exchange for genuine real-time accuracy. Most product catalogs, in practice, fall closer to the Catalogs end of this spectrum than teams initially assume.
Core Capabilities
A well-built Catalog implementation goes beyond just storing data -- it becomes a genuine foundation for personalization across multiple message types and channels.
Structured Storage: Upload product or reference data as structured records, queryable by message templates.
Multi-Item Display: A single message can reference and display multiple Catalog items, supporting personalized recommendation-style content.
User-Combined Personalization: Catalog queries can incorporate user attributes and behavior, letting recommendations reflect an individual's actual browsing or purchase history, not just generic catalog display.
Designing Your Catalog Data Model
Getting Catalog structure right upfront meaningfully affects how usable it is for message personalization later.
Include fields you'll actually query on: Beyond basic display fields (name, price, image), include fields supporting the filtering and matching logic you'll need -- category, tags, or attributes relevant to how you plan to match products to user interests.
Keep identifiers consistent: If your Catalog product IDs need to match IDs used elsewhere (in user behavior tracking, in Connected Content calls to a separate system), consistency here prevents matching failures that are often subtle and hard to debug after the fact.
Plan for catalog growth: A catalog structure that works cleanly for 500 products may need reconsideration at 50,000 -- thinking about query performance and update process at your genuinely expected scale, not just your current scale, avoids a painful later migration.
Common Query Patterns
Category-based recommendations: Showing items from categories a user has previously browsed or purchased from, using their behavior data to filter the Catalog query.
Cross-sell/upsell logic: Referencing related-item relationships stored in the Catalog (like a "frequently bought together" field) to surface complementary product suggestions.
Price-based filtering: Showing items within a price range relevant to a user's typical purchase behavior, rather than generic top-sellers that may not match their actual spending pattern.
Availability-aware display: Combining Catalog data with stock status fields to ensure recommended items shown in a message are genuinely available, not promoting something currently out of stock.
How to Get Started
Prepare your catalog data (product details, or other structured reference data) in a supported format, thinking ahead about which fields you'll genuinely need for personalization.
Upload via CSV or API, depending on your update frequency needs.
Build message templates querying the Catalog for personalized content.
Combine Catalog queries with user attributes for genuinely individualized recommendations.
Set an update schedule matching how frequently your underlying data actually changes.
A Real-World Example
An online retailer wants to show personalized "You Might Also Like" product recommendations in their weekly newsletter, based on each subscriber's browsing history. A Catalog storing their full product data, updated nightly via automated API upload, lets message templates query for relevant products matching each user's recent browsing categories -- delivering genuinely personalized recommendations without a live API call for every single newsletter send, which would be both slower and riskier at that send volume.
As the retailer's catalog grows past several thousand SKUs, they revisit their original field structure and add a few new fields specifically supporting more sophisticated queries -- a "trending" flag updated based on recent sales velocity, and explicit cross-sell relationships between commonly co-purchased items. These additions, planned deliberately rather than added reactively under pressure, let the newsletter's recommendation logic grow more sophisticated over time without requiring a disruptive restructuring of the underlying Catalog itself.
💡 Pro Tip
Choose Catalogs over Connected Content by default for anything that doesn't genuinely need to be real-time -- the reliability benefit of not depending on a live external API call at every single send is significant, and most product/reference data doesn't actually change fast enough to require true real-time accuracy at every message.
Frequently Asked Questions
What is a Braze Catalog?
A Catalog is a structured data table within Braze -- similar in concept to a product catalog or reference dataset -- that message templates can query for personalization, without needing a live external API call the way Connected Content requires.
How is a Catalog different from Connected Content?
A Catalog is data uploaded and stored directly within Braze, queried locally at send time; Connected Content fetches data live from an external API at send time. Catalogs suit reference data that changes on a manageable schedule (like a product list updated daily); Connected Content suits genuinely real-time data.
What\'s a common use case for Catalogs?
Product catalogs for e-commerce personalization are the most common use case -- storing product details (name, price, image, category) that message templates can reference to build personalized product recommendations without needing a live API call per send.
How is Catalog data updated?
Catalog data can be updated via file upload or API, either manually or on an automated schedule, depending on how frequently the underlying reference data actually changes.
Can a single message reference multiple items from a Catalog?
Yes, message templates can query and display multiple Catalog items, useful for showing a set of personalized product recommendations rather than just a single item.
Does using Catalogs require the same live API dependency risk as Connected Content?
No, this is a genuine advantage -- since Catalog data is stored within Braze rather than fetched live, there's no external API call dependency or failure risk at send time, making Catalogs more reliable for data that doesn't need to be truly real-time.
Can Catalog data be combined with user-specific personalization?
Yes, Catalog queries can be combined with user attributes and behavior data, letting you build genuinely personalized recommendations (like showing catalog items related to a user's browsing history) rather than generic catalog display.
What data formats does Catalog support for upload?
CSV file upload is a common method, alongside API-based upload for more automated, frequent updates -- the right method depends on how often your catalog data actually changes.
Is there a size limit to how much data a Catalog can hold?
Catalogs are built to handle meaningful product catalog sizes, though very large catalogs should be planned with awareness of any specific size limits relevant to your Braze plan.
Can Catalogs be used for non-product reference data, like store locations or content library items?
Yes, while product catalogs are the most common use case, Catalogs work for any structured reference dataset that message templates need to query -- store locations, content library items, or other reference data.
How often should Catalog data realistically be refreshed?
This depends entirely on how frequently the underlying data actually changes -- a product catalog with daily pricing changes needs more frequent updates than a relatively static store locations list, and the update schedule should match genuine business need rather than an arbitrary default.
Can Catalog updates be automated via a scheduled job, or must they always be manual?
Yes, API-based updates are well suited to automation, letting a scheduled job push fresh catalog data on a recurring basis without requiring someone to manually upload a file each time.
Can different message templates use different subsets of the same Catalog?
Yes, query logic within a template can filter to a relevant subset (like a specific category or price range) of the broader Catalog, letting one underlying dataset serve many different, more targeted use cases across different templates.
Can Catalog data be used for segmentation, not just message content?
Catalogs are primarily built for message-time content queries rather than segmentation criteria directly -- segmentation typically still relies on user attributes and behavior, with Catalog data shaping what content is shown once a segment is already defined.
Related Articles