The World Bank has opened up an awful lot of its data. Here are some of the interesting stats from their “World Development Indicators”. There is a caveat, however. The data is out of date since the 2009/2010 data has yet to be released.

Here are some examples from the 2008 version:

Top 10 Countries by Number of Patent Application (by residents)

1. Japan - 330,110
2. USA - 231,588
3. China - 194,579
4. South Korea - 127,114
5. Germany - 49,240
6. Russia - 27,712
7. United Kingdom - 16,52
8. France - 14,743
9. Canada – 5,061
10. Spain - 3,632

Top 10 Countries by Internet Users (Per 100 people)

1. Iceland – 90
2. Sweden – 87
3. Netherlands – 86
4. Denmark – 83
5. Norway – 82
6. Finland – 79
7. Bermuda – 79
8. Luxembourg – 76
9. United Kingdom – 76
10. Switzerland – 76
11. United States – 76

Note: The numbers are rounded. See data.worldbank.org for exact figures. Also bare in mind that was in 2008

Top 10 Countries by cost of Mobile phone subscription plan

This could be used as an alternate to Big Mac index and  potentially for subscription services, which require bandwidth usage. I want to note that countries at the top of the list are there principally because the infrastructure cost is being passed on to customer.

The plan is defined as “which includes the cost of monthly mobile use for 25 outgoing calls per month spread over the same mobile network, other mobile networks, and mobile to fixed-line calls and during peak, off-peak, and weekend times as well as 30 text messages per month.”

1. Brazil - $37
2. France - $36
3. Switzerland - $36
4. Spain - $33
5. Japan - $32
6. Australia - $26
7. Portugal - $26
8. Greece - $25
9. Venezuela, RB - $25
10. Austria - $24
11. New Zealand - $23
12. Cuba - $23

For those interested the UK came in at $20 while the USA $15

Why is this data interesting?

Well, it's the same data one of the largest data mining groups use to determine how solvent, economically viable, and wealthy a country is. However, it's also a great snapshot of life in different countries. While it may have no direct use in eccomerce, it can be used to weigh several factors. When entering new markets, determining cell phone costs and comparing them to how much money people have to spend will ultimately tell you how big a market it is.

One of the more interesting sections for me is 'Economic Rankings'. It's a fascinating place for anyone looking to start, run and close companies abroad. Each country is ranked by various factors ranging from how easy it is to set up a company to how hard it is to sue people. This is actually a whole microsite in its own right.

Getting hold of the data

All this data and hundreds of other indicators and economic data is available from data.worldbank.org. They have an API as well as XML, Excel and various other data types including RFD. I can’t wait to see this data being used! Together with the national data sources for the UK and the USA, its never been easier for data lovers to get their fix!

Over the weekend, Andy Beard pointed me to a Mike Hill video on 'Buyer Mining', which was a response to an interview Techcrunch did with two ex Googlers who started the ecommerce company 'Tell Apart'. It provides sites with leads based on buyer demographic data. They are so confident in their service and the ability to provide such leads, they only charge a percentage of the revenue increase. Think 'affiliate style CPA' here.

Still with me? Cool, because after the video, I’m going to demonstrate how you, as an ecommerce owner and affiliate, can do something similar, for a fraction of the budget.

Buyer Mining

So, what is the 'buyer mining' Mike Hill talks about? Well, put simply, it's looking at key buyer demographics to identify patterns. Some maybe fairly obvious such as the average Tampon buyer being either in the military/Female or both. Others may not be so easy.

Some of the key demographics to grab would include geographic location, age, and gender. In addition, we want to look at the average basket price and whether they are returning customers. Here is Mikes explanation:

Now, the problem is to be statistically reliable, you need a lot of data. In fact, you'll need more than your average ecommerce store can produce. Still, even with a limited data set, you can make some choices when it comes to lead acquisition.

Simple Buyer Mining

Scenario
Let’s assume you are a small/medium ecommerce store selling red widgets, and one of your lead acquisition methods is Facebook ads. These can be a great for targeting users, but it's often hard to tap into and they are fairly expensive, unless you are making a decent return.

