Tag Archives: traffic

Reviews

Using Contenture to handle micropayments

Back in April, I wrote about micropayments, and why I thought they were an equitable way to reward web publishers for their time and effort. I shared my thoughts on ad revenues, which, for most people, are minimal and not enough to live on, unless you are one of the relatively few websites that gets massive amounts of traffic.

In that same article, I also talked about how I thought micropayments should work, via a standard, instant way to charge readers a few cents per article, through protocols that were integrated into each browser. Instead of charging fees for each transaction, which would be impractical for such small amounts, micropayment processing centers would charge for bundles of transactions which exceed a set limit.

Fast forward a few months, and ZDNet publishes an interview with Barry Diller, one of the early Internet millionaires, where he talks about the very same thing: the need to go beyond falling ad revenues by charging small amounts for useful information. That article was hotly debated on FriendFeed, which is where I found out about it. Among the comments, I found one pointing me to Contenture, a newly launched micropayment system (it saw the light of day on 5/26).

contenture

Contenture’s method of handling micropayments is different from what I envisioned, in that it involves a monthly subscription. Here’s how they say it works:

“… a fully automated system that requires no user interaction. Users simply pay a set fee to Contenture on a monthly basis, and that money is automatically distributed to the sites they visit. How much each site gets from each user is determined by how often that user visits that web site, relative to all of the other Contenture sites they visit. Users get their seamless experience, and the site actually makes money. Everybody wins.”

So what’s involved on my end? I installed Contenture’s WordPress plugin and pasted in an extra line of code to customize the ad hiding behavior. Others might need to paste a Javascript snippet in their footer, which is basically what the plugin does for you.

On your end (the reader), the code will check to see if you’re a Contenture user, and will automatically distribute your subscription fee to the websites that you visit, based on how often you visit each site. As an immediate benefit, all ads on my site are hidden from you. They’ll load as the page loads, but they blink out of view and the ad space collapses unto itself as soon as the page finishes loading. It’s pretty cool.

Other benefits I might be able to offer you in the future are the ability to view exclusive content, or perhaps to even close off the archives to those who aren’t Contenture users, although I’m not too keen on that, since Google won’t be able to index me properly any more if I do it. At any rate, the ability to offer more benefits is built in, and that’s nice.

Contenture’s model is opt-in (also called freemium) and so it has some limitations, in that I don’t get paid for everyone that accesses my content. My micropayment model, the one I envisioned and the one Barry Diller and others are talking about, is standardized across platforms and browsers and works for everyone, all the time. Eventually, I think we’ll get there, but Contenture has made a good start of it, and they did it now, which is why I signed up with them.

To let site visitors know they can support my site, I placed a small link in the header, as you can see below. I also have a link in the footer, also shown below.

header-screenshot

footer-screenshot

I look forward to seeing Contenture’s user base grow, so I can tell whether I’ve made the right choice. I want to keep writing and publishing online for a long time to come, but the only feasible way for me to do that is if I get rewarded properly for my efforts. I believe micropayments are the way to do it. It’s affordable for the readers, and it scales up nicely for me, the web publisher. Time will tell exactly which micropayment method will work best, and you can be sure I’ll continue to monitor the options available out there.

Standard
Thoughts

My Drobo review is first at Google

A couple of days ago, I noticed an increase in the traffic to my Firewire Drobo review, most of it from search engines, so I did a quick search on Google for the phrase “drobo review“, which is what people were using to find me. To my surprise, my review was the first search result that came up! I’d been in the #2 spot for a long time, just under CNET, for the same phrase, but now, without having made any changes to my review since I’d written it, I ranked first.

drobo-review-google-search

This makes me happy, because when I created my site, I wanted to sit down and write good articles while staying away from any unethical SEO tricks or even white-hat SEO tricks like keyword loading and other such unappealing, tedious stuff. I just wanted to create good content and get noticed because of that, not because I’d tricked the search engines into ranking me higher up the page. That would have been an empty success indeed.

It also makes me happy because I like my Drobos. So far, they’ve worked well for me, and I’m glad I’ve found a reliable and expandable way to store all my data. It’s also worthwhile to note that my Firewire Drobo review was published months after it came out officially. I did not get a review unit, I didn’t have to pull any strings to be among the first to get one, and I didn’t spend a feverish night working on my review after it first came out. You know how the press clamors to get review units of products when they first come out… I didn’t do that, and it’s very refreshing to see that after taking my time and really putting my Firewire Drobo through its paces, intensively, for a prolonged period of time, I was able to write a truthful review that is now ranked first at Google.

