I’ve tried a handful of websites based on “tip with micropayments” in the past. They come and go. That’s fine. From a publisher perspective, it’s low-commitment. I’ve never earned a ton, but it was typically enough to be worth it.
Now Bruce has me trying Coil. It’s compelling to me for a couple reasons:
- The goal is to make it based on an actual web standard(!)
- Coil is nicely designed. It’s the service that readers actually subscribe to and a browser extension (for Chrome and Firefox) that pays publishers.
- The money ends up in a Stronghold account1. I don’t know much about those, but it was easy enough to set up and is also nicely designed.
- Everything is anonymous. I don’t have access to, know anything about, or store anything from the users who end up supporting the site with these micropayments.
- Even though everyone is anonymous, I can still do things for the supporters, like not show ads.
It’s a single tag on your site.
After signing up with Coil and having a Stronghold account, all you really need to do is put a <meta> tag in the <head> of your site. Here’s mine:
<meta name="monetization" content="$pay.stronghold.co/1a1b91b23306ab547228c43af27ac0f2411">Readers who have an active Coil subscription and are using the Coil browser extension will start sending micropayments to you, the publisher. Pretty cool.
Cash money
I’ve already made a dollar!
The big hope is that this becomes a decent source of revenue once this coerces a web standard and lots of users choose to do it. My guess is it’ll take years to get there if it does indeed become a winning player.
It’s interesting thinking about the global economy as well. A dollar to me isn’t the same as a dollar to everyone around the world. Less money goes a lot further in some parts of the world. This has the potential to unlock an income stream that perhaps things like advertising aren’t as good at accounting for. I hear people who work in advertising talking about “bad geos” which literally means geographic places where advertisers avoid sending ad dollars.
Reward users for being supporters
Like I mentioned, this is completely anonymous. You can’t exactly email people a free eBook or whatever for leaving a donation. But the browser itself can know if the current user is paying you or not.
It’s essentially like… user isn’t paying you:
document.monetization === undefinedUser might be paying you, oh wait, hold on a second:
document.monetization && document.monetization.state === 'pending'User is paying you:
document.monetization && document.monetization.state === 'started'You can do whatever you want with that. Perhaps you can generate a secure download link on the fly if you really wanted to do something like give away an eBook or do some “subscriber only” content or whatever.
Not showing ads to supporters
Ads are generally powered by JavaScript anyway. In the global JavaScript for this site, I literally already have a function called csstricks.getAds(); which kicks off the process. That allows me to wrap that function call in some logic in case there are situations I don’t even wanna bother kicking off the ad process, just like this.
if (showAdsLogic) {
csstricks.getAds();
}It’s slightly tricky though, as document.monetization.state === 'started' doesn’t just happen instantaneously. Fortunately, an event fires when that value changes:
if (document.monetization) {
document.monetization.addEventListener("monetizationstart", event => {
if (!document.monetization.state === "started") {
getAds();
}
});
} else {
getAds();
}And it can get a lot fancier: validating sessions, doing different things based on payment amounts, etc. Here’s a setup from their explainer:
if (document.monetization) {
document.monetization.addEventListener("monetizationstart", event => {
// User has an open payment stream
// Connect to backend to validate the session using the request id
const { paymentPointer, requestId } = event.detail;
if (!isValidSession(paymentPointer, requestId)) {
console.error("Invalid requestId for monetization");
showAdvertising();
}
});
document.monetization.addEventListener("monetizationprogress", event => {
// A payment has been received
// Connect to backend to validate the payment
const {
paymentPointer,
requestId,
amount,
assetCode,
assetScale
} = event.detail;
if (
isValidPayment(paymentPointer, requestId, amount, assetCode, assetScale)
) {
// Hide ads for a period based on amount received
suspendAdvertising(amount, assetCode, assetScale);
}
});
// Wait 30 seconds and then show ads if advertising is no longer suspended
setTimeout(maybeShowAdvertising, 30000);
} else {
showAdvertising();
}I’m finding the monetizationstart event takes a couple of seconds to fire, so it does take a while to figure out if a user is actively monetizing. A couple of seconds is quite a while to wait before starting to fetch ads, so I’m not entirely sure the best approach there. You might want to kick off the ad requests right away, then choose to inject them or not (or hide them or not) based on the results. Depending on how those ads are tracked, that might present false impressions or harm your click-through rate. Your mileage may vary.
How does the web standard stuff factor in?
Here’s the proposal. I can’t pretend to understand it all, but I would think the gist of it is that you wouldn’t need a browser extension at all, because the concept is baked into the browser. And you don’t need Coil either; it would be just one option among others.
1 I’m told more “wallets” are coming soon and that Stronghold won’t be the only option forever. ↩
Awesome
This seems like an interesting alternative for monetizing Web content which I’m gonna explore more (from the gamedev point of view) in the near future. The js13kGames competition partnered up with Coil for the brand new Web Monetization category.
Nice!
Did you try out Brave Rewards as well? It sounds very similar to Coil, but then baked into the Brave Browser.
The difference is that Coil pays real money (USD for now, but more wallets coming very soon). And we hope to make this an open web standard, so anyone can become a Payment Provider, not just Coil. We’re trying to bootstrap an ecosystem.
I was inspired to try out the Brave Rewards thing after this. I think I’m signed up correctly there as well. But Bruce is right, it only pays out in “BAT” which I guess is some cryptocurrency thingy specific to this. In about a month I guess it’ll autodeposit into some service I had to sign up for called Uphold. Upload looks like it’s USD, so I’m not sure if that conversation happens when it deposits there, or what?
You can connect your Brave Wallet to Uphold (uphold.com). I did not get to fully complete the connection to to uphold yet (still need to make a photo of my passport) but Uphold also pays out in real money. Maybe that is a solution? Anyway. I’d love the fact that Web Monetization is being considered. So I can see why you went with Coil!
It looks similar to https://contributor.google.com
It’s superficially similar. But it’s not limited to turning off ads. For example, in the Flood Escape game (https://flood.enclavegames.com/), web monetization subscribers begin the game with 100 extra coins, and the cooldown timer for the wheel of fortune is 5 minutes instead of 10. (See https://medium.com/js13kgames/web-monetization-new-category-this-year-e87bb1c998cd for more details.)
We hope to make this an open web standard, so anyone can become a Payment Provider, not just Coil. We’re trying to bootstrap an ecosystem. Any comments on the initial proposal would be very welcome! https://discourse.wicg.io/t/proposal-web-monetization-a-new-revenue-model-for-the-web/3785
I tried signing up for that too, just so I can kinda dip my toes into how everyone is trying it. I had to apply though, and haven’t heard back in several days now.
Thanks for an amazing post!
I’m a huge fan of Web Monetization standard and Interledger Protocol that powers it. I’m also friends with Coil team and have been building a new browser called Puma Browser to bring this technology to more people sooner :)
We recently launched on iOS so if you have an iPhone or iPad give us a spin and let me know what you think!
[0] https://www.pumabrowser.com
[1] https://apps.apple.com/us/app/puma-browser-monetize-the-web/id1456296154
Let’s count. A paying user (5$/month) with 100 h/month browsing budget spends 10 minutes on your site during a visit. It is approximately 0.01$ per visit or 10$ Page RPM.
It could be nice. However, The Coil will never publish the real statistics and we will never see the real numbers. You cannot see the performance numbers of your site. We do not have the knowledge of their algorithms. At the end, they can do what they want with the users money.
I would suggest you not only to switch off ads for the Coli users but also collect the total user time and compare with your Coil balance at the end.
I’m in the middle of working out how I want to hide ads based on monetization.
I’d rather delay grabbing the ad code (and any tracking that happens as a result) until after I’ve confirmed monetization isn’t happening, but that feels like it it would be annoying for users.
No ads, then after 5 seconds or so, pop!
Doing it the other way (showing first, the hiding) means the tracking has happened (and I feel this would be against most network’s t&cs)
The second I get a viable amount of revenue with this approach I’m just going to kill the ads.
Yep that’s where I’m getting stuck too. Despite the title of this blog post, the post just goes into a possible implementation, and I haven’t actually done it yet on this site for those reasons. The delay is just too long, but I’m not sure what an acceptable delay is. Advertising is important enough to me that I don’t want any delay at all, so maybe some kind of repeat visit cookie thing would be helpful. Feels like there is some technological solution to this.
You could set a cookie? Readers would see ads on the first page (the default). Check the cookie and hide the ads accordingly the next time they load a page.
That’s probably the ticket. And update the cookie as needed on each page load after monetization is figured out. Worst case, someone USED to monetize you and stopped, and they benefit from no-ads for one extra page view. Or they monetize you, and they see ads for the first page view.
Wonder if there’s anything we can do on the browser side to communicate to the site that it should expect the payment. Maybe part of the initial request that it’s coming from Puma Browser that specifies that you should expect to be paid directly vs. ads?
Daniel Aleksandersen: How Coil and Web Monetization works compared to Flattr
Thanks for sharing a link to my Flattr-comparison article, Chris Coyier! I hope it’s okay that I share another: How to make a vanity Payment Pointer for Web Monetization (reduces page-weight impact).