However, what really interested me were their new identity services. Now, several sites have been jumping up and down with headlines like “PayPal becomes an identity provider,” which is a tad odd. They have been for a while with both an Authentication API (Though, I think Coding Futures may have been the only company outside of PayPal who were and still are using it.) and more recently, OpenID implementation. What the new services do is bring these experiments to the main stream, with support for both identification and authorisation.

PayPal Identity Implementation

The OpenID system is PayPal’s new standard mechanism for identification for third parties. It’s part of a collective of mechanisms for identity provision called PayPal Access. This is an interesting step to create a brand.

One of the biggest problems we have faced in the past with PayPal identity services is convincing users to make use of it. Many users, when asked to “Login” via PayPal assume they are being asked to enter a payment flow. The OpenID implementation follows the OpenID v2 specification. It can return basic details such as name and the user’s address, and for people running PayPal related services, two exceptionally useful parameters: PayPal account type and the PayPal Verified status. Unlike a normal OpenId implementation, the domain you’re using it on needs to be whitelisted. And to make full use of the system, the entire process should be under https.

PayPal Authorisation Implementation

What is new is the announcement that at last PayPal will be supporting OAuth. OAuth is a token-based service that, once a users identity has been confirmed, grants permissions for your site to take certain actions. Initially, these actions will be limited to accessing certain information, but hopefully, the old permissions API and Adaptive Payment flows will be initiated from Oauth token.

PayPal Access – Branding Identity

As I already mentioned, for me the biggest issue with PayPal’s previous identity services was the lack of branding and PayPal’s attempt to instill user confidence. Having spent so much time and energy into preventing phishing scams, PayPal trained its users not to trust anything that looks like PayPal from a third party site. Consequently, digital payments, embedded goods payment flow and its previous identity service attempts have had issues with consumer confidence.For PayPal to be able to push PayPal Access, they will need to not only push the concept to developers, but also to consumers.

Unifying the technologies into a brand is a good starting point. Making the user experience and language coherent and obvious that no additional charges will be made isn’t quite there yet. The PayPal Access login and approval screens still look too much like a payment flow. They also fail to tell the user why they are logging in until post-login. That said, as PayPal access becomes more widespread, and people are regularly confronted with it, confidence will improve.

On to the cool stuff…
If you are a privacy advocate do yourself a favour look away now…

User Profiling with PayPal Identity Services

In addition to the refreshed OpenID and implementation of Oauth, PayPal also added some additional identity services to improve user profiling: Prospect API, Segmentation API and Product Recommendation Service API. Each of these allows a site to gain information about a PayPal user and their buying habits. It also harnesses the power of the Intelligence Engine on Ebay to product categorise — You can cross-sell from your own inventory to that user.

Prospects and Segmentation APIs

How much is any given user worth? What are their spending habits? How active a shopper are they? With the segmentation and prospects API, a merchant is able to profile individual users overall PayPal habits, including how frequently they shopping, the average spend value of a shop, etc. None of this is finite data. Instead, users are grouped in terms of usage frequency the groups are: Engaged, Habituated & Casual

So, what can you do with this data? Well, for your initial sale, probably not much. But post-sale, this data provides extra details about the user’s sales prospect. For example, if we wished to sell a group of products, we could do so in two ways: individually at a low price, or bundled together at a higher price. With our customers profiled we could target groups differently.

The casual user but big spending group could be targeted with the bundle deal. The super engaged but low spending users could then be targeted with individual products over a range of time.

This does lead to the obvious privacy concerns, of course. In reality, people have been buying and selling this data for years, and all major eccomerce sites are using prospect analysis of some sort.

PayPal is bringing this down to mid-level merchants. It’s worth emphasising that this is PayPal, so expect it to be near impossible to get access to these APIs, without jumping through a dozen or so hoops, while standing on one leg.

The problem comes in when offering these services — There really is no way to do it, without providing user information. The grading bands are wide enough that the demographic information could not be used to judge any financial information. After all, just because someone is a heavy PayPal user does not mean they’re wealthy or poor.

The new data, while interesting and useful, really is scratching the surface. An aspect I would love to see included in the data is a user’s refund/chargeback rate and their average subscription rate. For membership sites and other recurring subscription sites, an idea of how long they have got the user for could totally change the way they present information.

