Advertising and Blocking

Journalists online often make their money from advertising. And there have been a number of stories over the years about the damage of ad blocking. Seldom (never?) do you see the exact amount they make per view or per impression or however you want to measure how much money they make from me looking at their articles.

I read a bit of stuff from Ars Technica, and a rough count for the past month is at least looking at (which is admittedly different than reading) about 70 different URLs (some might be little more than photo galleries, so they aren’t all necessarily articles). They have two subscription options that would apparently supplant any money they would otherwise make off my visits if I saw their ads:

  1. $50 per year, which is about $4.17 per month.
  2. $5 per month.

Assuming the past month is my average viewing of their site, it would work out to between $0.0595 and $0.071 per URL, if I subscribed. The problem is that I don’t believe they make anything like ¢5 or ¢7 per view from advertising. If that were the model, that I actually paid them a nickel per URL, I would probably read less, at least until I got a handle on how much it was costing.

Loyalty is also a hard argument to make on the web, when I find my reading habits shift over time. If I have to go to each content site and manage subscriptions, figure out whether I want to give $5 to Ars Technica or $5 to some other site, that’s time I’d rather spend doing something else. Anything else.

But if they told me they make $0.007 per view (my completely blind guess), I might gladly pay $0.01 per URL (on average), especially if it were a cross-site system, and I doubt I read more than 100 articles per day. That is the micropayment model.

In other words, if sites like Ars Technica or Business Insider want to shift the model, they should get together and try to build the system that lets that happen. Because right now there’s a lot of difference to me between $0.49/month (the $0.007 ad rate), $0.71/month (if I paid a cent per article), and $5.00/month (if I paid their subscription rate).

Now, I’m sure their argument is that not everybody who reads will subscribe, so the $5 is designed to subsidize the freeloaders and still be low enough that people with modest incomes can afford it. The counter to that is that there are many articles I do not read from them. I would prefer to pay for the ones I actually read, to encourage the journalism I care about.

It’s the difference between paying for access to all the music from some record label and paying for specific albums by specific artists.

On the other hand, I do have my Ars whitelisted in my ad blocker. Edit 20150910: I have removed the whitelisting, as Ars Technica uses moving ads and Adobe Flash ads.


Source-agnostic Funding

You’ve probably heard of PayPal.  You might have heard of Flattr and Bitcoin.  Surely you’re aware of credit cards and checks.

As technology has become so common, we’ve seen only modest integration by the money transfer industry.  There’s not been enough movement toward better banking options and money transfer abilities.  The result of this is that, as with the problems caused by poor service authentication, we are held back both economically and culturally.

The idea I’m examining today is source-agnostic funding.

Let’s say you’ve signed up for a subscription, and that signup represents a recurring bill.  Every month you pay a fee, and the service continues.  For convenience, you attach a credit card to that service.  It’s automatically billed, until the card expires and a new one is issued.  Suddenly you have to go through a number of services to update your card details and continue automatic billing.

Instead of this system, what should happen is that you provide a service provider with a source-agnostic funding credential.  It’s like providing a credit card number, but you control what’s attached to it.  The service providers still bill it mostly like a credit card, and it still offers as much of a guarantee of payment as a credit card.

On the backend, you can change the source at any time and save yourself the trouble of having to update a bunch of payment details at a bunch of different services.

The interesting part about this idea is that it’s not new by any means.  Credit cards are the same idea, as is PayPal and Flattr.  But where the current solutions fail is that they just shift the problem a single step.  If you use credit cards instead of checks, then you can pay the credit card with a different source, but services that are relying on that card’s details will need to manually receive new data to process a different source.  If you use PayPal, you can change the source to pay a particular bill, but if a service doesn’t accept PayPal, then you have to switch to another similar service like Google Checkout.

What’s needed is not to perpetuate that problem: if you simply set up some new container and attach existing sources to it, it will only shift the problem again.

My guess is that the solution will turn on two things:

  1. An URN-like identifier for sources of funds.
  2. A tree-like structural requirement for URN-providing sources.

The URN-style identifier will allow for easy, unique reference to a source, and the tree structure will require and allow that any source could be attached to another, to build a tree of sources.  The tree requirement is essential, as cyclical source graphs would be problematic.