Braze naming conventions — the practitioner's guide

The standard reason is the convention itself. Twelve dimensions, dropdown-heavy, 90-character names nobody can type or remember. A lifecycle manager under a deadline defaults to free-text because the structured way is slower — and six months later, nobody can find the asset that paused the churn bleed last Q3.

The conventions that work have three properties. They fit on a sticky note. They compress to a readable 40–60 characters. And their dimensions map 1:1 to the filters you actually use in Braze reports. If a dimension exists in the convention but doesn't exist as a filter in your reports, drop it.

A second failure mode: documentation-based enforcement. A Notion page explaining the rules never moves the needle on compliance. The only reliable enforcement is workflow-based — a naming tool that's open next to the Braze campaign builder, keyboard-accessible, one-click-to-copy.

Almost every useful Braze filter maps to one of four dimensions:

1. Asset Type— campaign, canvas, segment, template, content block. This anchors the name to what the object is in Braze. Without it, you're searching a list where campaigns and canvases blur together.

2. Channel — email, push, SMS, in-app, content card, webhook. Most lifecycle programs split by channel in reports, and the channel is what most team members filter on first.

3. Program — onboarding, activation, retention, dunning, win-back, feature adoption, upsell, re-engagement, transactional, promotional. Note these are lifecycle stages, not campaign names. Program = family; the specific campaign name is a suffix.

4. Audience — all, free, paid, trial, churned, at-risk, new, dormant, VIP. Segment targeting is a first-class concept in every reporting query — pulling it into the name means filtering by audience never requires an ad-hoc segment join.

A practical canonical form: [asset]_[channel]_[program]_[audience]. For example: campaign_email_onboarding_newuser. Short enough to scan, structured enough to filter on, consistent enough to enforce at scale. The audience dimension itself comes from your segmentation model — the segmentation guide covers how to derive those audience names consistently.

The Orbit Namer exposes six dimensions beyond the core four: Country, Language, Version, Step, Variant, and Deployment Date. These are not always wrong to include — the failure mode is filling all ten always, not selectively.

Country and Language matter when you run regional programs with separate sends per market. Include them in the name when the program actually ships in parallel per region; leave them out when there's one global send. Version matters when you're running a v2 redesign alongside the existing v1 and need both measurable. Step matters for sequenced journeys (day-1, day-3, day-7) where each send is independently tracked.

Variant matters for structured A/B tests where the variant letter (A/B/C) is the analysis key. Deployment Date is the tricky one — for recurring programs, dates belong in tags, not the name; for one-off promotional sends (black-friday-2025, summer-sale-2026), the date is part of the identity and belongs in the name.

The name answers: what IS this asset? Tags answer: how do you want to group it? Identity in the name; grouping in tags. This separation is where most teams get confused — and where the bulk of naming-convention failure actually happens.

Date-sensitive promotions (black-friday-2025), experiment variants (test-hero-v2), team ownership (growth-team, lifecycle-team), and campaign cohorts (q1-launch-batch) all belong in tags, not names. You filter by tags in the Braze UI; you match on names in reports. Tags are metadata that a campaign CAN have; the name is what the campaign IS.

A concrete test: if you renamed the asset, would the report still make sense? If yes (because the filterable value is stable metadata), it's a name. If no (because it changes across instances of the program), it's a tag. The Orbit Namer skill automatically surfaces recommended tags for every asset it names, so the split is done for you.

Documentation-based enforcement fails. Slack reminders fail. Quarterly reviews of naming compliance fail (the offenders are long gone by the time you audit). The only approach that works at scale is making the convention faster to follow than not.

This usually means: a naming tool open next to the Braze tab, populated with the dropdowns your team filled in on day one, producing the canonical name + recommended tags in one click. The Orbit Namer is built for exactly this — six seconds from intent to copied name.

For larger programs, add a gate: a pre-launch QA checklist that verifies the asset name matches the convention regex before the campaign is approved. Braze doesn't provide this natively, but the Braze Instance Audit skill scans your whole workspace for off-convention assets and produces a prioritised cleanup list on demand.

If you're adopting a convention on an existing messy workspace, don't rename everything at once. Enforce on new assets first. Audit once a quarter. Bulk-rename the top ~50 most-reporting-critical assets after you have at least a quarter of clean new-asset data — that's when the baseline for 'good' is clear.