Manage data governance at scale with an automated tracking plan

“What got you here won’t get you there.” Coined by Marshall Goldsmith, this phrase is often referenced when discussing growth.

You can't (shouldn’t) run a marathon without running a couple of 5K races first. Shorter races help you get comfortable with waking up early, commit to training, and understand what running gear you prefer. And while you gain valuable insight, the way you train for a 5K isn’t enough to help you train to complete a marathon.

In our Customer Data Maturity book, we outlined the concept of “scaled governance.” (And if you haven’t yet read the book, read it here.) We share how, as your company evolves, your data maturity must also increase. 

In the beginning of the data maturity process, it’s normal for a company to use one tracking plan in both development and production environments. But as you grow your CDP infrastructure, and as change management becomes more crucial, you’ll need distinct environments to experiment with changes to your tracking plans without affecting the live data flowing into your CDP.

Scaling governance requires you to develop a process to propose changes to data governance, so you can test and experiment safely before implementing the changes into the production environment.

Without this process in place, you open the door to mismanaging customer data as your company scales.

In this article, we’ll share how we helped one of our customers, Webflow, build out an automated tracking plan system, giving employees of all technical skill sets the ability to access and act on data.

How we evolved our initial plans

When you’re just starting out on your journey to data maturity, our advice is to keep things simple.

You probably don’t need 5 pairs of running shoes to get you through your first 5K - one quality shoe should suffice.

In your CDP, don’t over complicate your data. Starting off your journey, a small number of events can be edited in a tool like Segment Protocols, which ensures you have a unified schema in place.

This setup is great for non-technical teams who aren’t that familiar with code, and for businesses who need to crawl before they can run.

But as the data needs of the organization grow, it becomes apparent that such a simple approach reaches its limit. For example, when you have multiple teams managing tracking plans.

As you introduce multiple tracking plans to your architecture, and as they become more complex in size, it’s common to include developers and technical teams, not just marketers, to update these tracking plans. Introducing developers requires them to learn the Protocols interface and begin working in multiple apps.

Below is the first iteration of the architecture we built in 2023 based on the feedback. Note that in the example, we’ve created three tracking plans in Segment (Sandbox, Dev, and Prod) which are connected to branches, merges, and releases in a corresponding tracking plan repo:

This automation flow worked well. Though complex, it’s an extremely powerful and effective way to manage an ever-evolving set of tracking plans in your workspace. The architecture also encouraged close collaboration among CDP stakeholders.

However, it still required engineers to learn Protocols UI and slowed them down. We got feedback from many of our customers, including Webflow, asking for a different way of working. One that better met engineers where they are, in tools they are familiar with.

A self-serve solution

So, in 2024, we took our own advice. We kept things simple, and introduced V2.

With this updated tracking plan management system, engineers can use the tools they are most familiar with.

If a company has hundreds of unique events, and each event has 30 properties to it, manually making changes in Protocols could be almost impossible.

With the update, engineers can do all of their work under one hood. And it’s self-serve, so teams can set it up on their own. The merging and branches of GitHub are second nature for engineers.

By allowing teams to choose the tool they are most comfortable with, marketers can still work in Protocols (without having to learn Git) and developers are able to do all of their work under one hood.

You may access the Git repository here.

Conclusion

As your data usage and CDP mature, so should your strategy. When you add stakeholders to your data strategy, it’s important to ensure they feel comfortable with the tools they are using. By incorporating GitHub as an option to use with Twilio Segment, engineers and marketers can both use the tools they prefer.

To learn more about how to improve your data maturity, talk with your Account team or check out the Segment Professional Services offerings.