Broad Matching Demographic, while possible, is often ineffective. So, to make best use of Facebook ads, we need: a location, a gender, and ideally, an age range. Two out of the 3 are very easy for any company to provide retrospectively, and well, 2 out 3 ain't bad now, is it?

Determine Geographical Location

Virtually all ecommerce systems will store the IP address of the purchase, which can be used to determine location within a few metres in some cases. More likely, it will resolve to a city or a country, at minimum. Be wary, however, as using an IP is not always accurate. For example, my home IP address for many years claimed I lived in London, when I was 200 miles away. At best, it will offer country accuracy with potential city/town. The exception is AOL customers, which some IP systems identify as being in the US regardless of where they are in the world. In addition, you can always take location from the address given at the time of purchase. This will be more accurate, but might only be available for non digital products.

Gender

There are lots of ways to determine gender, and this would be a great place to plug my new tools, except they are not ready yet. Here is a simple way to determine gender in historical data:

From your purchase logs, pull all the first names, and pass them through a gender dictionary to identify female/male names. With the exception of a few Kims, etc. most western names will be one gender or another, and therefore, those running Western based sites should be able to process and get gender demographic quickly and easily. You can do the same for Arabic, but Chinese names are a bit more problematic. Names from some Asian countries and the Indian Subcontinent, however are generally a nightmare to work out this way.

Age

Remember I said 2 out of 3? While you can analyze names to get age,  it is really too unreliable for use. Likewise, browser history is not an option, which leaves only one choice: asking the user for his or her age. Sadly, when looking at historical stats this is not much help. It is also one of the most useful demographics. So much so, I try to encourage all my clients to gather it. For subscriptions and certain products, this is easier to warrant, and obviously you do not want to much cluttering your sales flow, but I strongly suggest you include it even as an optional field.

Facebook Ad fun

Once we have the demographic information, it’s time to do some mining and try to identify trending patterns. Specifically, we want to generate targeted ads.

From experience, the best place to start is with the demographic you should definitely have: location. Depending on your data size, the more you have, the tighter your geographical targeting should be. With this in mind, take your data and split it into geographic regions. For each region, split the data by gender and age, if you have it.  The biggest of these groups will be your first target for Facebook ads. From there, it’s simply a case of setting up one or more ads within Facebook for these groups.

Split Testing

It goes without saying that it’s worth doing straight a/b testing, but it’s worth remembering different groups will react differently, so do split tests for each separate profile group. The results maybe different or you may have a clear winner across all the profiles. Don’t forget to cookie your test groups if they purchase at a later date so you have the split test data. (It’s worth recording regardless to see if a group has a tendency to purchase later.)

Affiliates

I mentioned the above could be used with affiliate marketers, as well as ecommerce owners. This is sort of true, but the ecommerce owner will need identify which of your leads resulted in sales, otherwise you will be grouping blind.

Of course, you can do a blind variation by determining the gender of each lead through CSS history attack. To do this, use the IP for location, split your users up, and test each group to see which is more likely to purchase. However, this could prove to be an expensive option.

I wish to pose a simple question:

How would you determine the price of a product or service for multiple countries?

• You could go through each country and work out a value.
• You choose a base currency and do real time conversions.
• You could use comparable item counting.

Each method has merits, but they are reliant on a lot of manual and repetitive work. They may also cost you when the method fails to take local conditions such as taxes into account.

Work out individual value - This is a long process, but probably the best when working with 1 or 2 currencies in familiar markets. For example, I'm likely to set Pounds, Dollars and Euros because I am familiar with costs in the US and in Europe, but I'm not so sure about prices in South Korea, for example.

Real time counting - (Determining a price in a default currency and converting it into alternative currencies on the fly.) This method has several issues: the price will change constantly, people are nervous of products with constant price changes, and it doesn't take local taxes and other costs into account. Customers in the EU, for instance, wouldn't be charged VAT.

Product Counting - (Finding a product similar to your own and using its price in each country to set your own.) The problem is that the product has to be the same in each country, and it doesn't account for import costs.

So how do burgers help? Well, let's start with an example:

I'm running a subscription site in multiple countries, and I want to display subscriptions to people in their own language and currency.

Identify the costs per country

For each currency, identify any additional costs such as sales taxes, shipping , and any additional costs associated with selling products or services in a country. If it costs you more to supply a country, be sure to include it in your price.

Choose a stable currency as your base

This does not have to be your country's currency, since it's just something to work from. For instance, if you use the Big Mac index, the default currency is dollars, so you may wish to use dollars. Or, you might choose the currency you do your accounts in.

Define the default currency levels

Next, work out the subscription levels in your default currency. Lets say we use $10, $20 and $30 as our levels. Obviously, how you determine the initial price is up to you, but I suggest testing multiple prices before settling on one. Also, remember when choosing a currency conversion system that you can override it when you need to.

Start counting Big Macs

No, seriously! A Big Mac is a perfect comparison tool. It's made of the same ingredients in every country, and is competitively priced. This means that, while McDonalds makes a profit on each burger, it's carefully calculated to be roughly the same % in ever country. For a list of the costs of a Big Mac in every country, you'll need a subscription to the Observer, or you can go to www.oanda.com/currency/big-mac-index

source: Economist

Our next step is to count how many Big Macs are in our subscription. So, a Big Mac in the US costs $3.57 so 10/3.75, and we would need to multiply it by approximately 2.8 to equal our subscription. So, to determine the relative value of a $10 subscription in other countries, we find the value of a Big Mac and multiply it by 2.8.

Lets do a simple example: A Big Mac in the UK is 2.29, and when we multiply that by 2.8, it would be 6.412.


function bigmac($value,$cost,$rate){
return round((floor($value/$cost) * $rate),0,PHP_ROUND_HALF_UP);
}


For PHP users a quick function where $value is default subscription, $cost of the burger in the default country and $rate is the current exchange rate. Works only currencies with similar exchange rates

The real economics of the Big Mac index

The example above is an extremely simple way to use the Big Mac Index. Economists will use the index to determine the purchasing-power parity, which was first proposed by Gustav Cassel. (Purchasing-power parity is when a countries exchange rate is determined by the price of a shopping basket from a super market)

