Creating an Facebook ad really is very easy, and is split up into three simple steps.

1. Designing Your Ad

Designing a Facebook Ad

Designing your ad couldn’t really be simpler. Put in a destination URL, a headline, some ad text, and an optional picture and you’re good to go. There are some useful links to best practices, reasons for rejection and a design FAQ on the page also.

For some reason their preview of the ad has a line saying “Phil Boyle likes this” with a thumbs up icon beside it, but this hasn’t appeared any time we’ve seen the ad displayed.

2. Targeting

Targeting A Facebook Ad

Facebook offers some great targeting options, but also leaves some basic ones out. For instance, you can easily target just men or women, just those in a relationship, or even just those who are engaged. This is a great service for anyone in the wedding industry looking to drum up some business!

However, it only allows you to geographically target by country, which will be too coarse for many businesses, especially smaller local businesses.

Similarly, their other targeting filters will be great for certain business types but all but useless for others.

3. Campaign Pricing

Pricing A Facebook Ad

All the usual options are available when it comes to controlling the cost of your campaign, but there are also some things that we find a little strange. You have to set a daily limit, as they bill you every day. There are also no VAT invoices available for your campaigns at the time of writing.

You can choose either CPM or CPC payment for you ad. We went with CPC ourselves. The suggested bids seem to be picked out of thin air, and they are quickly creeping up too, presumably as more advertisers buy up slots. Pay what you want to pay and don’t be afraid to cut your bids. They do offer a decent set of reports so you can analyse what effect changing your bids has.

Our intention with Facebook advertising was primarily to get our brand in front of as many people as possible with as little cost as possible, and to that end it has been pretty successful. We’ve had coming up to 9,000,000 impressions on our ads and spent less than €900, and that was just targeting Ireland!

So, in summary, if Facebook’s targeting can identify any niche that your business is interested in, it could well be a useful advertising platform for you to explore. For the rest of us it’s probably just a good way to get some cheap name recognition going.

We don’t have a product or sale as a goal of our Facebook advertising, but if you do we’d love to hear how you have gotten on with it and whether you think it has been a success or not, and any other thoughts people have on social network advertising.

When looking at this it is easy to get caught up in looking at your main landing pages to the exclusion of the other pages. At RevaHealth.com we have historically focused on our search results pages to the exclusion of pages deeper in the site.

Old Page

However, times change and we have over 1.5 million pages indexed by Google. Every month Google sends traffic to a about 250,000 different pages including a large number of deep and seemingly unimportant pages.  The vast majority of landings are still on our main search results pages; however there are an increasing number of visitors landing on individual clinic’s profiles.

These profile pages all had a disproportionally large bounce rate when compare to the rest of the site and looking at the pages it should come as no surprise.  For an engaged audience they present the information in a reasonably structured fashion, however for a visitor who has just landed on the page it’s a bit difficult to see why they should stick around.

The most obvious way to reduce bounce on these pages would be to eliminate the advertising. However these pages rely on advertising for revenue generation, so we elected to see if we could reduce the bounce rate while attempting to keep advertising revenue static.

We introduced a navigation panel on the right hand side. The purpose of this panel is to inform the visitor about relevant content in the rest of the site.  The key points are:

New Page

1. The number of relevant clinics in the immediate area that they might be interested in.

2. Up to three sample clinics in the immediate area.

3. The number of relevant clinics in a broader geography with a means of navigating to them.

Other changes we made to the page were:

1. A new call to action within the address field – “Get Phone Number”. About 20% of the visitors to our site are actively looking for a clinic’s telephone number. We don’t want to immediately display this number because we want to track it, however we absolutely want visitors to know that it is available.

2. Introduction of default Description Text where we do not have a description of the clinic along with a call to action.

After making these changes, the bounce rate of the profile pages dropped by nearly 7%, causing an overall drop in the site’s bounce rate of just over 2%.

We’d love to hear your experiences with bounce reduction, especially any unexpected results you had.