For example, if I know a member subscribes for roughly 3 months, while my overall average is 4 months, I can change my content delivery strategy, so that open content (that starts 1 week and ends the next) is sitting over a 3 month period and not the 4 month mark.

Future of PayPal Identity Services

The announcements are a good start, albeit a slow one. Most of what I have talked about is still in Alpha (with exception of OpenID) rushed out for Innovate. And given PayPal’s track record, these are still a year or more away from becoming a reality.

The shift to OAuth is important. PayPal is not just providing services to identify users, but also a fully-fledged authorization system, which is an industry standard. This has to be applauded, but the old user experience bugs from the old identity system are still there. Even with branding and without a large marketing push, consumers will still struggle to see PayPal as being used for anything other then paying.

One of the things I hope OAuth brings is a unified system. Then, I as a merchant can use OAuth to authenticate and authorize the user, make a call to the segmentation API, present my offer, and start the payment flow with the auth token. This way, the user only has to sign in once.

As a merchant and developer, I want a flow similar to:

Login -> Segmentation API -> Show Offer -> Make Payment -> Show Upsell -> Setup Subscription

This flow should be easy for the consumer. Sadly, this flow currently requires 3 separate PayPal sign ins. And each successive sign in degrades consumer confidence and will power.

With the whole X.Commerce brand, PayPal is trying to create a platform like Amazon and Facebook have. The cornerstone of any platform is opening it to third parties, but given the nature of PayPal’s business, this has to be done in a controlled manner.

The identity services are a step in the right direction, but so often before PayPal has taken a step in the right direction, only to have its own bureaucracy prevent any real usage. I really hope this is not going to be the case and the X.Commerce platform lives up to its promise.

Photo by P_A_H via Flickr

So, here are some of my favourite tips when dealing with mail lists segmentation you may not have thought about:

Recently purchased list

“Amazing savings on TVs get a 42” for just £399”

Such an awesome offer, but I just bought a TV, which is why I’m on this list!

Sods law says an amazing sale will always happen after you purchase, but one of the most prolific reasons for unsubscribes with new users (and to a lesser extent existing companies) is badly timed emails. Keeping track of people who have recently purchased, and making sure they are not sent “sales emails” except for specific up-sells, will help your readers avoid seeing you as insensitive money grabbers. It will reduce your costs, and increase conversion rates, by reducing one of the groups least likely to purchase. Conversely, having a recently purchased list also means you can use this list to flog direct product up-sells. “Need help setting up that TV?”

Segment by purchase

You know who has purchased what, so make sure your email list knows too!

Segmenting by purchase has 2 very important uses: 1) You won’t try to sell someone something they already own 2) You can sell them something they are going to need or might not own. Segmenting by pages they visited when logged in may seem like an exceptionally cunning plan ala Amazon, especially for more niche sites, where it does work…

“Today only: One day sale on Your Secure Stream “

But, if you are selling lots of products, chances are the user is just browsing. By segmenting by purchases, at the very least, you can compare that to their behavioural history, before suggesting rattles.

Behavioural History

I have a great tip for those looking to show a marked increase in conversion: don’t send emails to people who won’t purchase. Simples!

Virtually all good mail campaign providers will provide statistics and allow you to segment based on who clicked what, who opened what, etc. If a user rarely opens emails, don’t send him daily deals, as the next one they open will most likely lead to an unsubscribe.

Instead, target him only on major campaign pushes. Likewise, the person who opens regularly, but rarely clicks is a window shopper. Entice them and target them with coupons. Make offers especially relevant to them. You may also want to use this group for surveys and feedback. Chances are they will click a “free” anything.

Customers Mood

Let’s face it: things happen, mistakes are made, and stuff get’s broken. It’s what customer support is for, but sometimes, it might not be wise to push the latest awesome deals to an upset customer. That said, one of my more interesting emails recently was from a company, who sent me an email suggesting I upgrade to their premium service, after providing some appalling customer service. I wasn’t sure if I should laugh or cry; it was either amazing timing, or a deliberate attempt at an up sell.

Looking at customers moods may not be a metric you have on hand. If it’s not, it might be worth asking support staff to try and gauge the mood of a customer through the support cycle.

I tend to recommend segmenting at least by who has contacted support recently, and if possible, their last known mood. Generally, we will not contact people who have requested recent support,  unless the outcome was positive.

