Archive for August, 2010

How to Vet Potential Affiliates

Monday, August 30th, 2010

By Adam Ward

Whether working for a network or an advertiser, affiliate managers spend a lot of their time trying to recruit quality affiliates for their programs. Since recruiting is a two-way street, they also spend a lot of time vetting affiliates who want to join their programs, making sure they don’t accept the less-than-desirable publishers.

If you are an affiliate manager, here are some simple steps you can follow to ensure you’re accepting quality publishers into your program.

  1. Look at the email address. Does it look legitimate? If the affiliate site is www.companyx.com, you would expect an email address to look like soandso@companyx.com. Many affiliates use gmail for their email, though, since they often manage many domains. In that case, you would expect that an email address including part of their name would be more legitimate than something like 49grd36@gmail.com. If the email looks questionable, move onto the next step.
  2. Call the phone number. If you reach a business directory corroborating the company name, you should be fine. If you reach the person, ask questions to confirm the information they provided on the sign-up form. If they have trouble answering them, don’t accept them. If you get sent to voice mail, what type of a message is it? Is it a business message or a personal message? If it doesn’t feel right, it probably isn’t. To confirm your suspicions, move to the next step.
  3. Check out the business address on Google Maps. Using Street View, you’ll be able to see whether the business is a building, a home, or an empty field.

Although there are many publishers that like to work under the shroud of secrecy for fear other publishers will steal their money-making ideas, more legitimate publishers realize they have nothing to hide. And since your affiliates will essentially be your business partners, wouldn’t you rather know who you’re dealing with and err on the side of caution?

Tags: ,
Posted in For Advertisers | 4 Comments »

What if EPC Doesn’t Really Mean Earnings Per Click?

Wednesday, August 25th, 2010

By Adam Ward

Acronyms abound in the online-marketing world: CPA, CPS, CPM, CTR, SEO, PR, CRO, etc. They are straight forward, except for when they aren’t. And since nobody knows where they originated from, everybody adopts their usages, even if they aren’t particularly intuitive. The term EPC seems to be one of those. It means earnings per click, right? Everybody will tell you that. But then why, when you sit down and calculate it, does it mean earnings averaged over a hundred clicks? And why don’t we then refer to it as EPHC? Or EPH?

What if, instead, the “C” is supposed to represent the Latin word for 100, or centum? There is a precedence there. After all, CPM stands for cost per mille, the Latin word for thousand. But none of us say that. If we refer to CPM without saying the acronym, we always just call it cost per thousand. Likewise, we’ll all continue to refer to EPC as earnings per click; but if anyone asks why it doesn’t really mean earnings per click, I think I’ll throw in the centum thing just to watch them scratch their heads harder.

Posted in Random | 2 Comments »

Why it is So Hard to Aggregate Tracking Statistics for Affiliate Marketers

Friday, August 6th, 2010

By Adam Ward

“And it’s so easy, it’s so easy, it’s just so easy, to do the goat dance. Yeah, but it’s so hard, it’s so hard, to love somebody, really love somebody.” -Greg Brown, So Hard

If affiliate marketing is the goat dance (whatever that is), then tracking statistics is loving somebody. In Feeling the Pain, I mentioned that one of the top frustrations for affiliate marketers is having to log into every network to access the tracking statistics from their affiliate programs. Everyone we talk to that runs on more than one affiliate network tells us what a hassle that is.

So that begs the question of why it is so hard to aggregate those statistics. Certainly, companies have built databases for personal use that aggregate statistics across multiple networks, and some have even done it for commercial use. But they will tell you it is hard, and not a panacea. When you understand what they have to do, you begin to understand why.

First, there are only so many ways you can pull data from a database. If you have direct access to the database and know what report to run (or write), it is easy. But no network is going to give a publisher or advertiser direct access to their database. Instead, your access is either going to come from an Application Programming Interface (API) that was written and authorized by the network, viewing the reports through a Web browser (which you may or may not be able to export to your hard drive), or from the network pushing the report to you via FTP or email.

APIs

Let’s look at APIs first. APIs are great if you can get them. By writing an API, a network essentially tells developers what parts of their database they can access, and provides the vocabulary for them to pull the data they are looking for. So if every network had an API, a developer could easily use those APIs to pull all the tracking statistics into your own database, which you could then run consolidated reports from.

Here are the problems, though. First, not all networks have APIs. Even if they aren’t opposed to having you get your information that way (it is your data, after all), they have to take the time and effort to write the APIs. That includes documentation on what APIs are available, and what the data structures, object classes, protocols, etc. are used in them. Second, if they do have APIs (yes, there will most likely be multiple APIs), they may not be written using the same protocol. The same network can have some APIs that use Simple Object Access Protocol (SOAP) and others that use Representational State Transfer (REST). That drives developers nuts. Third, even if they have some APIs, they may not have them for everything you are looking for in your consolidated report. That means you either have to forego that desired information, or you pull it in with a scrape.

Scrapes

A scrape refers to creating a program that will go to a website, log in as a user with a username and password, go to a particular page on the site, run any necessary reports, and harvest the results of those reports into a database outside the site. This happens automatically, perhaps on a daily basis. This sounds fine, considering you ostensibly should be able to pull all the information you have access to as a real user logging in.

Except for these problems. First, companies don’t particularly like non-humans logging into their sites. They may employ software tools to thwart hackers, which could restrict access. Just because an application can scrape the site today doesn’t mean it will have access tomorrow. And even if it does, it relies on everything staying the same on the site. If the website changes to where the report shows up in a different place, or with a different name, the data pulled from the scrape could be missing, or worse, replaced with incorrect data. That means your developer has to constantly be tweaking your report. And third, unlike APIs, networks don’t have any control over what information you’re pulling from their databases. Besides not liking that, it may be in violation of their terms of service.

The Good News

As we’ve talked to networks about data aggregation, we have yet to have one tell us they are opposed to it.

The Bad News

Just because they aren’t opposed to it, networks don’t seem to have a big enough incentive yet to help out with the effort, short of some of them providing APIs. Even though their customers are all clamoring for it, they aren’t leaving the network over it. After all, where would they go?

Tags: , ,
Posted in For Advertisers, For Publishers | 4 Comments »