The video from the (http://www.metalproject.co.uk/) explains how economists can compare Big Macs by country to determine the relative value of almost anything. However, this rate often varies wildly from the actual rate, which is affected by many other factors.

Always round up

Now, of course you'll want to convert 6.412 to something a little less programmed, so round to 7,13,19. You'll notice in this example that the bigger the value is, the more of a discount it's getting, and the further it will drift from market demand.

Low inflation currencies probably should be rounded to the next 5 or 0 to maintain a nice pattern.

Note: This only works for low inflation currencies, so don't try this with Zimbabwean dollars. In the example, our Pounds are now 10, 15, 20. Suddenly, the site is making a profit on the lower price and losing on the higher price. Ultimately, it works out even, so long as there is an even distribution.

What about larger subscriptions

Sometimes, Big Macs are just to small to be useful. As you saw in the previous examples, the more Big Macs you work with, the greater the rounding error will be. So, when dealing with larger numbers, we could use an alternate index.

One possible example is the iPod Index. Initially proposed back in 2007 by Comsec, the iPod has become as ubiquitous as the MP3. Unfortunately, they do not maintain the index, but it's possible to recreate it using the Apple store and some googling.

Other methods

One technique I've used is what I call 'over pegged middle'. First, you need to know the number of subscribers for each level and the total income they bring in. Then, whichever total brings in the most income is the one you do the Big Mac check against.

Next, round that figure up to a 5 or zero and match the other subscriptions by using the same ratio as the original subscription. This will cause an imbalance because the majority of users will pay more, but it will also make higher earning subscriptions more tempting.

Any suggestions for how you would work out subscription prices?

Currently I run:

• Google Analytics
• Google Weboptimiser and other A/B testing
• GetClicky
• Heatmap software
• Occasional CSS History profiler
• Surveys

If I want to track a user across all these currently I can't for example if I want to see the clickmap of a user I can't compare it with Google Analytical data for example. This is fine but the more work I do the more I want to be able to follow a user through the entire experience, now at this stage many people may start to think ok, reduce the number of third party software and this thought has occured to me. The reason I use getclicky and Google Analytics is I can't do better it's that simple.

Privacy Concerns

The biggest issue when linking multiple systems together is the inevitable extra privacy issues, while these systems are separate they are psuedo anonymous combining them makes it much easier to identify a user especially when linked with a login/commenting system where they have to give their email and other information like name. However in many ways I think centralising your data makes dealing with concerns easier to deal with for example you can set up a single "remove me from your tracking" service (also you can track how many people have opt'd out! oh wait is that wrong?) so centralising my data not only will make things easier for me it will make it easier for visitors who have privacy concerns.

Central storage area

The obvious way to centralise all the data is to create a central storage repository and put data in it, of course this immediately prevents several obvious problems.

• Replication
• Single Point of Failure
• Reliability

Replication - There is rarely a good reason in life to have two working copies of something, your analytics data included, apart from the fact you have to maintain both copies you also have to check data integrity and it's taking up space and therefore costing more to store.

Single Point of Failure - while not normally a problem, when something is being continually used both for read write it''s life expectancy is limited made worse by the fact that several parts of the site will be reliant on the system to make choices, if the system falls over or worse is just slow it will cause issues throughout the site.

Reliability - One of the reasons to use third party services is so I don't have to handle such things as uptime and reliability any benefit in getting someone else to do the work is lost if I then redo it.

the advantage is speed and as long as it's up we should be able to access everything instantly.

Decentralised with key link

The second approach to look at it is linking all the various services with a common key. Most third party services worth anything will allow you to store a custom value against a visitor. If the same custom value is used per visitor for all the services then they can be tracked through various calls to each services API. This is easier said then done...

A couple of problems that immediately come to mind

• Identifying the unique visitor
• Linking a visitor after the fact
• What controls the initial identification

It also has the potential for a single point of failure of the totally centralised solution, the service that tags visitors is down the data is lost. This however seems a much smaller risk, at worse some visitors are not tagged correctly and it probably means the site has far worse problems!

Identifying the unique visitor - This at first glance seems easy but to be accurate is actually more difficult and is a post in it's own right. Once identified the next problem is choosing a naming strategy for a visitor Id if we had a centralised relational database this would be easy it would be the id of the row but we don't. Some ideas I played with was timestamp, IP and profile type or some combination of these.

Once the ID of the unique user is set and stored on their machine either through a session, cookie or some more hardy persist storage they can be simply picked up in the future.

Linking to a user after the fact - There can be times where a user maybe identified after a service has stored data about the individual some systems will automatically tie in the old data with the new, others won't unfortunately there is not much you can do barring a recursive check and additions. For example let's assume a user visits a site on a laptop from home, then visits at work. We treat his work log in as a different instance, when he logs in, we can identify this new visitor under the same user. However we have already sent a pile of custom keys to all our analytical packages.

What controls the initial identification - here is a more tricky issue in the scenario to my blog, a simple wordpress plugin that checks to see if a persistent storage or cookie is on the users machine, determines ID and adds a cookie as needed.

so two competing systems both with problems the solution seems to be a blend between the two.

Decentralised in a Centralised way

I'm going to run through two examples of the way I'm going to centralise my data, one for here timnash.co.uk and the other for a membership site.

On timnash.co.uk I'm going for a totally decentralised approach, a wordpress plugin, will identify users based on if they have been tagged before as I have no easy way to identify if they are previous user on a different browser machine, except if they comment there is no major advantage of maintaining any form of database control. Users will be tagged with a combination of timestamp+profileid+random number
This is then included as custom data to all the stats gathering packages and stored on the users machine using browsers persistent storage. If a user wishes me not to collate individual data they can opt out via the privacy page, this will place a persistent storage cookie, telling the system to not attach the key to their pages, to opt out entirely they will still need to individual drop out of each service.

For a Membership I run I plan a similar system however as it has a login system, individual browser profiles (unique keys) will be stored against a logged in user. This will allow these profiles to be linked via the username and has the advantage of spotting password sharers if their are a large quantity of browser combinations (it should be able to detect even if users use proxies or are on a corporate network)

so that's the plan, anyone see any major issues with it? let me know, ideally before I fully build it! How are you managing your various data services?

Already in the forum are:

• How I'm profiling all of you guys in the hope when I relaunched timnash.co.uk I can better serve your needs
• Sample JQuery code for the CSS History Hack which reports back to a logging system
• How I'm using Big Macs to determine prices of subscriptions

If your a Dojo member check the new forums out, if your not well here is a couple of samples of what you are missing...

Profiling the SEO Community

My site tends to be geeky bordering on nerdy at times therefore my target audience are geeky search geeks, programmers and IR peeps, yet the people who come to my site are mainly SEOs/Internet Marketers who tend to run away quite quickly. Likewise a third group exist clients or potential clients they visit the site not in the hope of knowledge but to contact me. However this third group expect to not understand the posts. There are more groups such as the Bob Massa spam team who regularly visit but let's concentrate on identifying the first three.

The problem is interesting, normally when you have two groups it's easy to pick instant differences for example with the CSS history hack we could and indeed will look to see if they have visited certain sites. for example:

www.huomah.com/dojo/component/option,com_kunena/Itemid,65/ = clearly a search geek with some intelligence
www.seomoz.org/members/ = an idiot with no brains at all

The problem is when they are both it's hard to have a search geek with some intelligence but with no brains.

the solution that I pose is to build onto sub profile the Search geek becomes a part of the internet marketer profile, this is fine in most cases we will want to treat them the same but not in all cases so we still need to pick them out.
http://www.huomah.com/dojo/component/option,com_kunena/Itemid,65/catid,55/func,view/id,2915/

Identifying Subscriptions Prices using McDonalds Big Macs

Define you default currencies levels[/b]
Next is to work out our subscription levels in your default currency lets say we are choosing $10, $20, $30 as our levels nice easy figures, obviously these are not our final figures we are going to be price break testing right, all nod and say yes Tim.

Start counting Big Macs
No seriously a Big Mac is a perfect comparison tool, it is made of the same ingredients in every country and is competitively priced meaning while McDonalds makes a profit on each burger it's carefully calculated to be roughly the same % in ever country. For a list of the cost of a Big Mac in every country you either can get a subscription to the Observer or go to....
http://www.huomah.com/dojo/component/option,com_kunena/Itemid,65/catid,56/func,view/id,2929/

So what are you waiting for if your not a dojo member it's just $30 a month which is a steal. Go on you want to join me and 200 other dojoers.

The seminar started with hellos and introductions before going into a couple of fun games the idea was to get people to start looking at each other and to understand we can pull data from multiple sources. We ended up using word association to generate rudimentary and fun profiles of the attendees before going into some of the methodology behind some of the work I do. The second half was much more focused and included overviews and specific ideas and techniques.

I think everyone left with value for money (after all it was free!) and loads of information to digest but even amongst the small group the amount of use from the seminar will be varied.

Our attendees fell roughly into the following categories:

• Bloggers - and professional writers probably got more out of the first half of the seminar
• Web developers - More out of the second half then the first
• Internet Marketers - Not sure I suspect more out of the second half which would be a shame because that implies quick fix
• SEOs - looked confused because Google was mentioned but once

The problem comes I'm not providing a solution, a quick fix or indeed a way forward but rather an ideas and concepts I strongly believe the one example I showed in the second half for guaranteed under cutting of your competitors price is worth virtually any ticket price I wish to set. I also intend to provide more detailed examples and access to video content for any attendees. This is not an unusual business model its proven to work, the issue is not with the concept, the content but the pitch and who to pitch to itself.

I want to run at least one more seminar and to be honest it would be nice if it paid for itself even if I wish to provide online access via a paywall (for at least some content). I don't really want to offer a product or service and really prefer to simply communicate the ideas. Consequently I have now got a difficult choice of who to market to and what to charge (if anything) and so am thinking the people who read my blog are my current audience the best people to ask so tell me what do you think?