Building segments in MailChimp

In theory, you could do the above by hand, assuming you had the metrics to hand, but it would be long process, and one most mail manager GUIs of are not suited for. To get people started, here are some handy hints for doing the above in Mail Chimp. (Other mail managers can do the same, and if you are dealing with lots of products, you may wish to do this in house, as it will get messy.)

I’m going to assume you have built yourself a handy class for handling mail, which has some nice separation of method, parameters and all the boring stuff.

Setting up segments
To add a new segment within the API use the:

listStaticSegmentAdd (APIkey, ListID, Name)

The name can be more or less anything, but remember that it’s what you will see in the Mail Chimp screen. On success, you will be returned an ID. This ID is relative to the list. You will therefore need to make static segments per list.

Removing an unneeded segment is just:

listStaticSegmentDel (APIkey, ListID, seg_id)

Where seg_id is the relative segment ID. Note: It has to be the id, not the name.

Adding users to segments
This again is pretty straight forward:

listStaticSegmentMembersAdd(APIkey, ListID, seg_id,batch)

Batch is an array of IDs (of users in the system), or email addresses. You can mix between the two, if you want to be crazy. I tend to find using emails easier, as I’m often adding data from my own systems and won’t be using Mail Chimp’s internal system. Note: this does NOT add people to lists. If they are not on the list, it will return an error for the given user.

So, can you guess how to remove users?

listStaticSegmentMembersDel(APIkey, ListID, seg_id,batch)

The nice people at Mail Chimp were not imaginative in naming conventions, which to API writers is a good thing. Again, it’s worth noting the Batch is an array of emails or Ids. If you want to wipe all the users from a segment:

listStaticSegmentReset( APIkey, ListID, seg_id)

As tempting as it is when doing temporary segment lists such as new purchases etc to wipe the whole list on each cron job and rebuild, you may wish to avoid it. While it’s nicely efficient from your side of things, it may potentially upset Mail Chimp. Though, this would depend on the size of your list. Also, I confess that I am using this bad practice on one of my lists with a segment that is wiped and rebuilt weekly.

Segmenting by Lists in Mail Chimp
I’m sure it was the middle of last year when myself and Illiya Vjestica MD from Smart Dog were chatting via Twitter. At the time, I had written a simple tool for doing segmentation by list, so you could select a list to segment another list by, when someone from Mail Chimp mentioned the feature already existed. I even remember looking and going, ‘oh yeah, so it does’. Well, I can’t find it any more, and nor can the people at Mail Chimp live support. And, with their URLs all screwed (hmmm there is an SEO/usability post in there somewhere), I can’t even check properly.

That said, it is fairly easy to do via the API (though, sadly it means you will need to run a script before going into Mail Chimp).

1. Add a static segment on your main list, or Sorry Mail Chimp, listStaticSegmentReset if one exists, especially if lists are regularly updated.
2. Use listMembers to get all the user Ids from the list you are segmenting by
3. listStaticSegmentMembersAdd using the list of Ids you just did against your main segment.

That’s it!  The only pain is needing to run it before you go into Mail Chimp.

Other ideas?

This is the point where I go over to you. I haven’t covered bits like geography, time, etc. So, what are some of the ways you segment your list?

I’m currently midway through a major behavioural modelling project. It’s complete with large scale re-targeting, both within the site and via advertising networks, as well as using techniques such as the CSS history hack to collect data about whether a visitor has visited our competitors.

Indeed. Looking at the sort of stats we are collecting:

Everyone coming into one of 3 sites is being tagged, using a browser fingerprint. It’s similar to the level Panopticlick project uses in their efforts to educate users on how to be on the safe side. We also use a persistent storage in the form of persist.js to “cookie” the visitor. Lastly, any third party software, which is capable of accepting custom values, has the user hash added, making tracking a user across the board as easy as possible.

To put this in perspective we can at 1 click retrieve:

• If the user has purchased
• How they arrived on the site
• A rough idea of age
• Rough idea gender
• Where they are coming from (not just country but are they at home or work)
• If they have visited our competitors
• What pages they have visited
• What offers enticed them
• If reinforcement marketing is working
• Any lead mechanisms (email/twitter etc) we may have them subcribed to
• If they are part of a focus or test group
• What ad group they arrived in
• Which split tests they have been set up with
• Where they clicked on a page and when