It’s been about three years of intensive writing, and my work has begun to pay off. (I began publishing multiple articles per week in 2006. I’d only been publishing sporadically until then.) In 2007, almost two years ago, I noticed I was getting more and more traffic from search engines, and made a list of the articles that were getting noticed. For a lot of them, I was either on the first page of search results, or among the first few search results, right at the top.

Still, it’s something to be the first search result for what is a fairly common tech phrase such as “drobo review”, and it really makes my day that I, a writer working alone, using WordPress and hosting my site on my own little Ubuntu web server at SliceHost, has outranked CNET and other big names such as Engadget and others, on Google, the world’s biggest search engine. It serves to illustrate very well a point Matt Cutts from Google has made time and time again: just focus on writing good content, and the rest will come. You’ll get indexed, and as your site builds a larger collection of articles, your online trust will cause you to rise up among the search results, until you make it to the top. You don’t need tricks, you don’t need to get headaches from trying to squeeze SEO juice out of every paragraph and page title and others — you just need to write informative articles.

I’d like to thank God for this. You see, I live by certain principles which are rooted in my religious beliefs, most notably in the Ten Commandments found in the Bible. When I began to write online and created my site, I didn’t want to steal, and I didn’t want to lie. Taking content from others (content-scraping) is theft, so I don’t condone it or do it. Using dirty SEO tricks to rank higher in search results is also theft, because those who do it are robbing others of those spots and robbing tech engineers at search companies of their time, which they will have to use to modify algorithms and clean up the search results. And using those same dirty SEO tricks is effectively a lie, because those who do it are misrepresenting their websites and their articles. That’s not me, I don’t want to do those things, and I’m really glad to see that God proved me right when I stuck by my principles. I’m also glad to see that a company such as Google exists, and that it rewards honest, forthright behavior.

Standard
Thoughts

Micropayments: the only equitable way to reward web publishers

The more time I spend writing and publishing articles on the internet, the more I realize that trying to get paid for my efforts through advertising is not a sustainable way to make a living. I get decent web traffic, but that’s not enough. Have you seen the going CPM rates these days? I’d need to get ridiculous amounts of traffic in order to see any sort of worthwhile profits, and even then, I’m not so sure the costs of running my website wouldn’t trump my revenues or at least take a big bite out of them.

The current system is messed up. Most web publishers don’t get tons of traffic, which also means they don’t make money. They’re lucky if they break even with things like Google AdSense or affiliate programs or other some other ad programs. They, like me, don’t want to load up their websites with ads, left and right, top and bottom, inbetween the lines and everywhere else. They just want to worry about writing and publishing informative articles. They don’t want to spend ¾ of their time (or more) advertising their site and getting their buddies to vote up their posts on Digg or StumbleUpon or who knows where else. They’d much prefer to not have that headache at all, and to only write and publish. But they can’t, because the system is faulty. It only rewards the very few who get the most traffic.

Do you want to know why newspapers aren’t making money these days? Why they’re going under? Sure, blame shoddy journalism, blame whatever else, but the truth is they relied mostly (or solely) on advertising for their revenues, and look where they are now. Subscription fees were kept artificially low, and as circulation numbers started to go down, they couldn’t charge their regular rates for ads, and revenues went down fast, in a vicious spiral that fed itself.

Had a decent micropayment system been in place, the web would be a flourishing, profitable, preferred way to make a living nowadays, instead of the insane, overloaded, “buy, buy, buy, look at me, no look at me, no, I’m better, wait, my titles are more interesting, I get more traffic, I make more money, I know how to increase your traffic, I have more free stuff” nuthouse that it has become. Everyone’s desperate to publish more articles, to make the titles and text more titillating, to grab an extra click from you here and there, to make you vote or like or bookmark their stuff so they can supposedly get more clicks and votes and likes and bookmarks and more and more and more meaningless crap that leads nowhere and contributes to nothing.

Unfortunately for the world and the web, micropayments were talked to death, even in the early days of the internet, and all the fancy initiatives went nowhere. A lot of people were wronged because no one bothered to get things going. Just think, all this time, web publishers of all sizes could have been making an honest living! Fortunately, this nasty situation can still be set right.

Here’s my micropayment initiative. I think it’s workable, and more than that, it would allow a lot of people to make a decent living by doing what they love: writing, not hustling and wasting their time pushing their site on people.

First, we need all the browsers and feed readers to work with the companies or organizations that would process micropayments. Whether the functionality is built in or added through plugins is up to the browser makers and feed reader makers to decide. Users would enter their account information directly in their browser’s or feed reader’s preferences, and their micropayment accounts would be automatically charged every time they access a micropayment-enabled article, on the web or via a feed. There’d be no logging in every time, like with PayPal, which is a hassle when all you want to do is read an article.

