OVERVIEW

Building a scalable data ingestion system at Braze.

Customers viewed data ingestion as a "black box," blindly uploading CSVs without guardrails. This resulted in malformed data, massive deduplication efforts, and over 80 complex engineering support cases annually.

Impact metrics

Pitched and designed a scalable, no-code Data Mapper UI with background pre-import validation. The pattern was so successful it was adopted across multiple teams for Cloud Data Ingestion.

751,000+

errors caught before data imported into Braze

Role

Lead designer across data ingestion and CDI team.

Process

Identifying the Strategic Gap

CSV import is often the very first method customers use to get data into Braze. It is a table-stakes feature. To kick off the project, we synthesized internal research and interviewed customers to understand their ingestion workflows. A major theme emerged: customers felt data ingestion in Braze was a "black box." When data synced correctly, confidence was high. But when issues arose, they were completely unable to troubleshoot.

For manual CSV uploads, which customers rely on heavily for one-off lists like in-store campaigns and onboarding, the lack of visibility was especially painful. Customers resorted to tedious workarounds, like creating test segments just to verify whether their data actually made it into the platform. Without guardrails, marketers were accidentally creating massive data cleanup projects.

"They did a manual CSV upload, and because there were no guardrails within Braze... instead of updating existing users, they added a bunch of duplicate users." — Customer Success Manager, Braze

This lack of transparency and defensive guardrails was causing 80+ support cases annually. The hardest required hours of engineering time to untangle, and some escalated to deleting malformed data outright. I realized we didn't just need a UI update; we needed defensive infrastructure built into the flow itself. I successfully pitched the CSV Data Mapper concept and secured its place on the Ingestion Foundations roadmap.

Before: the original CSV upload modal. It previewed the file and detected attributes, but offered no column mapping, no validation, and no flag when a header would silently create a new attribute. The green "Upload completed" check confirmed the file had parsed, not that the data was safe to import.

Designing for Scale & Ambiguity

As the lead designer for two different ingestion teams, I recognized early on that the CSV mapping problem wasn't unique to CSVs. The logic of mapping incoming data to Braze applied just as much to Cloud Data Ingestion (CDI) and e-commerce integrations.

Ownership of the feature bounced between teams for months. Rather than waiting for perfect alignment or final PRDs, I used rapid design exploration to force product decisions. By bringing 3-4 solution proposals to every inflection point, I kept the work moving. To pressure-test the complex mapping logic before committing to high-fidelity Figma components, I utilized Gemini and Cursor to build working prototypes, allowing the engineering team to react to a tangible system rather than abstract concepts.

The Solution: A Modular Mapping Interface

The old experience packed preview, naming, targeting, and the final commit into one modal, with no way to see or control how a column became a Braze attribute. I unpacked it into a guided sequence built on a single rule: every consequential decision is visible before anything commits. Two of those decisions did most of the work.

The flow opens on a plain file preview, the cheapest checkpoint for catching a malformed file before anyone invests effort in mapping.

File preview: the first ten rows, noting that Braze validates the full file at import.

Make silent failures visible. The most expensive failure in the old flow was invisible. A mistyped header quietly created a permanent custom attribute, and nobody noticed until segments broke weeks later. My call was to make every match the system inferred explicit and readable at a glance, so a mistake surfaces in the row before import rather than in a cleanup project after it. The same principle governs identity: mapping an identifier is required, because unresolved identity is what turns a routine upload into thousands of duplicate users.

Column mapping. The screenshot callouts carry the mechanics: a "New attribute" flag on a header that matches nothing, a "Data type mismatch" warning on an incompatible type, and the required identifier field at the top of the step.

Between mapping and commit, the settings step states what the import will do and offers a deeper, opt-in check for teams who want one.

Import settings: create-and-update behavior, targeting preferences, and an opt-in full-file validation that runs a row-level pass before import.

Gate the one thing you can't cleanly undo. Almost every choice in the flow is reversible. Creating a new attribute in the customer's workspace is the exception, and cleaning one up later is the kind of project this feature exists to prevent. So I pulled that single action out of the noise and gave it its own confirmation at the end, stating exactly what will be created and under what condition. Nobody adds a field to their Braze instance without seeing it named first.

Summary. Callout on the "Changes" panel: new attribute creation isolated from everything benign and named in plain language, so the one consequential change is seen and confirmed before Start Import.