Basically, everything they have done on the site to the tiniest detail can be looked at, analysed and dissected. What’s more, the average user will not have a clue. That list would terrify many. I mean, if little peeps like us are doing it, then imagine what people like Google are doing. Best get your foil hats now!

Privacy at heart of Behavioural driven campaigns

One of the things that has been important for us from the start of the campaign is for our visitors to be in control, well a bit anyway. If possible, we want them to be able to opt out of our orwellian vision. The problem is how?

Removing data

Let’s assume we have a user who does want to opt out. The first stage is to remove their data. Since our system has a database, this is fairly simple. Just delete their row in the visitors table and any associated data in the meta table. Small snag: this doesn’t remove the data in third party applications and causes data corruption in the master table. Really, there is not much we can do about the 3rd party applications. Where possible, you can try to automate them, but normally the only option you are left with is giving a user a link to the application’s opt out procedures, if indeed they have one at all!

With your own applications, we have gone down the route of what we term “anonymous annihilation”. All our users are split into testing groups, and the user’s information is overwritten by an average of all those in the test group. The only data we keep exact is country. The IP is overwritten to 999.999.999.999, which makes an easy way for us to exclude the data in reporting, and their user agent finger print is reduced by us removing all the plugin data. Suddenly, we can’t tell them from Adam, except for that Persistent “cookie”, which actually is quite a pain to remove. But hey ho! That was the point. The issue is how do we not track them in the future?

Cooking the excluded

The only real way to exclude someone from an opt out system is to know they have opt’d out! But, to know they have opt’d out, we need to either maintain some information, or tag them in some way. Neither of these options are very palatable to the end user, but ultimately, at the moment, it is the only real solution. When opting out, I suggest using a traditional cookie rather then a persistent storage, clearly named within the cookie and make it clear this is what you have done. The downside, if they clear their cookies and come back, you generate a new profile and the circle starts again. But hey, you tried!

Looking to the future

Right now, there is a lot of talk about “Do not track” methods, especially amongst browser manufacturers. Google is releasing a new extension to allow you to prevent tracking (The irony sure will not be lost on them) and there is a more public discussion from the Mozilla team. Both seem to be heading down the route of the browser making the decision to prevent storage, which is great in principal, but has 2 major obstacles to overcome:

Persistent storage is all about hiding things in the most obscure places such as flash storage, where browsers do not have control. Therefore, simply assuming the browser is in control of all storage would be a mistake.

Carpet banning of data, would be frustrating and would effectively break a lot of the modern web. Cookies and storage are used in every aspect of web development, from ad tracking through to analytics, to storing shopping carts, to changing the colour of a site. Users are not going to want to be prompted every time, so they are likely to adopt an on or off approach.

One of the more interesting and hopeful projects is the idea of using headers. Proposed by Mozilla, the idea is that the client browser sends a HTTP header to the server, telling the server the user does not want to be tracked.
X-Tracking-Choice: do-not-track
It’s then up to the server to determine how to handle this. I think this is a great step forward with one major addition.

Telling a browser to send the header, I would like to see a method that allows sites to instruct a browser to send the do not track header. In effect, when someone clicks opt out, the site tells the browser the user wishes to opt out. Now, obviously, you don’t want a site to be able to opt people in, so the mechanism should be one way, and not mandatory for the browser (i.e it shouldn’t override an existing user preference).

The mechanism I propose has one major issue, at the start I explained this was a multi site campaign, but the mechanism is for only one site, and I can’t see a safe way around.

What do you think? Should we adopt Do not click header? What about the ability for a site to ask a browser to enforce it? Would other advertisers use it?

Anatomy Of a Credit Card Number

(Note: this goes for most modern debit cards as well)

MII – Master Industry Identifiers

The very first digit of the long string on your credit card is the master identification number, it tells you which industry the card originated from

• 0 ISO/TC 68 and other industry assignments
• 1 Airlines
• 2 Airlines and other industry assignments
• 3 Travel and entertainment
• 4 Banking and financial
• 5 Banking and financial
• 6 Merchandising and banking
• 7 Petroleum
• 8 Telecommunications and other industry assignments
• 9 National assignment