Warning – Not for the casual non-technical reader!

The Problem

RevaHealth.com is made up of 10’s of millions of pages, organised as ‘pretty’ URLs such as

• /dentsist/ireland
• /dentists/ireland/dublin
• /dentists/ ireland/dublin/crowns
• /dentists/ ireland/dublin/crowns/the-big-clinic

We cache each page in an asp.net data cache, and this works for frequently requested pages as they have a high cache hit rate. This works by holding the data you need to construct a page in memory. However, there is a fairly heavy code hit which results in a Time to First Byte of 1.2 to 1.5 seconds.

This wasn’t providing the user experience that we wanted and we were determined to lower it, so we added asp.net output page caching with a time to live of an hour. This holds the fully constructed page in the web server memory so it can be close to instantly returned to the user. This resulted in a Time to First Byte of 0.5 seconds.

This was great.

Or so we thought. Regular testing revealed that even frequently requested pages were rarely in our cache. Why? In fact only about one in ten pages were in the cache. This wasn’t good. Was the output page caching not working?

Why?

The answer wasn’t so simple. Firstly, RevaHealth.com is very broad and flat. Search results are divided by the type of clinic (dental, cosmetic, etc) and then further subdivided by multiple levels of location (country, county, city & neighbourhood). To make matters worse there are options for further treatment and/or specialization sub-subdivisions. A typical landing URL might well look like this:

http://www.revahealth.com/dentists/uk/west-midlands/birmingham/erdington/implants

Landing pages are almost all ‘long tail’, and the tail is very, very long. With over 50,000 locations in over 200 countries, several dozen clinic types and hundreds of procedures, we have millions of search pages and over 100,000 clinics. We knew our landing pages covered a very broad range, but only when we looked into the figures more closely did we realise just how broad and how flat the site was.

In a typical period 152,072 visitors entered the site through 36,357 pages. Only 66 of those pages had more than 100 hits and 30,000 had five or less hits. So in a typical one hour period only a few hundred pages were getting a hit in the output cache. The huge bulk of pages requested were not in the cache when requested.

Looking for Solutions

Clearly a simple remedy would be to extend the cache life beyond an hour. But this has business implications. Firstly, when our customers update their profile, they want to see that change reflected as soon as possible. Asking them to wait more than an hour would not be good.

More importantly, for a site like RevaHealth.com, search ordering and the appearance of results is critical, and search results order updates happen dynamically as patients contact clinics, review clinics and generally interact with the site. So, extending cache time to a level where we get more of the tail into the cache would be very problematic.

We decided to simulate traffic to the site, and to force the most frequently requested pages into the cache on an hourly cycle.

cURL seemed to be the obvious tool to use, as we had some experience with it and it is widely accepted. We generated a list of the top 100,000 most frequently requested URLs and created a cURL script to fetch them all.

Our experiences with cURL

cURL is a feature rich tool, but we wanted to use it in a pretty simple way – fetch all the pages on the list on an hourly cycle.

The first problem we encountered was that from the command line there is no way to limit the rate of page fetches. We knew we wanted to fetch them at a rate just above 12/second to ensure that the script would complete in an hour. But curl will only set a speed limit in kb/sec. Since our page size varies greatly, this made fixing that speed a case of trial and error. Obviously we didn’t want to fetch too fast and strain the server unnecessarily, or fetch too slow and not complete the list in an hour.

We could have used libCurl in our own server code and set a rate per second there, but we were keen not to have to write code for this, and instead use the command line tool to keep it simple.

Some relatively straightforward trail-and-error tests revealed a rate which would enable the script to finish within the cache time available (one hour).

What was frustrating during this process was that there is no way for cURL to send the actual file data fetched to nul and to save  the normal stdout output to a file or even send it to the screen. We didn’t want to save the actual output files which could get potentially very large, but sending them to nul meant normal output was sent to nul too. Equally frustrating when testing was that the normal (non verbose) output does not show the URL of the page being fetched.

