Common PPC pitfalls and how to avoid them

We’ve spent a few quid with Google over the past year on their pay per click service. It drives traffic to our website and it has generated conversions, but boy have we wasted a lot of money on trial and error.

Here’s an overview of the mistakes we made initially, so you can skip the learning curve…

What to turn off:

  • All countries but your own
  • Display network
  • People searching about your location rather than in your location
  • Non-business hours
  • Mobile traffic

All of the above are potential PPC money pits, and so it’s best to disable them when you first start out.

Turn on:

  • Your location, start as small as possible

Start small, and test. Too often we thought “screw it, let’s target all the big cities in the US and the UK and hope the numbers work out”. They don’t.

The Ads themselves:

Use exclusive and SPECIFIC language and be sure to include the call to action like “contact us”, “call us”, “sign up for a quote”. You want to dissuade people who won’t convert. Don’t be vague about what you do.


Start low, and SET A DAILY BUDGET to a tiny amount to start. We set our initial daily budget way too high, and burnt through much more advertising spend than I would have liked on a campaign that hadn’t been properly tested.

Your choice of keyword:

  • Broad match modifier only – this gets you 90% of the way with 10% of the effort
  • You only need a few keywords
  • Add negatives that don’t fit your business (“free” is usually a big one)

Landing page:

Do not under any circumstances point your ads at your home page. You need a landing page with a clear call to action. If you’re feeling particularly cute you could even create different landing pages for different ads. So for example, that Ad that you’ve pitched at the construction industry should send visitors to a landing page all about why your <widget> is so great for the construction industry. You will see a huge leap in conversions if you get this right.

On your landing page have just the one call to action.  Make it clear that they can only do one thing, whether that’s sign up, leave their email address, or call you for more info. If your landing page asks for people to call you, tell them to speak with “Chad” to obtain a quote so you can track who is calling from one of your PPC ads.

Testing and optimising performance of your ads:

Look through the keywords that are coming in on a regular basis, and perform the searches yourself to see what comes up (make sure you do this with personalisation turned off). If the query isn’t relevant, use a negative keyword to exclude that traffic. If none of them are relevant, you need to pick better keywords to start with.

Read More

When should you add a new feature to your product?

One of the greatest (and most time consuming) problems a great deal of product companies face is whether they should add feature X to their product.  The gurus over at 37 Signals have a policy of saying no to new features by default. While this is a great strategy, and keeps their apps focused and much easier to manage, this is a very difficult stance to take as a new start up. Fear Of Missing Out (FOMO) will keep even the most steadfast of product managers from staying true to saying no when a potential customer is waving a Visa card at them.

On our feature request forums over at Staff Squared we receive new ideas for our app every week. I’m constantly reading through the feedback we receive, looking for features I believe will increase sign ups and keep us hitting our targets. Therefore it’s incredibly difficult for me to say “No” too.

Understanding this is a weakness of mine, I’ve put a simple checklist of questions in place that I run through for every new feature request.

The questions are separated in to three phases. If the feature doesn’t make it through phase 1, we don’t bother with phase 2. Similarly we don’t go on to phase 3 if the feature doesn’t make it past phase 2. This approach has saved us 1000’s of hours in wasted development time.

Phase 1 – will this feature increase purchases of our app?

  1. Will people buy because we have added this feature?
  2. Will people not buy because we lack this feature?
These two questions are designed to focus our minds on whether the addition of this feature will make a material impact in the number of people buying our app. Other stats are nice, but money talks the loudest.

Phase 2 – what is the benefit of this feature?

So if we’ve passed phase 1, we are now in a position to dig deeper in to what type of ROI we expect to derive from the work we plan to do. At this stage we need to make sure that if we’re going to add features we need to have a clear ROI story. For example:

  1. This feature will add more customers
  2. This feature will convert more existing customers on trials
  3. Our existing customers will pay more if we add this feature
  4. This feature will reduce churn rate
  5. This feature will allow us to gain more press coverage (and therefore more trial sign ups)
A good solid strategy to follow regarding the product development cycle is the Kano Model . It takes into account how leaving out a feature or adding it in affects value to the customer. A milk jug is a common analogy for this:
Adding a thermometer strip to a milk jug adds value to the customer, but leaving it out does not diminish value. Adding volume to the milk jug adds value, but reducing volume reduces value to the customer. Putting a small LCD Display on the milk label adds value, but adds more value than the customer is willing to pay for. Certain features a customer will be willing to pay a lot more to have incorporated, and certain features only have a limited amount of value.

Phase 3 – the devil is in the detail

Having successfully understood and demonstrated ROI on the new feature, we can now dig further in to the detail.

  • Does this feature resonate with our value proposition, vision and values?
  • Will this feature make my product better for my target audience? (Note that target is an important word in this question, you only care what the people buying from you think)
  • What metrics do we think this feature will improve? How will we measure it?
  • How long will this feature take to build?  (Very important to understand the cost versus revenue generated so that we don’t labour for months over a new feature that won’t generate significant revenue)
  • Does this feature overcomplicate my product?

What if we can’t answer some or all of the questions on our own?

In some cases it’s simply not possible to know the answers to the above questions. At this point your best bet is to reach out to your customers (or potential customers) and interview, survey or split test for demand. Personally I struggle with this type of work as it is laborious and I understand that I might be given feedback I don’t want to hear. However, good developers aren’t cheap, and this approach has saved my backside on a number of occasions.

Read More