Facebook Web Analytics Setup

Summary

Using analytics as part of your Facebook marketing strategy is considered a best practice, yet adding analytics to your website requires deep technical knowledge and access to the website code-base.

This project covers how my team and I designed and built an entirely new way for Facebook business users to set up web analytics – without having to write a line of code.

Background

The two most common reasons for a business user to use Facebook’s web analytics tools is to:

• Measure the effectiveness of money spent. If I spend $100 worth of advertising money, I want to know how many of those ads actually resulted in a purchase and for how much money.
• Be able to advertise to customers based on website activity patterns. For example: Re-engaging with people who added something to their cart, or finding people likely to sign up for a service.

Traditionally the only way to set up this type of analytics, is to put a snippet of code on your website, or integrate via any of Facebook’s partner platforms (Shopify, Wordpress etc). But if you are in marketing and don’t have access to the website code, or aren’t on any of the partner platforms, you won’t easily be able to do the things above.

My Role

Designers at Facebook generally work as “full-stack” product designers, meaning we are responsible for everything from gathering requirements and understanding users and use cases, to building prototypes and defining the final visual- and interaction design specs.

I was the lead designer on this project, working together with a content strategist, a user researcher and a team of cross functional peers including PM, engineering and data science.

Project Goals

Design and ship an experience that allows a marketer with no technical expertise to set up and manage web analytics on their site.

We set some UX-specific ship criteria that included:

• Completion Rate – At least 50% of clients that enter the flow complete setup of at least one event.
• Completion Time – At least 50% of customers successfully setting up an event within 1 minute.
• Sentiment – Average of at least 3 of 5 stars from the in-product review survey
• UX Quality Score – 2.5 of 5 score from an internal Product Quality Audit (where product designers across the Facebook Business org evaluate the feature and rate it on a number of axes).

Design & Prototyping

The basic idea of the product is that you can input your website, and then get a Facebook hosted UI overlaid on top that allows you to tag buttons or URLs with “events” that you want to trigger every time a person clicks the button or visits the URL.

This was challenging from a design perspective since you need to be able to differentiate the Facebook-hosted UI from your website, without the website being covered up or distorted by the overlay. After a few different iterations, we solved this with a compact movable module as the main control, and other pieces of UI would show up as needed during different parts of the workflow.

Additional complexity was introduced when, in addition to tagging the button with what type of action it represents, we also wanted to provide the ability to add price information in order to support the use case of measuring ROI. We managed to solve this by getting the user to point at the price on the page as part of the setup flow.

Development & Activities

The design and development for this product was quite fast: we went from nothing to a closed beta in six months, and to a full release in nine.

During that time I:

• Developed and iterated on several prototypes that were tested by our user researcher
• Worked closely with engineering to take design specs and ensure they were translated into the built product
• Defined UX ship criteria together with research and data science
• Ran monthly team retros to improve our team efficiency and morale

Pushing Back

By the time we were about to launch the beta, our UX metrics weren’t where we’d expected and I had to convince the team to push back the release by a month. It was a hard but important exercise in keeping the team accountable for hitting the goals we had set around usability. After about a month we were able to make enough changes that we were meeting or exceeding all goals.

Results

• Completion Rate | Goal: 50% - Before the beta, we had a number of leaks in our funnel, preventing customers from successfully launching the tool for various reasons. But since addressing those, we eventually saw completion rate stay consistently above 60%.
• Completion Time | Goal: 50% of customers setting up within 1 minute - More than 70% of customers set up an event within 1 minute of launching the tool.
• Sentiment | Goal: Average of at least 3 out of 5 - We had an average of 4.5 stars.
• UX Quality Score | Goal: 2.5 of 5 - We received a 3.4 score, which is higher than most business products at Facebook.

In addition to exceeding all of our goals, we also received a highly positive reception through the feedback tool and some industry experts.

Retrospective

As with all projects there are things I’d done differently were I to do it again, or if I’d had more time to iterate before handing the project off.

• I would have wanted to experiment more with animations between states, to improve the usability and reduce the perceived complexity. I think there was an issue with having elements show up and disappear instantly on the page. Just relying on color and visual hierarchy to pull people’s attention to the right place was hard when you can’t predict the color scheme of the website in the background. Animated transitions could help guide users to the right things at the right time, by using motion rather than color.
• The other real struggle that we had as a team was the definition of our customer; were we building for people who were quite sophisticated in marketing, but wanted faster code-free ways of adding powerful parameters to their data (such as price per purchase)? Or were we building for folks who are beginner marketers that have never used analytics-based marketing before? These two groups require pretty different tools, so not being clear on this landed us on a middle-path where we didn’t build for total beginners, but we also didn’t build for power-users. Going forward, I would make sure that the team is aligned on who we’re building for by putting together a user profile with characteristics that the team can refer to when making trade-offs.