The progress meter shows bytes downloaded, percentage completed, etc, but rather strangely, not the file being fetched, so there’s no easy way to tell your progress through the list of pages you are fetching.

In the end though we got past all these problems and had a script that worked – or so we thought. In fact, our first run through made no difference to the cache at all. This caused a lot of head scratching until someone looked at the fetched files and we realised that, of course, they were not compressed.

We always return compressed dynamic pages. Since the output file is gzipped, and cached as a compressed file, we were only having non-zipped pages cached.

Helpfully, cURL allows the http request headers to be set on the command line, so simply adding  –header “Accept-Encoding: gzip,deflate” fetched our zipped pages into the cache and testing in Firebug showed that they were being requested by our script.

We watched memory usage during the build up of the cache, and made some adjustments to allow larger physical memory to be used. At a certain number of pages requested we began to see large page usage, so we scaled back the number of pages being requested and all returned to normal.

Browsers Browser Browsers

We thought we were done, but one of the oddest things was yet to bite us. Like most developers, we love Firebug and we were checking everything using Firefox, but before we push changes live we do a fairly rigorous check in other browsers. Disaster. Firefox and Chrome were receiving our new cached page but Internet Explorer wasn’t.

Internet explorer was simply bypassing the cached pages and hitting the code. This was exactly what we were trying to avoid.

The problem was that we were also using GZIP to compress the HTML. It turns out that  IE passes a different parameter for the ‘accept-encoding: gzip’ than Firefox or Chrome does. Even though they all accepted exactly the same encoding the web server wouldn’t serve it up.

• FF: Accept-Encoding: gzip,deflate
• Chrome: Accept-Encoding: bzip2
• IE: Accept-Encoding: : gzip, deflate  (note the space)

Essentially because the browsers were each requesting the same file using very slightly different parameters it resulted in the web server thinking they were different files.

The choice was simple, either:

1. Cut the size of the cache to 33% and increase the length of it 3x
2. Only support some browsers

Unfortunately the commercial reality of choices like this is – ‘Provide the greatest good to the greatest number of users’. This meant only providing cached pages for IE. As a result Firefox and Chrome users have a slightly degraded experience compared to IE users, however this degradation is largely compensated by faster JavaScript engines.

Note: IIS 7 introduces some control that solves this particular issue.

Your War Stories

We’d love to hear about your  trials and tribulations getting time to first byte down. Leave a comment below.

What’s worse is that they frequently don’t know what the problem is. They then turn to yet more designers thinking that the colour scheme or graphic design is at fault, when they should be focusing on the core proposition of communicating their information efficiently to their visitors.

The following are the top 10 most frequent mistakes that we see clinics make when they first build a website.

1. Creating a splash page. This is a page that appears before the main content that ‘introduces the tone’ of the clinic. This just gets in the way of the visitor and the information they are looking for.  RevaHealth.com usability studies have shown that the majority of visitors don’t progress to a second page.  Get the visitor to the content that matters as soon as possible.
2. Background music. You may think it is soothing – it’s not. Most people find background music irritating, especially if this is a repeat visit to your website.  Audio can be used effectively especially in the areas of treatment descriptions, however this is very much an advanced technique.
3. Original navigation. We have seen everything, even using the teeth in a jaw as way to visually navigate a site. This just confuses the visitor. As a general rule, use tabs.
4. Clinical photography of procedures on prominent pages.  Your patient is interested in results – in general it’s only other professionals that are interested in photographic details. It can be good to include these photographs but only include them on deep pages that are clearly linked to with text similar to “view detailed photographs of this procedure’.
5. Expensive, flashy design. Your site needs to look professional; however it doesn’t need to be flashy. It is very easy for clinic owners to get caught up in the design of a website and lose focus on the whole purpose, which is to inform the visitor.
6. Hit counter. You may want to boast about how much traffic your site has, however why does the visitor care. They want to be treated by your clinic, not take out advertising on your site.
7. Not doing the SEO basics. The basics of search engine optimization are simple and given that the search engine should be the #1 distributor of your content there is no excuse not to do them. Give each page a unique title; make sure your website doesn’t require JavaScript and sign up for Google Webmaster Tools.
8. If you are using an agency to create your website many will offer to supply you with stock content, such as treatment descriptions. Don’t use them. The search engines will recognise them as duplicate content and will not rank you for these pages. Worse still they may think you’re a spam site and remove you entirely. Write your own content.
9. Not including basic information that a visitor may want – like a map or opening hours. We will publish a list of the most frequently requested information by visitors in an upcoming post.
10. No call to action. Why do you want a website in the first place? Is it because you want more online enquiries? If so then there needs to be a large and effective call to action – A big red button with ‘Click Here to Contact the Clinic’ or somthing similar on it.

