Before digging into your or your client’s AdWords account, you might need to do some tidying up first. Image via Shutterstock.
When PPC agency ParaCore started working with a niche inspection company, they realized pretty quickly that before they could start optimizing this client’s AdWords account, they needed to do some necessary housekeeping.
The client — who shall remain nameless due to their highly competitive industry — was already pairing landing pages with their PPC ads. However, because they had so many market segments to target, they were juggling 60 different landing pages. This approach was certainly scrappy, but it was also incredibly challenging to maintain and optimize.
The client also lacked insight into both how many phone call leads they got, and exactly where these leads were coming from. Without this data they were unable to attribute leads to the appropriate campaign, making optimization — let alone determining the ROI of their ad spend — virtually impossible.
In efforts to better manage this client’s account, ParaCore used Unbounce to reduce the number of landing pages from 60 to just four (while maintaining hyper segmentation), set up CallRail for improved phone call conversion tracking, and implemented a negative keyword approach in AdWords that ultimately saved the client $30k in ad spend and lowered the cost per lead over 40%. Needless to say, their client was thrilled.
Here’s how they did it.
Simplify market segmentation with landing pages
ParaCore’s client was already deep in the PPC game. They were spending $10k monthly on Bing and AdWords ads, and they had the wherewithal to pair their ads with targeted landing pages. But in order to target each individual market segment, they were using 60 landing pages (15 markets x 4 services).
Despite the benefit of better segmentation, juggling this many landing pages has its challenges, as ParaCore founder Adam Arkfeld can attest to:
Updating one thing on all landing pages takes forever. If you want to change content, it’s 60 changes. If you want to change something major like design, that’s a huge effort. It’s also just more difficult to track analytics and keep track of all the pages.
So ParaCore’s first task was to take those 60 pages and whittle them down to just a few manageable (but still high-converting) pages.
Using Dynamic Text Replacement on their Unbounce pages, ParaCore was able to reduce the amount of landing pages to maintain. Image via ParaCore.
To ensure they maintained the same hyper-relevance for each market segment, they implemented Dynamic Text Replacement (DTR) on the landing pages, an Unbounce feature which allows you to automatically swap out keywords on your landing page based on someone’s search intent and the corresponding ad clicked.
That is — if someone searches “piano lessons in Arizona” that’s exactly what your corresponding landing page’s headline can read to match their query.
In this example of a landing page for a music school, the instrument type is swapped out depending on which ad is clicked.
CallRail works similar to DTR, by dynamically populating a unique phone number depending on the original referrer. So when a visitor clicks on an ad and then calls the number on the landing page, that lead is attributed to the appropriate click-through ad.
Attributing your phone call leads to the original ad has never been easier. Image via CallRail.
Don’t know where all your phone call leads are coming from? CallRail integrates with Unbounce landing pages, so you can track which ads and landing pages result in calls. Find out more here.
Not only that, but CallRail allows you to create regional phone numbers, which was especially important to their client. Adam said it was key that their client’s prospects saw “a 480 number for Phoenix instead of an 888 number.”
AdWords Call Conversion Tracking, on the other hand, allowed ParaCore to see which keywords were converting so they could kill the underperforming keywords or ad sets.
Within four months, this is what team ParaCore had found:
55% of leads came from calls made after seeing the new Unbounce landing pages, 24% came from landing page forms and roughly 20% came directly from ads.
Once they had the data they needed, it was time to actually dig into AdWords.
Optimize ad groups with negative keywords
Now that ParaCore had all the necessary data to determine which keywords were and weren’t working, they could start optimizing in AdWords.
ParaCore’s client had already done a significant amount of keyword research resulting in a robust collection of targeted keywords; however, a review of their analytics revealed not all of them were performing top-notch.
ParaCore added negative keywords to the client’s campaigns, followed by daily negative cleansing (which sounds like something you’d do with a smudge stick and quartz crystal, but is actually just excluding search terms that aren’t relevant).
After the initial cleanse, ParaCore scaled back to periodic reviews to ensure keyword relevancy. They kept an eye on conversion data over the first two months and turned off keywords that were, as Adam put it, “eating up the ad budget without producing good returns.”
Clever Account Management Pays Off
By adding negative keywords to their client’s AdWords account and turning off the keywords that weren’t bringing in results, team ParaCore managed to save their client $30,000 in annual ad spend and reduce their cost per lead by 40.7% in the first three months.
Not only that, with these all of the changes in place, ParaCore’s client was set up to scale. Now when the client wants to add additional markets, the agency doesn’t even have to create a new landing page, they simply “add dynamic text insertion with new phone numbers and local text.”
This kind of progress wouldn’t have been possible had they not first simplified their client’s landing page collection and clarified their metrics. Only then could they turn their efforts toward their client’s AdWords account.
According to Adam, the data collected during that initial exploration “continues to guide our efforts as we optimize the company’s PPC campaigns to bring in the highest quality leads at the lowest cost.”
And ParaCore’s client could not have been more pleased. Their Google+ review says it all:
These guys have been awesome for us so far! We love the reporting metrics they use as it really identifies the important information and tells us a lot about our PPC campaigns. We have also been very happy with how thorough they have been in implementing the crossover from our old PPC manager… All in all, we are very happy to have made the switch and wish we would have pulled the trigger sooner.
One of our clients this past year is an e-commerce company. They sell a wide variety of beauty products and use a subscription model. Subscribers are part of an exclusive club and receive a box of beauty products each month.
Most of these subscribers come in from a Facebook ad.
We were focused on this client’s 4-step acquisition funnel. After targeting the first step, we wanted to apply what we had learned to the second step of the funnel.
Based on previous tests, we knew that subscribers responded to social proof and were sensitive to both community messaging and the quality of our client’s products.
We ran the following test on desktop and on mobile, segmenting the results by device.
Press play: Round I
The control page for this experiment highlighted the customizable nature of the monthly beauty box.
In one variation, we replaced this information with a video of a subscriber talking about how much she loves being a member of this community. With this video, we hoped to draw out visitors’ appreciation for social proof.
We had actually tested social proof before, but it didn’t work. We used a statement that said ‘Join thousands of other subscribers’ but it sounded so fake. The video added genuineness to the messaging.
In another variation, we replaced the control content with a video of the company’s CEO — an already-prominent figure on the their social media pages. In this video, she discussed the community, the company’s core values and the quality of their products.
Both variations saw significant lift in completed orders on mobile: 12.9% and 10.0% respectively.
Press play: Rounds II & III
As is our habit, we decided to build on this test. We adopted the winning social proof variation as our control and created two more variations:
In the first variation, we added the video of the CEO beneath the subscriber testimonial
In the second, we shortened the subscriber testimonial from 2 minutes to 1 minute
The variation that included both videos increased conversions by 3.5% on desktop and 6.5% on mobile. The variation with the shorter video actually decreased conversions among desktop users but lifted conversions on mobile by a significant 12.2%.
While mobile users seem to enjoy the video content, their possible limited attention spans could explain the dramatic lift caused by a shorter, more concise video.
Desktop users, on the other hand, may have more time and prefer more information to become familiar with the company’s value proposition.
We kept going.
Our next move was to combine these two variations into one. It featured the shorter video testimonial and the video of the CEO. We saw a 15.5% lift for desktop users and a 12.2% lift for mobile users.
In this series of tests, we found that video can be a powerful social proof tool across all devices.
The client in this case was fearful that mobile users might be too impatient to watch a video. They worried that visitors may not want to waste data, but our results showed these fears to be unfounded.
Our continued testing led us to discover a winning video combination for our client’s users. It also revealed insights about video length on mobile versus on desktop.
How does one design and develop for the responsive web? A lot of methodologies out there try to tackle this problem, but all of them rely on the same classic website development process. It boils down to the following: design and then develop. Let’s go nuts and flip this outdated methodology on its head.
Before we start flipping things around, let’s take a quick stroll down memory lane, just so we know where we’ve come from and where we are now.
It’s 1989, and Tim Berners-Lee, the man with the plan, conjures up HTML while working at CERN. It’s a language to link content across documents.
After four years, the Web went public, in 1993. It took a couple of years for someone to create the first columned layout using a table — at which point, something changed. I imagine this as being a turning point in web development. It was the moment when design could be moved to the front of the development process. You could now design a web page, slice it up and present it on the Web.
Luckily, we regained our sanity and ditched tables for layout. We proudly moved to semantic HTML, but we held on to our design-first approach. Let’s take a closer look at semantic HTML.
Semantic HTML is about picking the right HTML element to describe a given piece of information, rather than using HTML to define the way the information should look. If you’re a front-end developer, you’ve probably been doing this for the past couple of years. Great, keep it up!
In my opinion, writing semantic HTML is one of the key aspects of being a good front-end developer. It’s something I value greatly.
Because of that, it’s been a topic I’ve discussed a lot with colleagues who have valued it less or simply did not understand. To resolve these debates once and for all, I tried to give them a glimpse of the thought process behind my HTML writing.
I looked up a straightforward website and derived its HTML structure (without looking at the HTML, which would have been cheating). Then, I turned my HTML thought process into a step-by-step visualization. For many of my colleagues, this visualization turned out to be a real eye-opener. These couple of visuals created mutual understanding of what a front-end developer does and why semantic HTML is important. Also, interestingly, it revealed that not all front-end developers view semantic HTML in the same light.
Below is the website I used in the thought process experiment.
I’ve laid out the thought process below. On the left side is my view of the website. On the right is the written HTML as rendered in the browser. OK, let’s do this!
In my opinion, this landing page serves as an umbrella for all subpages. So, I’ll wrap the logo in an h1. I’ll add an img tag as well, so that the logo displays when printed.
All right, next up is the menu. I’m putting it at the top because this is a landing page. Also, let’s handle caps with CSS text-transform. I’ll wrap the menu in a nav and add a mandatory h1 called “Navigation” inside. Also, we’ll add an ordinary unordered list, with anchors as links to the other pages.
Is this image showing a train actually content? And should we, therefore, use an img tag? Or is it aesthetic, meaning we should handle it in CSS using background-image? I’m going with aesthetic, which means it won’t end up in the HTML outline.
What type of content is that white text below the image? What should I name it? How about “Introduction” — I’m not 100% sure, though. I’ll add an “Introduction” heading and hide it with CSS later on. This heading might be useful for screenreaders as well.
Wait a minute! That blue “Join us today” button is related to the introductory paragraph (“… if you joined us”). Also, it’s not a button but a link. I’m setting myself up for a CSS positioning nightmare.
At this point, I don’t know what to do with the “Book an event” button. It’s not related to “Join us today,” that’s for sure. It’s a button without context. I’ll just skip it for now.
Finally, some straightforward content: headings, paragraphs and links. To position them, we might need to wrap some of these in a div later on.
On to the events! Let’s go for an ordered list because shuffling the dates would be confusing. We’ll use the time element for dates and times. Let’s wrap a link around the subheading.
Now we know where the “Book an event” button should go. People need to know about upcoming events before they can book one — makes sense. So, we’ll put the button with the events making our CSS positioning nightmare even worse.
Below is the resulting HTML.
<h1>Greater Dunnellon Historical Society</h1>
<p>We’ve come together … if you joined us.</p>
<a href="/">Join us today</a>
<h2>A commitment to our history</h2>
<p>The Greater Dunnellon … in its heyday.</p>
<h3>Learn about Dunnelon's history</h3>
<p>Dunnellon was platted … South Williams Street.</p>
<a href="/">More history</a>
<h3>Your next event at the depot</h3>
<p>The depot provides … are also available.</p>
<a href="/">Make a reservation</a>
<h3><a href="/">Museum open Tuesdays</a></h3>
<dd><time>01/21/2015 from 11:00 am</time> to <time>4:00 pm</time></dd>
<p>Learn, teach and share history with Boomtown Sam!</p>
<a href="/">Book an event</a>
You probably noticed that I’ve made a lot of assumptions in order to come up with the HTML structure above. The introductory paragraph heading, the banner image and the call-to-action buttons — these were all places where I assumed something and added to or altered information on the page.
I’ve also made assumptions about where to position things on the page. In deriving semantic meaning from textual data, I’ve assumed that the visual designer intended to give information on the right side a lower priority than information on the left. Based of these assumptions, “Upcoming events” ended up below “A commitment to our history.” I put the navigation above “Introduction,” although it might have been better the other way around.
Assumptions are dangerous, not only because one could assume incorrectly, but also because somebody else will most likely assume differently. In this case, if you and I had independently written an HTML tree based on the design above, it would have been a miracle if they turned out the same.
HTML is about giving meaning to information. We should not end up with different descriptions of the same information. It seems that design clouds the meaning of the content and creates room for interpretation and assumption.
A content-first1 approach teaches us that visual design should always be based on actual content. Only with real content can we decide how best to present it to users. We’ll get to what “real” means in a minute.
With a content-first approach, we move from designing without content to designing based on content — a very important distinction. Remember the definition of semantic HTML: giving meaning to content.
Semantic HTML has no relation to appearance — that’s what CSS is for. Why put off the HTML until after the design phase if it doesn’t depend on the appearance? Let’s move it to the front and describe our content before designing it.
It’s a small change, but it makes a big difference. With this change, all assumption is taken out of the equation. We now know how our content will be structured. And before even drawing a pixel, we’ve got ourselves a website.
Do you hear that? That’s the sound of screenreader users celebrating.
Let’s go back to the slides. This time, we’ll do it the other way around. We’ll use the HTML that we’ve just written and imagine a designer using it for their visual design.
It’s difficult to imagine the call-to-action buttons ending up where they were in the original design. In terms of visuals but also content, this new setup makes a lot more sense.
When we were basing the HTML on the initial visual design, we could use the visuals for one viewport only. By turning things around and basing the design on the HTML, we can use the HTML for all possible viewports and contexts.
If I’ve piqued your interest, you might be wondering how to implement this approach in an actual project. Depending on the project, your team and your client, it might look something like the following.
Because we’re doing things content-first, we need to get our hands on the client’s content. Mark Boulton4 rightly points out that content-first is not about waiting for the final content before doing anything. When we talk about content-first, we mean that we want to know the structure of the content that we’re designing for. Having the final content already in hand would be fantastic, but most of the time it simply is not. In “Structure First. Content Always5,” Boulton says:
You can create good experiences without knowing the content. What you can’t do is create good experiences without knowing your content structure.
In my experience, this is true, and making sure everyone knows what “content first” means is important. So, make sure everyone understands that you’re talking about structure and that you don’t mean to pause the project and wait for the client to deliver the final content.
Before we start writing HTML, we need to determine what content to present on the page and how to prioritize it. This is where a priority guide comes in handy. Together with your client, write down all of the content types of your web pages on sticky notes, and then order them chronologically along the y-axis. For example, you could have a “product detail” sticky and a “post a review” sticky, and because someone would need to know about a product before reviewing it, “product detail” should come first. Your client might deem the “post a review” box to be more important, but that importance could be visualized later using color and composition, not by changing the order of content.
I find that clients are pretty good at this exercise, maybe because they are used to writing documents such as quotes and writing papers that must adhere to a certain hierarchy and chronological order to make sense. As I said, this exercise makes them really think about what’s important. Also, if there are multiple stakeholders, it shows how each is motivated and which stakeholders have the most influence.
We’ve set up our content types; let’s talk about content structure. Structuring content is exactly what HTML is good for. Let’s go for it. We’ve got our content types, and we understand semantic HTML, so let’s start adding structure to the various content types. This could be easy or challenging, depending on how high-level your content types are.
A basic “post a review” form could be pretty straightforward:
The “product detail” sticky might be a bit more challenging. In its most minimal form, it could be just a “title,” “image” and “short paragraph.” But your client might also want things in there like “product specifications,” “ordering options,” “related products,” etc. These other content types require further discussion and prioritization. In the end, you might conclude that “post a review” is actually a part of “product detail” because people will be posting a review of the product described in “product detail.”
<p>A groundbreaking Retina display. All-flash architecture. Fourth-generation Intel processors. Remarkably thin and light 13‑inch and 15‑inch designs. Together, these features take the notebook to a place it’s never been. And they’ll do the same for everything you create with it.</p>
<h1>Post a Review</h1>
<!-- 'post review' module here -->
These content types don’t stand on their own. They should be contained in an overall content hierarchy, as we saw in the series of images related to semantic HTML earlier. Together with this hierarchy, your content types should create a nice and correct HTML5 sectioning outline6. To test this, you can copy your HTML to the HTML5 Outliner7.
Below is an example of an initial web page setup.
Now, we could have also done a bit of content choreography8 to make sure each bit of content receives the right amount of attention from the user. In his excellent book Responsive Design Workflow9, Stephan Hay10 advises us to set up content reference wireframes at this point. In my opinion this would be a bit too early — it’s best to wait a bit longer on the composition, because color, typography and functionality will affect the way attention is distributed across the page.
Let’s continue with our basic HTML web page. Don’t show it to your client yet; mix in their brand identity first. Add their logo, and convert their typography rules and color schemes to CSS. This will make it easier for your client to identify with the content — the content will look less anonymous and more like their own.
While your client would be able to relate to the version shown above, they would probably have a hard time getting enthusiastic about it. In my experience, the client will be impressed with the amount of work done but will feel uncomfortable not knowing what the result will look like. I recently renovated my house, and I have to admit, after totally stripping it, taking down walls and removing old plumbing and electricity, I seriously doubted whether it would come together in the end. That’s when I understood how my clients feel.
You need to manage that feeling or else they’ll panic and fall back to the classic web development pattern, demanding design up front.
The version above is the “minimum viable web page.” It contains, if all has gone according to plan, the core content that your client’s users will be coming to the web page for.
If you’ve been using actual content, then even if all hell breaks loose, you could put this online as is. It wouldn’t be perfect, but the brand would be recognizable, and users would be able to access the information.
For now, hell is not breaking loose. So let’s move to the content choreography. Start resizing the browser window and view the page on some different devices. You’ll notice that on a wider viewport the line lengths will become uncomfortable to read. An ideal line contains between 45 and 75 characters11. So, you can regard points where it’s longer or shorter than that as indicators to tweak the layout or font size.
You have two options here: either make the adjustments live in the browser or boot up your favorite design tool. In my experience, designing in the browser is useful for tweaking things such as font size and color, while composition experiments are easier to do in Sketch or Photoshop or using pen and paper.
Tweaking CSS values in the browser might be tempting, but taking a screenshot and making some quick adjustments outside of the browser is usually faster. I find this results in more interesting design choices. When sketching, try to imagine how your solution would scale or break in smaller and bigger viewports and how your design choices relate to the content’s order and importance.
When you’re happy with the sketches, transform the result to CSS.
Now that we have set up the base version of the web page, we can start testing and iterating. Do some quick usability tests, which you can easily do by following the Don’t Make Me Think12 methodology. Sometimes creating a small prototype for this is easier than using the production version.
While tweaking the web page for each context, we can look into adding functionality and presentation styles based on contextual measurements13. For instance, in small viewports, we could move the menu out of view. Or when the user is viewing the web page late at night in a dimly lit environment14, we could load a style sheet with inverted colors. If enough real estate is available, we could turn an address into a Google Map.
If you look closely, you’ll notice that all of these enhancements are layered on top of the content. They only change the way the content is presented and interacted with; they never change the content (or priority of content) itself. This fits perfectly with a strategy of progressive enhancement: Start with the content, and work from there.
We’ll finish up this section with a short note about web applications. The methodology explained above is for content-driven web pages — pages that are and should be accessible to everyone in all contexts. Not all web applications fit this description. Many use HTML to describe the interface instead of the content. In these cases, this methodology might not be the best fit.
Advantages Over Design-First Approach
I’ve compiled a list of the challenges overcome and the advantages gained by this approach. Not to say that this approach does not introduce new challenges, but those new challenges mostly have to do with managing client expectations and team communication.
To the list!
Content — and, therefore, HTML — is the only constant across all devices. How you present your content and how users interact with it will differ between devices, but the content will remain the same. Starting with content means starting with everyone.
Describing content with HTML is not only about lists, paragraphs and headings. It’s also about choosing between buttons and links, dropdown and radio buttons, tables and definition lists. It’s about outlining all functionality with HTML first.
With the content nailed down, there’s less confusion about what things actually are. Something could look like a button in a visual design but in reality be a hyperlink. This creates miscommunication in a team, which is easily prevented by writing HTML first.
Because we’ve layered design on top of HTML, we have created an opportunity for the team to work together. Developers can work on implementing the HTML, while designers can think of compositions for various viewports and contexts. No more deliverable dependencies means no more tiny secret waterfalls.
This methodology enables designers to work concurrently with their developer buddies, allowing them to quickly test things in the browser. Some design problems might be easier to tackle in CSS. As Paul Boag explains15: “Developers might suggest ideas that you might have dismissed as impossible.”
It’s now clear what content should be generated or be manageable via the CMS. Hidden skip links, headers and labels are no longer hidden — all content is right there in plain sight. Design choices can now make content implicit, but that does not mean the content won’t end up in the HTML, because we’ve already written it. In my experience, none of these implicit content items end up in the CMS because they aren’t visible to everyone. By starting with HTML, this is easily resolved.
If you and the client have pinned down what content you want to communicate to users, that will very likely not change during the development process. A change would only happen if user research uncovers some previously unknown facts that warrant a change in course.
Content creates focus. By focusing on content and functionality early on in the process, you’re less likely to end up in a “red or blue?” discussion with the client. Too often clients are tempted to focus on details when they should be thinking of the big picture. With this layered setup, the focus starts with the big picture and then moves to the details during the project.
Having the HTML early on enables you to build the minimum viable product first. In later stages of the project, you can progressively enhance it to further improve the user experience. If you introduce usability testing in the project (which you should), you can use the results to decide what to enhance first. An asynchronous search filtering system might be cool, but your users might value other functionality more. Harry Roberts reminds us16 that “good enough” today is better than “perfect” tomorrow.
As we saw with the call-to-action buttons in the semantic HTML exercise, spotting user experience problems is easier when you’re working with content as the foundation.
Once you’ve finished the HTML, you can immediately start testing the content with visually impaired users. Most of the additional layering will be for the sighted.
Starting with content enables you to more easily define your HTML5 sectioning outline, to pick micro-formats17 or micro-data18 and to apply WAI-ARIA rules19. This results in better accessibility and makes the pages easier to index by search bots.
This approach entails going from a robust stable base to a very detailed flexible end product. By staying away from highly detailed solutions early on, you decrease the risk of putting a lot of hours into unneeded functionality. For example, you could build synchronous search first, and then later on in the project, if your user base turns out to heavily favor search, you could layer asynchronous search and filtering on top of it.
No longer are you creating pretty pictures of web pages. The focus has moved to quick sketches and tiny prototypes to solve design challenges, and the results are quickly transformed in CSS and moved to the browser. We’re throwing away fewer deliverables, which means we’re working more efficiently.
Talk To Your Client
As with everything, it’s all about communication.
If your client thinks the Web is a 1024 × 768-pixel box — and continues thinking this while you and your team are working on their shiny new website — then you’re going to run into a lot of trouble.
Many clients expect a visual design up front, because that’s what they’re used to getting. They don’t know any better.
Your job — not an easy one — is to explain to them why this is impossible. Enlighten them about the millions of different viewports, interaction methods and feature sets out there, and help them understand that you cannot capture all of that in a static design.
If your client understands the Web, you’ve won half the battle.