A common question that we get about Web Monetization is “how do I share a portion of my revenue?” It’s an important question: more often than not, the creation of high quality content involves more than one person.
Web Monetization is a pretty flexible system, so there’s several ways you can do revenue sharing:
One way to do revenue sharing is at the Interledger layer. You can run some software that hooks into the same Interledger network as your wallet, and it splits the streams of incoming money into multiple outgoing streams. Even for an advanced user, this can be hard to set up.
Another way to do revenue sharing would be to add support for multiple monetization tags on one page. But sending to a lot of payment pointers at once would cause performance issues, and the Web Monetization standard would also get more complicated. We need a solution that is performant and simple.
A particularly interesting alternative, and the topic of this article, is probabilistic revenue sharing. The name sounds a little intimidating but it’s actually pretty easy to understand and use.
Edit: We've now created a probabilistic revenue sharing tool on webmonetization.org that you can try out right away!
Probability-based payments have been proposed many times for many purposes. For instance, this 1997 paper by Ron Rivest uses the concept of expected value to implement a micropayment scheme. The probabilistic revenue sharing we discuss in this article is inspired by these ideas, and applies them to the problem of revenue sharing in Web Monetization.
In Web Monetization, probabilistic revenue sharing works by having a random choice every time a Web Monetized visitor loads your page.
You have several possible payment pointers, each with a different chance of getting chosen. The visitor pays to the chosen pointer until the page is reloaded or closed.
If Alice’s payment pointer has a 50% chance of getting chosen, then ~50% of the Web Monetized visitors will be paying to Alice. Because our random choice is not correlated to other variables like the length of time the visitor spends on the page, the amount of money per-second you make off the visitor, and so on, the laws of probability say that Alice’s share will approach 50% of the page’s total revenue as more users visit the site.
This gives us a straightforward rule: The chance of choosing somebody’s payment pointer is equal to their expected share of the revenue.
This snippet of code chooses a payment pointer randomly every time somebody loads your page. You can replace the pointers at the top with your own, and modify the weights to whatever you want. Then put it in a script tag in your site’s head.
Here’s a live demo using Glitch that shows how the random choices will approach the correct percentages over enough tries. You can customize the number of times to randomly choose a pointer and it will show you the results:
Imagine that I have a blog post and I’m embedding an image into it. The creator of the image has said “If you want to include my image, just give me a percent of your article’s earnings.” So that’s fine, you add the image’s creator to your revshare.
But what if the photographer were also sharing their revenue? Then you would have to include everyone in the photographer’s revshare into your revshare, but with a scaled-down percentage. And you’d have to keep updating your revshare if the photographer’s changes. That’s a huge pain!
The idea is really similar to the vanity payment pointers in this article by ctrl.blog. A vanity payment pointer is a redirect to your actual payment pointer. If we want to make this do a probabilistic revshare, we need to make that redirect random instead of redirecting to the same pointer each time.
You can pick several payment pointers and a chance for each of them to be chosen, just like the example from earlier. The chance that you redirect to each pointer is equal to that pointer’s expected share of the revenue.
Here’s an example of how you can implement this in an Express.js server. It uses the same code as our previous snippet to implement the pickPointer function. We plan on offering a hosted tool that lets you manage revenue sharing payment pointers without writing code in the near future!
The cool thing about this scheme is that your payment pointer contains all the revenue sharing logic and you don’t need to repeat that information on every page.
This also means that it works recursively. One of the pointers that my vanity pointer randomly chooses could go on to make a random choice of its own. 1% of the time my blog could choose the photographer’s pointer and then 10% of the time the photographer’s pointer chooses the photo editor’s pointer.
This lets you make some revenue sharing schemes that would be wildly impractical with existing revenue sharing schemes. By taking the pain out of revenue sharing, we can help everyone get compensated fairly!