Conversion goal updates

The headlines from my partner's first iterations were technical, lacked action, and were filled with jargon. I wanted to understand what we were actually asking users to do and how they thought about it.

The main headline from PM mocks captured the user's directive: "Update your goals from Universal Analytics conversions to Google Analytics 4 conversions." Technically correct, but way too complicated.

After digging through past research and talking with our research team, I reframed this as a "switch" to new analytics. Research backed this up. The language change aligned better with how advertisers think and reduced hesitation in testing.

Working with PM and design, I found more opportunities to clean things up. I cut redundant explanations and focused on what advertisers needed to know.

As we neared launch, I worked with help content teams to spot remaining knowledge gaps. We added tool tips and consolidated help resources to give people answers without overwhelming them.

From manual guide to automated recommendation

The biggest headache was the individual conversion updates. We showed users a table with all their conversions and dropdown menus to switch between "Primary" and "Secondary" settings. It felt comprehensive, but was actually a mess.

My first iteration replaced generic dropdowns with clearer actions like "Switch" and "Change to primary." I wanted to carry the language we used elsewhere and connect directly to the user's mental model.

After putting this iteration in front of users, we heard something different. In roundtables, advertisers said this approach felt overwhelming and created decision paralysis. More options didn't mean more confidence.

Taking in this feedback, I explored how to build confidence while reducing cognitive load. To do some of the heavy lifting, I explored automation. The change was straightforward: old conversions become secondary, new ones become primary.

I mocked up a two-column layout displaying current settings alongside recommended changes, giving users clear visibility into exactly what would change before committing.

After validating this with engineering, I spotted another opportunity. While working on performance warnings, I realized we were asking people to approve changes without showing the potential impact upfront.

I made a mockup of how to share performance fluctuations on the review and update page. I shared updates with my design partner, and we presented the proposal to our product and engineering partners.

When we talked to engineering about moving these warnings earlier in the flow, they pointed out something helpful: since we were now generating recommendations automatically, we could also calculate and show the performance impact before users made any decisions.

Why were we making people figure this out manually when we could automate it?

We flipped the entire approach. Instead of “here’s a complex table, and you need to make changes,” it became “here’s our recommendations–does this look right?”

The result was a dramatic reduction in cognitive load while maintaining full transparency—users could see exactly what would change and why, then approve updates with confidence in a fraction of the time.