Part 4 - Traffic Test - Show Me the Money!

Analytics can generate exceptional returns.

This is the third in the series on running a traffic test. The first three articles in the series can be viewed at:
Part 1 – Baseline Data

Part 2 – Focusing on Performance
Part 3 – Improving the Revenue

Escrow.com

In the previous three articles I’ve been taking readers through an actual traffic test that a real prospective client is doing with ParkLogic (I'm a co-founder). I have not doctored the numbers or done anything to make them look better. They’re the real deal.

The traffic test is now at the stage where we are looking at really putting the foot down to maximise the revenue. Overall, there has been a 36% uplift in revenue, which for most people this would be an outstanding result. Once you begin to dig into the numbers the results look even better.

The following chart compares the performance of the latest week’s data versus the baseline as a percentage for various traffic levels. For instance, for domains where we saw at least the same level of traffic as the baseline there was a 46% uplift in revenue, for domains with at least 80% of the traffic, an overall 43% uplift. This continues on until for all domains it’s just shy of 36%.

Results by traffic level

 All domains will have varying traffic levels over time and what this chart displays is the performance of the traffic test at the different traffic levels. Since domains with less traffic take longer to optimise then it also suggests that the low traffic domains still have potential upside that is yet unrealised.

Continue reading
0
  930 Hits
  0 Comments
930 Hits
0 Comments

Part 2 – Traffic Test – Focusing on Performance

What determines good performance?

This is the second in the series on running a traffic test. The first may be viewed by clicking on the link below:

Part 1 – Traffic Test – Baseline Data

Escrow.com

One of the challenges of running a traffic test is to determine which metrics should be used for comparison purposes. I’ve had so many people tell me that all that matters is revenue…..I beg to disagree.

Although revenue is a very important metric it is not the only metric that should be paid attention to. For example, let’s imagine the baseline data for an education related domain is from May and the traffic test started mid-June.

Many education advertisers wind down during June and therefore the pay-out rates per click will typically be less for this type of traffic. In addition, depending upon the type of education domain the traffic is likely to be less as well.

What we need to do is to interpret what the data is telling us and not just look at it and say, “The revenue is down, I’m pulling the test.”

One of the challenges in running a traffic test is using views as a comparison metric. Because every provider counts views differently then using this metric can end up becoming quite subjective....that being said, sometimes it's all that is provided in the baseline data so it's better than nothing.

Many years ago, I was sitting in a meeting with a person that controlled a very large domain portfolio. They were running a traffic test with us and we were taking them through our typical analysis and discussing what was happening at the individual domain level. This surprised the prospective client as they said they’d never done that before.

Continue reading
0
  678 Hits
  0 Comments
678 Hits
0 Comments

Part 7 - Portfolio Optimisation - Running a Traffic Test

So you’ve just been to The Domain Conference in Fort Lauderdale and a monetisation company convinces you that you should run a test with them. Is there any real point and what is the best way to do this?

If you’ve ever moved your domains between parking companies by changing the nameservers then you will very quickly realise that there are so many variables to consider that the test becomes meaningless. For example, by routing the traffic at different periods of time, traffic volumes and domain market verticals all contribute to distorting the results.

In addition, if you move all of your domains across to the new company then from the previous article in this series we now know the best case scenario is they will win 35% of the time. Remember this number is for a properly optimised domain portfolio. If they win more than that then it’s only because your portfolio has not been looked after.

All monetisation companies know that they will perform well on some domains and not so well on others. Their goal is to hope and pray that overall the total amount they pay you will be more than your current parking solution.

From the domain investors perspective this is a really silly way of looking at things. What you actually want is to leave all the domains that win with the new company with them and automatically move all the domains that do worse away. This then maximises your earnings.

The ideal solution would be to keep all of your domains where they are and then send a percentage of the traffic to the new company for testing. This process allows you to accurately benchmark the new deal with a greatly diminished risk, compared to sending all of the traffic for your domains to the new company.

Earlier this year, one of ParkLogic’s customers had just returned from NamesCon and they were approached by a couple of the parking companies to run a test. Rather than move all of the domains away from ParkLogic they had a chat with me and we then routed a portion of their traffic to special accounts setup for them at the new companies.

They then were able to assess down to the cent on each domain whether the new deals were any good or not. In the end they moved everything back to their ParkLogic controlled accounts as they performed better than the specially setup ones. I should say that we were very happy to facilitate this process for our client as we regard it as one of the services we provide.

This structured process provides domain investors and any of their investors the confidence that everything that can be done is being done to maximise earnings. There’s no “grass is greener on the other side of the fence” as we absolutely know what the grass looks like and tastes.

Ultimately what you need to assess is your stomach for risk or in other words, how big a percentage is good enough? We typically find that forcing around 20% of the traffic for each domain over a couple of weeks (time depends upon traffic levels) gives a good enough sample. If the new company wins then you should move 100% of the traffic across to them…..and this is what we do. If a few weeks later they don’t perform as well then we automatically migrate the traffic back to the winning solution.

So after going through this process, what constitutes a win for the new company? You can’t use revenue as the traffic will have varied for the domain and distort the result. The only measurement that you can use is the normalised RPM.

Remember, we discussed this in a previous article. A normalised RPM involves measuring exactly how much raw unfiltered traffic we have sent for a particular domain to a particular parking company. We then measure get the revenue generated from that traffic. For a domain, mathematically this looks like:

(revenue at a parking company) / (total traffic sent to the parking company) x 1000

This then means that for every domain we will typically have the normalised RPM for every monetisation solution at any point in time…..yes, that’s what we do. In fact, we collect around three hundred different metrics for every domain every single day.

So when we were assessing for a client whether the new companies were performing better we we’re not looking at the revenue. We are looking at the normalised RPM because this metric tells us if the grass is actually green or brown. Given the process we also know the colour of the grass for every solution at any point in time.

So let’s imagine you’re not with ParkLogic and you don’t have any baseline normalised RPMs. For many clients we typically integrate their current monetisation account into the system. They change the nameservers to ParkLogic and we then route 100% of the traffic back to their existing provider.

By going through this process there won’t be a drop in revenue and it allows us to establish a baseline normalised RPM that we can measure any new solutions against. We then test a portion of the traffic elsewhere to see if it will perform better at other solutions. The whole time we are keeping an eye on the normalised RPM. It isn’t long before we see an uplift in the overall revenue.

This is the proper way to conduct a traffic test as it provides definitive performance data that is accurate. I hate to say it but any other methodology will largely be guesswork which is likely to end up with a suboptimal result.

0
  2459 Hits
  0 Comments
2459 Hits
0 Comments

How To Conduct a Domain Traffic Test - Part 2

This is the second article in the series on conducting a domain traffic test. The first article can be read by going to: How to Conduct a Domain Traffic Test - Part 1

For the past 8 years I’ve been looking at nRPM (normalised RPM) numbers and routing traffic to the best solutions at any point in time. This has produced significant gains for clients and well worth the effort of getting messy in the numbers.

Escrow.com

So now that there is an agreed set of definitions for metrics what do we need to do to conduct a traffic test? There are two main approaches:

1.      Using baseline data

2.      Using the existing monetisation account

When conducting a traffic test most domain owners provide us with the previous month’s stats to be measured against. One of the problems with this is that we don’t have the raw traffic numbers to generate a normalised RPM. One of the good things is although the stats are taken from a different time period they can be useful in focusing attention on which domains are clear winners and losers. Regardless of the outcome we need to understand why we are winning or losing.

For example, what’s the point in claiming victory if the domain has twice as much traffic during the testing period compared to the baseline? Although good, it would be false to say that it was due to traffic optimisation.

For larger traffic tests it’s far better to adopt option two and run the test by integrating the existing monetisation account into the traffic mix and then sample around 20% of the traffic elsewhere. If the new monetisation sources win the traffic, then all of that domain’s traffic is then moved to the new provider.

For example, let’s imagine that you have all of your traffic going to an account at Domain Sponsor. You want to check out if they are still the best solution for your traffic so you ask me to setup a traffic test. The first thing we do is integrate your existing Domain Sponsor account into ParkLogic and then leave 80% of the traffic still flowing through to DS while we test other monetisation solutions with the remaining 20%.

So rather than having to move all of your traffic you are now only risking 20%. Remember that 20% will earn some money (hopefully more than DS) so your revenue risk is more than likely going to become a win. What’s even better is that we can clearly establish a nRPM for the traffic flowing through to DS and know beyond any doubt who is actually paying the best at that point in time.

With traffic optimisation it’s vitally important that each domain is reviewed and treated as a unique case. There is no point in optimising across an entire portfolio is you don’t also focus on the domains themselves. It’s like the old saying, “look after the pennies and the dollars will look after themselves.” The domains are the pennies and the portfolio is the dollars.

The next article will continue to unpack what metrics we focus on in a traffic test.

----------------------------------------------------------------------------

Michael Gilmour has been in business for over 32 years and has both a BSC in Electronics and Computer Science and an MBA. He was the former vice-chairman of the Internet Industry Association in Australia and is in demand as a speaker at Internet conferences the world over. He has also recently published his first science fiction book, Battleframe.

Michael is passionate about working with online entrepreneurs to help them navigate their new ventures around the many pitfalls that all businesses face. Due to demands on his time, Michael may be contacted by clicking here for limited consulting assignments.

0
  3336 Hits
  1 Comment
3336 Hits
1 Comment

How To Conduct a Domain Traffic Test - Part 1

So many domain owners get incredibly confused by all the different companies that want to monetise their traffic for them. Which one is best? How do I really know if they are better than another? What is the best way to run a test? All of these questions are vital if you wish to get the most out of your domain traffic.

In this article I will unpack the critical success factors of what makes a viable good traffic test so that you will always know that you are monetising your traffic with the right provider.

Escrow.com

For a start, to eliminate any discrepancies in timing, all traffic tests need to be conducted simultaneously. What you don’t want to do is change your DNS to point to parking company A and then a few weeks later change the DNS to parking company B. The two separate periods of time introduce large errors in determining who is the real winner.

Without the proper tools, running a simultaneous test can be difficult but with a good partner this is eminently achievable. As an example, we find that at ParkLogic a number of clients use our services purely for benchmarking one monetisation source versus another. We’re happy to work with anyone on this.

The most important factor in a traffic test is understanding the definition of success. So many people fall into the trap of believing that revenue is the only metric that should be paid attention to. So is that the revenue for December or for September? Is that the revenue where there happened to be a 20% increase in traffic or not? Or how about the revenue when it just so happened that an advertiser paid more for the traffic by a mistake?

As can be seen, revenue, although important, is not the best metric to pay attention to during a traffic test. Many domainers have migrated to RPM (revenue per thousand visitors) in an effort to remove the distortions caused by variations in traffic.

For example, if you make $100 from 1,000 visitors then you have an RPM of 100. Let’s imagine that you did a test and you made $200 from 1,000 visitors from a different monetisation provider. Many people jump to the conclusion that the second monetisation provider is the clear winner with an RPM of 200…..and they would be wrong.

The problem with RPM is that it depends upon the views reported by each of the monetisation providers. Sadly, there aren’t any standards on reporting views therefore each provider has a different set of filters applied to the traffic which can dramatically change the number of views reported and ultimately the RPM.

It wasn’t so long ago that some parking companies used RPM more as a marketing tool to say they had the best in the industry! This was easily achieved by just filtering the traffic more aggressively, reporting less views which meant a higher RPM.

For a proper traffic test what we need is an unassailable metric that can be verified for each monetisation source that we wish to test. The only way to do this is to count the raw unfiltered traffic (ie. URLs) that we send to each monetisation provider for each domain and then see how much revenue that generates. This provides us with a normalised RPM (ie. nRPM) that we can then use for direct comparisons at any point in time.

Let’s take a look at some actual data for a domain (XYZ.com) across a ten day period of time (see below). Day 1 is the latest day’s data and Day 10 is the oldest. There are columns for URLs, nRPM and Revenue for 4 parking companies (1-4). The easiest way to understand what is happening is to read the table from the bottom up so that you can get an idea what is happening as the algorithms seek to move in on the higher paying revenue solutions.

Forensic report

Initially, the domain is only with parking company 4 and on day 7 forced sampling was implemented to expose the traffic to the other parking companies. At Day 6 parking company 4 was being beaten by parking companies 1 and 2. More traffic then flowed to those parking companies and away from two and 4 until parking company 2 began to perform and parking company 4 completely dropped out of the race.

In this example, the traffic flowing between the monetisation providers is very dynamic and moves around quite a lot due to the switching regimes being adopted during the sampling process. There’s a lot of moving parts and reasons why the traffic flows where it does but the whole time the algorithms are focused on increasing the domains revenue.

In the next article in this series I will really unpack how to conduct a structured traffic test and why most domain owners get this wrong.

----------------------------------------------------------------------------

Michael Gilmour has been in business for over 32 years and has both a BSC in Electronics and Computer Science and an MBA. He was the former vice-chairman of the Internet Industry Association in Australia and is in demand as a speaker at Internet conferences the world over. He has also recently published his first science fiction book, Battleframe.

Michael is passionate about working with online entrepreneurs to help them navigate their new ventures around the many pitfalls that all businesses face. Due to demands on his time, Michael may be contacted by clicking here for limited consulting assignments.

0
  4460 Hits
  5 Comments
Tags:
Recent Comments
whizzbang
Hi Michael thanks for the article. Is there a variation on results if the domain is pointed to the platform via DNS A Record ( as ... Read More
02 February 2016
mgilmour
Awesome questions and it's great to be dealing with someone that has some technical experience. Can I suggest that we take this of... Read More
02 February 2016
4460 Hits
5 Comments