Let us know any common mistakes or omissions from websites that you’ve come across in the comments.

For instance, here is the snippet of code to show a map of general practice doctors in Brighton.

<script type="text/javascript" language="javascript">

document.write("<iframe src='http://www.revahealth.com/doctors/uk/east-sussex/brighton/externalmap' width='600' height='500' frameborder='0'></iframe>");

document.write("<span>Data provided by <a title='RevaHealth.com' href='http://www.revahealth.com'>RevaHealth.com</a><span>");

</script>

And here is how the map would appear on your page.

The map pins show the locations of the clinics. The prices shown are for a standard doctor consultation in the practice. You can pan around and zoom in and out to see more detail about the location of each practice, and click on each pin to see more practice information.

Using the maps on your own website is completely free and easy to do. You just need to add a small snippet of code to your page which pulls in the map and data from the RevaHealth.com server. You don’t need to be a programmer at all; anyone who can edit their own web page can do it easily.

The snippet can easily be changed to show any of the different kinds of clinics in the thousands of locations in Ireland and the UK which are covered in the RevaHealth database. You can contact us at the address below to see what types of clinics are available. For example, you could show Laser eye clinics in Stratford, Dental Clinics in Prestwick or GPs in Cork.

To do it yourself, just search for the URL of any set of clinics on RevaHealth.com as normal, and when you find the list you want, add /externalmap to the end and replace the URL in the example snippet above with the URL of your choice. Hey presto!

The clinic data is constantly being refreshed and updated by the team at RevaHealth.com and users can look up phone numbers or contact the clinics on-line.

The API is free to use, although we do ask you to show the source of the data beside the map on your site with a link to RevaHealth.com. The code snippet above includes the link:

Data provided by RevaHealth.com

which you can change if needs be. If you are interested in putting these maps on your site or have any further enquiries, please contact us at support@revahealth.com.

The whole reason why search engines work as well as they do is because of the huge amount of effort that publishers put into SEO daily. That’s right – without SEO the search engines wouldn’t work.

Why?

Well, what a search engine tries to do is understand the meaning of a page and subsequently display it in the search results when someone types in a query that indicates that they are looking for that content. This is phenomenally difficult to do; even with the best brains on the planet it is currently impossible.

The reason for this is that machine learning isn’t nearly advanced enough to be able to understand at the levels that humans are able to understand.

So the search engines rely on publishers to shape their content so that they can better understand its meaning. Back when the search engines where pretty unsophisticated this literally involved telling the search engine using the meta keywords and meta description tags.

As the search engines and spammers have become more advanced the means of conveying meaning to the search engines has become less overt, but no less important.

RevaHealth.com definition of Search Engine Optimization:

SEO is the science of narrowing the gap between the search engines’ understanding of a page and a human’s understanding.

You will notice from the above definition that this doesn’t include link building. That’s because we regard link building as PR. Just as old school PR was about getting your company correctly positioned in newspapers and on radio, new school PR is the same thing online.

So what can happen if you build a website that solely targets users and not search engines?

The following examples are completely legitimate ways of constructing your website that will have no negative effects on your end users, but will completely ruin your chances of being distributed through the search engines.