Second, search engines and websites would display the price of the article next to its title, just like they’d display the site or the date the article was written. The browser itself would display an extra icon when such a web page is accessed, just like it displays a lock when HTTPS websites are accessed. Perhaps a dollar sign or some other currency sign would show up next to the website’s address. If the user would move their mouse over the button, the price would be displayed, similarly to the behavior of the alt or title tags.

Third, and this would happen behind the scenes, the browser itself would read the price tag of the article the user is reading, and would send that information along to the micropayment service along with the user’s account information. Notice this means the user could use their micropayment service of choice — so there wouldn’t have to be just one — and the browser or the website wouldn’t care. The micropayment service would then transfer the price of the article from the user’s account to the web publisher’s account. The transaction fees would best be charged in bulk, per 50 or 100 transactions or so, and would be deducted from the web publisher’s balance.

That’s it! It’s so simple I just don’t know why it hasn’t yet been implemented.

As for the price of the articles, each web publisher could set their own price. I propose 5 cents per view. When candy and soda costs 75 cents to $1 or more, I think no one would balk at paying 5 cents to read a good article. But let’s have a look at some proposed traffic figures just to give you an idea how 5 cents can add up.

Say you get 5,000 views per month. That’s a modest amount of traffic, but at 5 cents per view, you’d still make $250 at the end of the month. That’s nothing to scoff at. Tell me if you wouldn’t be happy with that money in your bank account!

How about someone who gets 25,000 views per month? That’s a fairly decent amount of traffic. At 5 cents per view, they’d make $1,250 per month. That’s already a line of income. That’s money in the bank you could be using to pay your bills, but you’re not seeing it because micropayments don’t exist yet. Isn’t that infuriating?

How about someone who gets 50,000 views per month? That’s a nice amount of traffic. At 5 cents per view, they’d make $2,500 per month. That’s practically a decent salary right there. If you keep your expenses low, you might even be able to live off that in the US. If you lived in another country where living expenses are less, you could live nicely on that money.

The best part is this: it isn’t free money, and it isn’t money that could be yanked away if your advertisers get pissed off with something you wrote. This is money each and every web publisher has rightfully earned through their work, and yet there is no micropayment system out there to make this possible. This means all the web publishers out there are currently being cheated out of money they could be earning. Isn’t it ridiculous and completely unfair? Think of newspapers, where dedicated journalists work, day in and day out, and who have to close when they could focus their efforts on web publishing and turn a very nice profit with their traffic!

What about developing countries? I suppose the price for reading an article could differ based on your country of origin. The micropayment processor would automatically charge those countries less per article, say 30 to 40 to 70% less, depending on their general economic status.

What about subscriptions? They’re nice but not sufficient. They’re nice because you can predict your income more reliably when you know you’ll have so many subscriptions coming in every month, but not sufficient because users don’t pay per usage. If they end up spending less time on your site, then they’ll feel like they’ve wasted their money on the subscription. Also, just in case you haven’t noticed, subscription numbers are down everywhere these days. When money gets tight, subscriptions are among the first things to go.

What about goodwill, and doing stuff for free? That’s nice, and I already do plenty of stuff for free, but the problem with goodwill is that this world still functions with money. When was the last time you paid your mortgage with goodwill? When you buy your groceries, do you pay with a smile and a hug?

Micropayments are the best way to go forward. I wish people would stop talking about them already and someone would get going with the idea. It goes without saying — but I’ll say it anyway — that I for one would be glad to work with any legitimate company that wants to start processing micropayments.

Standard
Thoughts

WordPress Stats plugin has gone cuckoo

For over a month now, I have been unable to rely on the official WordPress Stats plugin. (I say official because the folks that made WordPress also made this plugin.) It, all of a sudden, started assigning all site visits to the same article, so that all of my stats became completely skewed. Let me explain it with a screenshot:

WordPress Stats has gone cuckoo

Instead of seeing the proper distribution of site visits by titles, which is what happened in the past, almost all of the site visits get assigned to a random post. I have no idea any more which titles get the most traffic for a given day. I know this is wrong because I’m also using Google Analytics. Here’s a screenshot of the 20 most popular titles for the past 30 days.

Google Analytics Content by Title

I like WordPress Stats because they aggregate the data almost instantly, whereas there’s a 3-4 hour delay with Google Analytics. Sometimes they even correct the data a day afterward (this happened to me recently) so you can’t rely on their figures until 24-36 hours after the fact [reference].