Some cards may not appear where you expect, but are there for historical reasons. For example, American Express is in Travel and Entertainment, rather than banking.

Another slightly odd one out are Best Buy Credit Cards in the United States, which start with a 7 (I have no idea why Best Buy thinks it’s in the Petroleum industry, but I suspect as it’s an HSBC white labeled card, HSBC owned a company that use to issue under these numbers.)
Just with the first digit we can tell:

• If the card is a VISA card (they all start with 4)
• If they are a specialist business card 0,1,7,8,9
• If they are a second tier (normally debit cards) 6

BIN – Bank Identification Number

Sometimes called IIN (Issuer identification number) this is the first 4 or 6 digits of the card including the MII at the front. With this number you can identify the Issuing party, normally a bank. For example, 4047 83 is NatWest Private Banking Visa Credit Card.

Thinking it is just restricted to Credit and Debit cards? Think again! 6034 50 is Starbucks Card (for Starbucks Europe).

The complete BIN list is kept a closely guarded secret. While the reason normally cited for keeping the list a secret is security by obscurity, it’s more likely simply to protect ISO Registry and American Bankers Associations who publish the list. Bottom line.

There are however numerous attempts to identify all cards a short list can be found on Wikipedia and a larger BINDatabase is also available, which is user contributed. As you would expect, much like postcode data here in the UK, there are people selling copies of the data, but these lists may or may not be genuine so buyer beware.

Checksum

The last digit of the big long number is a checksum. This provides a quick way to validate the credit card number. While not useful in profiling the user, it’s worth noting all modern credit debit cards (including Laser Cards (contrary to Wikipedia) use Mod10 or Luhns Algorithm.

Expiry Date and Sort Code/Issue Number

All Credit Cards have an expiry date and some also include a start date. Using the two numbers and the current date can be used to help determine a risk assessment on the cards. Newer cards will be of a greater risk of charge backs and issues. Older cards are more likely to be hitting credit limits and be maxed out.
Some debit cards have a 6 digit Sort Code (mainly in the UK). The first 2 digits indicate the issuer, much like the BIN number. The last 4 digits are for internal use only, but basically are branch & handling office identifiers. So, for example, 52-41-19 is NatWest, Woolpack Ely Branch.

Getting hold of a list is not easy, as there is no centralised database, but with this date, you know the location of the card holders when they opened their bank accounts. People move; their sortcodes normally don’t.

Issue Number, again, mainly on debit cards, shows how many of that type of card they have had. For example, if a user had a solo card, then was given a switch/maestro card, the issue number on the Switch card would be 1. An issue number could potentially be a way of validating long term stable credit rating, but probably unreliable as such.

Potential Uses For Credit Card Data?

Identifying High Value Customers

Let’s face it: we don’t all have platinum cards in our pockets (well if your card starts 3713 then you do), but just like in a shop, the colour of your credit card often affects your experience. In the online world, it can be the same.

Ecommerce data miners looking for high value customers and can identify more premium credit cards such as the Platinum American Express (3713), Black Card (uk: 3742 88) or Infinite Aerogold (4500 03). There are plenty of others, just remember all that glitters is not gold! There are plenty of gold & platinum cards out there with low limits and anyone can max out their card!

Identifying Fraud Risk/Spending Profiling

Some banks are going to be more likely to have a higher rate of charge backs. In the UK, store cards, most of which are credit cards rather then loyalty cards, have a higher risk of chargeback against them. This can be put down to:

• Targeting people with bad or low credit score
• Lots of pressure from sales staff to push the cards

Likewise, there are certain banks that are likely to have a different approach to risk assessment when offering credit. While it would be unfair to assume all transactions will be fraudulent from these providers, it could be used in any risk calculations. In addition, you can use card types within profiling.

One example is something I’m working on now, which is a donation system where users may select how much they want to pay. When we see a high value platinum card making a $1 donation, it is deemed far more suspicious than if they were making a $50 or $1000 donation. Likewise, if a solo card made a $1000 donation, we would consider that outside of the normal profiling.

Just Being Nosy

When you combine this information with other buyer mining, you can come up with quite a comprehensive overview of a user. Their credit card choice and postcode is enough information along with demographic information from the Acorn Database (for those in the UK)  to make a rough judgment of an individual.

So, next time you use a credit card, ask yourself how much does your card say about you?

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?