Let’s say you are building a listing site similar to RevaHealth.com

1. You use parameters instead of hard URLs.  If you construct your parameters without thinking about SEO  you can easily create a website that the search engines simply won’t index.
2. You use JavaScript to dynamically call in the content similar to Kayak. This can provide a very useful end user feature. However, if coded without reference to SEO it will result in the content not being indexed.
3. You use a template for each page that results in the search engines thinking that each page is a duplicate of another page.
4. You include useful additional information for the user (for example from Wikipedia) that is not original.   At best this will result in the search engine marking down your pages and at worst they might list you as a spam site and exclude your entire site from the index.
5. You have a infinite number of combinations of search results available resulting the search engine giving up before they have crawled all of the relevant content

In Summary

Search engines are the number one means of distributing your content. If you develop a website without considering the SEO implications of your decisions, you are effectively giving the search engines two fingers. Don’t be surprised if they give you two fingers straight back.

We often get asked about our experiences with SEO, usually about what worked for us and what didn’t. Keywords are a topic that come up again and again. The video above comes from Matt Cutts, the head of Google’s Webspam team, and it neatly summarises the fact that when it comes to Google’s main search product, meta keywords are completely ignored.

That should be the end of that then. But it isn’t.

A lot of people seem to get mixed up between keywords and meta keywords, thinking they are exactly the same thing, so the video above might be taken by some people to mean that ALL keywords are ignored by Google. That just isn’t the case.

The word “keywords” can mean many things interchangeably, but for the purposes of this blog post, let’s  refer to a set of keywords as the most important words, phrases or acronyms that your potential visitors will use to find a particular page of content on your site.

For these potential visitors to find your page, the keywords they use, or their synonyms or related keywords will have to appear on or pointing to the page somewhere. These keywords can  appear in:

• the body text of your page
• the URL of the page, including the domain name
• the page title of the page
• the meta description of the page
• the H1 tag on the page
• the alt text of images on the page
• the links to the page

And that’s just off the top of my head. They can also still appear in your meta keywords, even if Google currently chooses to ignore them THERE.

You should still be doing your keyword research for each page (or set of pages) and using those keywords you identify as being the most important in the page elements listed in the paragraph above. Google even offer some good free tools to help you find out what keywords to use. I’d recommend Google’s Search Insights, Google Analytics, their free AdWords Keyword Tool, and even Google Trends. Add your own favourite keyword research tools in the comments below.

The SEO problem with duplicate pages is that Google doesn’t want to clog up its index with a whole bunch of duplicate content, so it tries to cull the duplicate content from its index. In our case it only includes cosmetic surgeons in London in its search results.

In the past we included machine generated text on each page, in an effort to describe on the page in a way people could easily understand what the content was without having to write tens of millions of descriptions by hand. However, because this particular block of text was quite similar from page to page, it hindered us rather than helped us in relation to duplicate content. So we set about trying to find a way to increase the originality of each page.

On a side note, it is possible for you to take control over your own duplicate content and to tell the search engines which page is the original or most important version of a page rather than letting them make that decision for you. You can use either canonical URLs or 301 redirects, something we’ll discuss in another blog post. For now, this is something that we do already, but as the pages are actually valid, non-duplicate pages for our visitors, we think that this shouldn’t be necessary.

So, going back to looking at how to increase the originality of the content on our pages, we took our search results for Dentists in Mexico as our test bed. For 50% of the locations in Mexico we added 2-3 paragraphs of location descriptions taken from Wikipedia. Wikipedia has relevant content that can be re-used on other sites thanks to the GNU Free Documentation License. The link to the original source of the text was included underneath.

We were hoping that syndicating content from Wikipedia could alleviate the duplicate content issue along with giving our visitors a better experience. We let the test run for three months.

The Results

Although our results shouldn’t be regarded as complete, we found that the inclusion of Wikipedia content on our search results pages had no effect on whether the page was included in the main Google index.