I stopped using WordPress Stats for a while, hoping the problem would somehow work itself out, but when I re-activated the plugin, all that happened is that it started assigning all site visits to a different random post. Whoopee…

If someone at WordPress reads this, please let me know if it’s something I’m doing wrong, or if it’s something that you’ve got to work out on your end. I posted about this problem in the WordPress forums, but I have yet to receive a reply there.

Standard
How To

Run WordPress by itself or cached?

I’ve been running an experiment for the past three months. I wanted to see how well WordPress would do if I ran it by itself, without any sort of caching. So far, so good.

About four months ago, my web server kept getting pummelled into the ground almost daily, and I couldn’t figure out why it kept happening. After researching the issue, I found the prevailing opinion to side with the need for a caching plugin. People were complaining that it’s just not optimized well, and must be run with the aid of such a plugin, otherwise higher levels of traffic will bring the web server down. Trouble was, I already ran my WP install cached, using WP Super Cache, had been doing so for over a year, and my server still went down. (I should specify it had only recently started to go down.) What was I to do?

I posted a message in the WP forums asking why WordPress doesn’t generate static files. Were there any plans to do so in the future? To my surprise, Matt Mullenweg (WP’s founder) replied to my post, and told me that while there are caching plugins out there, WordPress.com doesn’t run any, and they’re doing just fine hosting millions of blogs. Others chimed in as well, and their replies got me to make the following changes:

  1. Made the switch to a VPS (Virtual Private Server) with SliceHost. Four months later, I’m still very happy about that move.
  2. Doubled the RAM on my web server (to 512MB from 256MB).
  3. Turned off WP Super Cache and started running my site by itself.

Each step followed the other in succession. I wanted to make gradual changes so I could see why my server kept having issues. Switching to a VPS host was good, and it was needed, but for my traffic levels, it wasn’t enough. Doubling the RAM was good and it was needed, and while the new RAM is enough for now, I’d still be having problems if I didn’t also disable my caching plugin.

Here’s where I think the crux of the caching/non-caching issue lies: it has to do with the load placed on the server as cached versions of the pages get created. Normally, that’s a non-issue. But as I monitored my server carefully, I discovered that it went down only as it started to get indexed heavily by search engines. Their bots visited my site in spurts, with traffic peaking, then falling back down. They spawned multiple threads, over ten at times, following links and slurping up the content. It’s when bot traffic peaked that an incredible load was placed on the web server. It kept generating cached versions of pages it hadn’t already cached, RAM and CPU demand increased to unsustainable levels, and it went down.

No amount of tweaking the Apache and MySQL config files helped with this sort of scenario, or at least it didn’t help me. You see, the difference between peak traffic levels with search engines vs. people is that people will go to a single article or a group of articles that are in demand. A caching plugin works great for those sorts of situations. There’s a limited number of pages to worry about caching, and those pages get served up time and time again. The load is acceptable. When a search engine bot starts indexing your site, it’ll call up any and all available pages that it can find. That can place a huge load on the web server as it scrambles to serve up those pages and build static versions for the caching plugin. I believe that it’s too much for most medium-sized servers to handle, and they will usually go down.

In my case, disabling the caching plugin and making sure no traces were left in the .htaccess file were the only things that helped. Now, I might have up to four different search engine bots crawling my site, each spawning multiple threads, and my server will usually not go down. Sure, there are times when the server will get dangerously low on RAM, and will be unresponsive for 5-10 minutes, but that’s an acceptable scenario for me. And if I should all of a sudden get huge amounts of people traffic to a post, it’s possible that the web server will also become unresponsive, at least for a time. But the great thing about running WordPress by itself is that Apache will usually take care of itself. As the requests die down, Apache will kill the extra threads, the available RAM will go back up again, and the server will recover nicely. That wasn’t possible while I ran the caching plugin. When it went down, it stayed down, and that was a problem.

I realize that what works for me may not work for others. I have not tested what happens with WP Super Cache on a larger server, for example one with more RAM. It’s possible that the larger amount of RAM there will offset the greater demand placed on the server as it builds static versions of the pages, although I’m not sure what to say about the CPU usage. That also peaked as the caching plugin went crazy. Not sure how that’ll work on a more powerful server.

WP Super Cache has some options that allow you to cache more pages and keep them cached for longer periods of time. Perhaps fiddling with those options would have allowed me to keep running the plugin, but I wanted to see how things stood from the other side of the fence. Like I said, so far, so good. Caveats aside, running WordPress by itself was the cure for my persistent web server outages.

Standard