Tracking Plans and Data Catalogue

User Problem

Implementation, marketing, and business teams all needed one place to define data in a Data Catalog. Clean data needed to flow into tracking plans which connect directly into Rudderstack.

Building tracking plans into Rudderstack allowed our users to use it as a single source of truth that enforced schemas at ingestion, reducing data catalog clutter and upkeep overhead.

Approach

Product Goals

• Replace 5-6+ workflows that were previously done in spreadsheets, docs, and other tools with a single source of truth for data definitions and tracking plans.
• Win tracking plans Many in the data space were trying and failing to deliver tracking plan solutions.
• Create a foundation Data catalog sets us up with extensible components for later and more visibility for users and potential customers into what Rudderstack does

Strategy & Timeline

• Research: I mapped the data definition and tracking plan creation and implementation workflows on our internal side as well as via interviews with customers. I also talked to coworkers about the tracking plan and implementation process at former companies they'd worked at. The result was an extremely disjointed, disparate process across tons of different tools. Everyone had similar tasks, and similar goals, they were just doing them through various hacks.
• Define: Conducted qualitative research through user interviews and informal testing to uncover natural voice commands and tone preferences
• Design: Designed, prototyped, component-tized, and polished the UI of all features.
• Ship: Continuously refined the look and feel of each workflow and updated based on stakeholder feedback through beta and release

My Role & Contribution

I was the main product designer on this project. I worked most closely with a PM and EM to define in the early stages, and then with my two design colleagues in later stages for critiques, brainstorming, and design-system implementation.

Product Decisions

• Most users were using a google sheet or similar, or avo, to track events, and both solutions required a lot of integration headache with their warehouse
• Rudderstack's advantage was our place in the pipeline due to automation potential
• DevOps engineers are RS core users, and wanted credibility
• Marketers and business users (secondary) wanted visibility
• The solution had to accommodate API/automated import and hand-create, with automated prioritized to users
• Tracking plans and data catalog should be two separate and distinct features

• The core molecules of events, properties, and rules showed up everywhere else throughout the app and would have to be portable and extendable
• We should rely on our API (not a templated google sheet) and work as closely as possible with ENG to prioritize automation
• Newer, highly-flexible and interactive UI's like linear and notion were gaining trendiness, and Tracking Plans presented a good case to move in that direction

Solutions

Data Catalog

• Separated from tracking plans completely - this big architecture decision that would pay off later and in other features
• Events, which are usually represented as code strings, were broken into name, description, and type for easy filtering. Categories are not tied to the codebase and provide another layer of organization for different teams, which was a request for business users
• Tabbed structure provides credibility that the audit API is functional as well as organization by default for often automated or unwieldy data flows

Designing for developers

A common challenge at Rudderstack was using code functionality-as-requirements, in this case, custom rules that can be applied to properties.

I had daily calls with engineering to understand what needed to be reflected in the UI and collaborate on the highly complex data formats and functionality.

My solution was a flyout attached to the property at all times, wherever it manifests in the Rudderstack UI.

Tracking plan Iterations

We did multiple rounds of interviews during the beta with two of our most outspoken customers, one small and one large.

Nesting and bundling were revealed as high-value features

From the beginning, I prioritized audit, API-based, and automatic-populate features in design even though I knew they wouldn’t roll out with MVP, because I knew from early research it would be high value. This was validated in testing.

Results

Insights