However, we also found that all pages with Wikipedia content that were already in the search results dropped by around 3 positions, while all control pages gained on average 2 positions!

Search engines want and reward original content. It is known that Google uses document similarity techniques to keep searchers from finding redundant content in search results. Our experiment left no doubt about it. I only wonder how will Google solve the problem in the current large scale web syndication era if it is possible to find 5 exactly the same articles on the top 5 sites in the results for many of Google searches, e.g.

http://www.google.com/#q=Get+Motivated+to+Create+New+AdSense+Content

We have implemented nearly every performance enhancement possible and by far the most effective one for dynamic pages is page caching. What caching  does is store a copy of every page in the web server’s cache for a period of time. If someone requests the page during that period of time then the web server can serve it up immediately without having to make a request to the actual application.

For us this cuts a full second off of our page load time.  However, recently our page caching started becoming less effective and a greater percentage of landing pages where not in the cache, resulting in increased page load times and increased bounce rate.

The problem was that over the last six months the number of landing pages that the search engines were sending traffic to increased exponentially.  Every month Google sends visitors to over 100,000 different landing pages out of the 250,000 pages that it has indexed.

Caching 100,000 pages in itself is not problematic, however because we dynamically convert pricing on each landing page to the local currency of the visitor it meant we were in effect trying to cache a multiple of this number. At times this was as high as 60 different copies.

This caused our front cache to constantly flush the older pages resulting in decreased coverage of the landing pages.

We examined two possible solutions. The first one was adding more hardware.  This wasn’t a good idea because our problem was an exponential problem as both our landing page and countries that visitors were arriving from were increasing. We came to the realization that we had to stop caching a different page for each source country.

The problem was that we still wanted to have the performance improvements of page caching and to be able to localize into each visitor’s currency.

Our solution was to only cache a single master page for each landing page with the price in Euro. We then store the visitor’s currency and conversion rate in a cookie that we place in their browser. We use JavaScript in the browser to calculate and  display the currency.

This has allowed us to work with the boundaries of our existing hardware and implement a scaling strategy that has near linear requirements on hardware.

The old search results

We deployed an updated version of the RevaHealth.com website last night that focused upon the usability of our main search pages. The goal of these changes is to make it easier for users to refine their search results and increase their engagement with the site.

We are closely monitoring the performance of this change and are expecting to see a noticeable increase in the number of pages viewed by the average visitor. We also expect to see a drop in our bounce rate, however we expect this to be slight. If the test succeeds the next goal will be to convert the increased engagement with the site into delivering value to both the visitor and the clinics featured on the site.

1. We reduced the prominence of the search functionality. While the search boxes are still visible and constantly available we have discovered that the vast majority of our visitors are either interested in further refining their search or broadening it. It is rare that they want to jump into different categories or locations. Eye tracking analysis tells us that putting the search box on the right hand side of the page means that most visitors simply won’t notice it. This works as long as the page is relevant to the visitor, however some users will always land on the wrong page and having the search function available is still important.
2. 

   The new search results

   We logically grouped all of the search functionality into one cohesive unit by putting a white background behind it. Previously the search functionality comprised of three separate items that needed to be tied together into one function by the visitor. Now by strongly visually linking them we hope to have simplified this.
3. We changed the filtering mechanism from tick boxes and radio buttons, replacing them with drop down lists. While we don’t feel the new interface is as elegant or visually appealing as the previous filtering, it is more standard and occupies less real estate. We expect that by adopting the more common practice of drop downs and not forcing our users into learning a relatively unique UI that we will increase the use of this feature. This will give the visitor better and more relevant search results.
4. We increased the size of the title on the page and spaced it out more so that visitors who land on page for the first time can instantly see what the page is about.
5. We added the number of clinics that are returned by a search. So instead of saying ‘All Dentists in XXXX’ we now say ‘All 212 Dentists in XXXX’
6. We have added breadcrumbs into the header of the page for visitors that want to broaden their search criteria. We are not 100% sure about this feature and we expect to do further tests on their placement on the page.