Revisit "rate" (ability to compare ad vs WM revenue)

[sublimator]

Should there be support for specifying a rate?
Some sites may want more than 1e-9 (edit: arbitrary illustrative figure, not what providers currently pay) USD a second for their content.

[sbocconi]

I have the same question

[alexanderzatko]

Same question here (is it enough to "subscribe" to a github thread to show interest?).

[alexanderzatko]

There is this comment that seems to be relevant here, made by Stefan Thomas from Coil. It comes from an interview made in Sept. 2019:

Stefan: Note that the rhythm of the payment is not dictated by Web Monetization. A web site tells the browser where people can pay to, but not how much to pay or how often. It’s up to the browser and providers like Coil to figure out how to pay, and to give the user the best user experience. Suppose a newspaper site has articles that will unlock once you’ve paid $1. If a Coil user visits that site, we will try to make a determination: is it worth spending $1 of that user’s money in order for them not to see a paywall here? Obviously, if your budget is $5 you’re not going to get hundreds of dollars worth of content. Where providers like Coil will compete is on how intelligently we can spend the money and give the user the best possible experience for their money.

...and

Stefan: There are two ways to look at articles. You know how on some sites the site gives you an estimate of how long it will take to read the article? So the article loads right away, but you assume the user will spend a certain amount of time on that page, and thus the content provider could make a certain amount of revenue. In theory, you could even have the article load paragraph by paragraph as the user is streaming funds. Or, the site could unlock the article once a certain amount has been paid, which would incentivize providers like us to pay out that amount right away so the user doesn’t have to wait.

So my interpretation is that the information about a content cost to the consumer is implicit - the content creator will simply not show the content unless the payment he/she has in mind (and is likely stated somewhere on the page the content is in) is paid. In other words it is up to the Web Monetization agent to discover the cost.

If indeed this is going to be the answer to the question posed in this thread, then more questions come to mind. In particular, how would such a discovery algorithm look like? Would the agent issue first some small amount and go up if the content remained unlocked? How would the agent know when to stop (the content was unlocked)?

... looks like a lots of trouble that would go away if the concept of content cost existed in the spec.

[sharafian]

Glad that this topic is coming up here! It can be a little counter-intuitive, but there are reasons why Web Monetization doesn't allow the site to provide a rate.

Apologies in advance for this wall of text!

The core issue is that price negotiation is very different between autonomous agents than between people.

First imagine an ordinary checkout flow, with no WM or anything: If I go to the Wall Street Journal and want to read an article, they'll show me a paywall with a bunch of prices on it for their different products. Based on those prices I'll make a determination whether to buy access to the article/the Wall Street Journal.

I don't really know how much value the Wall Street Journal gives to me. But when they show me those prices I get a feeling whether it is or isn't worth my money. The prices that the WSJ presents are designed to make me pay as much as possible, manipulating my uncertainty over how much value I'm getting.

In Web Monetization, we're removing humans from the price negotiation process. With the small amounts paid, the value lost in the friction of a user interaction is greater than the value of the actual WM payments. So everything is done by an autonomous agent (the WM agent).

The WM agent's job is to pay for content but not to overpay. It should be using whatever signals it has to determine the value of the site. It may be loading some external data from the WM agent's servers, or it could be using local signals like time spent on the page, mouse movement, or any number of other things.

So the issue here is: Should we specify a way to signal 'price' (as stated by the site)?

We've reasoned that price just isn't a useful signal. A site with bad content can charge a high price and a site with good content can charge a low price. As discussed above, the price is really just a means to give hints to (or manipulate) a human user.

There's another theoretical use of price, which is to save money. If the price is higher than the WM agent's calculated value then the WM agent has the opportunity to save some money and pay nothing, because it knows no content will be unlocked.

The problem here is that it quickly becomes a game of cat and mouse. A site would never want their price to be less than the WM agent is willing to pay, because they're leaving money on the table. And they'll never want their price to be higher than the WM agent is willing to pay because they're also losing out on money. Even if the WM agent isn't paying enough to unlock their premium content the site still wants to capture whatever the WM agent is willing to pay.

That means the site will be adjusting their stated price to just try to hit the exact price the WM agent is willing to pay. The whole exercise is just lost value for the site and potentially a worse experience for the WM agent's user if the price is ever set artificially high in order to probe the WM agent's rate.

So in conclusion:

• Site-determined price isn't a useful signal for determining a site's value
• Site-determined price isn't useful for determining whether monetization will successfully unlock content

Let me know if you have any follow-up questions or disagree with anything here! I feel quite strongly about this issue but I don't want to close off any counterarguments

[alexanderzatko]

Thank you for the extensive reply - very useful.

We've reasoned that price just isn't a useful signal.

Is this idea based on some academic research? I am asking because price is THE signal in economics about value to both parties AFAIK.

But instead/in addition to citing such papers, could you maybe describe the content publisher's perspective on pricing in the WM context? I am assuming here the WM/IL creators must have taken their perspective into account - which is, to maximize earnings.

[justmoon]

Is this idea based on some academic research? I am asking because price is THE signal in economics about value to both parties AFAIK.

Yes, absolutely agree that price is an important signal.

Here is how I would explain why I don't think a price specification format should be part of the Web Monetization spec - apologies in advance for the lengthy response. I hope I'm making good enough points to make it worth your while.

First, let's recall: There is already the W3C Web Payments API which is widely implemented (and some of us also contributed to) so Web Monetization ideally should solve something that that API doesn't already solve. W3C Web Payments is basically a way for the website to ask the user to pay a certain amount. So when you're asking how to express a price then most likely what you should use is the Web Payments API. The website asks to be paid a certain amount and then the browser (typically with user approval) pays that amount.

Btw. if what you like about Web Monetization is the fact that payments are happening over the open Interledger network instead of credit cards and the-like, there is work being done to build the necessary pieces to have Interledger-based Web Payments.

So what is Web Monetization for if not that? The idea is to have a declarative API that is more flexible than the imperative "ask browser to pay" API of Web Payments.

That is useful for things like discretionary payments/tips. E.g. the user wants to tip this website $1. If the website has a Web Monetization tag, the user can just pay $1 to that wallet without the site having to request it which would then require the site having some widget where the user can enter a tip amount etc. It's easy to see that pricing doesn't really help for the tipping use case since the user can tip however much they want anyway. I can also tip a fixed amount every month like Patreon. If I am logged in to the website, the site can give me a payment pointer that is unique to me and they can give me benefits for my monthly support like on Patreon. But as soon as those benefits stop being "I thank you for your support" and they start being "I'm selling you this content for a monthly fee", I think Web Payments is a better fit for that.

WM is also useful for passive payments. This could be the kind of end-of-month compensation like what Brave does, i.e. track which sites you visit and at the end of each month send some money to all of them. Again, a declarative API is very nice for that, because you can just keep track of all the payment pointers and then pay them at the end of the month. Pricing doesn't help this use case because there is no quid-pro-quo and the user can pay whatever they want or nothing at all anyway.

And it can also be used for the sort of ambient monetization like what Coil does. In this use case, the user pays the site some money in real-time and the website might give the user some benefit as a result. This is the use case where pricing often comes up as being useful. You tell the user how much they need to pay to get a certain level of benefit. So let's look more deeply at this specific use case.

Basically, we want to communicate to the browser something like: "If you pay $0.15/minute, this site will turn off ads. If you pay at least $2 total, you'll get some cool bonus content. If you pay a cumulative $5 over the last 30 days (daily sliding window), we will give you access to our custom icon designer tool."

Maybe you can tell that this could get pretty complicated. Expressing the amount, required payment schedule, and what the benefits are all rather non-trivial. Even if we only cared about the very limited "Coil v0.1 model" of paying a certain amount per second, describing the benefits is still quite complex. And what good is the price without knowing what you get for it?

Another way to look at it is like this - which is similar to what Ben mentioned: The "ambient monetization" case by definition does not involve user interaction. If there is no user interaction, who looks at the price? I guess it would be the Coil extension or some such. But that's an automated system. So if I was the website, I would have a farm of servers each presenting the Coil extension with a different price and then figure out given which stated price the Coil extension pays the most money. And then I'd use that price. So why even go through that charade? All sites want to be paid the maximum they can get. It may well be useful for the site to provide some meta-data on what they provide which providers like Coil can analyze and use as a signal as you rightly point out but that format will have to be a) relatively complicated compared to Web Monetization and/or b) scoped much more narrowly than Web Monetization. I'm not against having such a format for expressing prices. I just think it should be a separate standard (or standards) because it would significantly complicate and unnecessarily narrow the scope and flexibility of Web Monetization.

One more note: Suppose we did define such a format. Would Coil use it? Yes, but we probably would not trust it. For instance, if a website had a tag that said: "We will turn off ads if you pay us $0.05/minute", we would still have a server farm where we try paying them $0.04, $0.03, $0.02, etc. and then pick the lowest amount that turns off ads 99.99% of the time. So the pricing data would be used to seed our first guess but it otherwise wouldn't impact much at all. We also wouldn't trust the benefits information either. A website might say it turns off ads but not actually do it. Or do it but still have trackers. Etc.

To summarize:

• Many (most?) use cases for Web Monetization would not benefit from pricing data at all like tipping
• The ones that do would each require a different format (minimum payment per second, minimum monthly payment, minimum cumulative payment, etc.)
• Pricing information is pretty much useless without data on what you get for it (benefits) and expressing benefits is vague and hard to standardize. (What does "ad-free" mean? Where does "bonus content" stop and "premium content" begin? ...)
• Even if you had pricing data, you would probably want to verify it anyways.
• For many use cases where people want pricing metadata for Web Monetization ("you pay me this, I give you that"), they should probably be using Web Payments instead.
• For these reasons, it's not worth adding it to the main standard imho but I would be open to investigating a separate pricing metadata standard/microformat that providers like Coil can use as a signal.

[alexanderzatko]

This clears a lot. In particular, where the WM proposal falls on the monetization spectrum - I would recommend to add this info on the Getting started page, or emphasize it, in case I missed it while reading*.

If I read it correctly, it makes most sense for sites that publish content without a firm price set, but want to provide consumers with an easy way to send a reward, if they wish to do so. I can see how WM might increase efficiency for this use case. A related question comes to mind, about what percentage of visitors would voluntarily pay for such content and how much, but that is a different discussion.

A more interesting is "ambient monetization" where a site might offer various access/services levels depending on the payment amount/frequency. It is not clear to me whether the WM proposal is attempting to cover also that scenario and if so, how would an WM agent behave in this case - assuming that it does not have information about the pricing scheme.

• maybe also including a link to this forum would be helpful. It took me a while to find it.

[sharafian]

It is not clear to me whether the WM proposal is attempting to cover also that scenario and if so, how would an WM agent behave in this case - assuming that it does not have information about the pricing scheme.

The way we tend to approach these complex interactions is by trying to make them a competitive edge, specifying as little as possible in the spec. We might not know the best answer now but if the WM ecosystem is set up so that an agent who can find the best benefit-to-price ratio is more successful, the ecosystem can approach better and better solutions.

Stefan described some possible solutions (like having a server farm that visits sites and tries to determine which are giving content at which price points) and it's also possible to do things more manually or have a really flat pricing structure. As the ecosystem evolves we'll get better validation on which of these work best

[sublimator]

so it's kinda a lucky dip ?

[sublimator]

@BobWay might have some interesting thoughts here

[sbocconi]

I am very interested in the tipping and end-of-month compensation use cases that @justmoon mentioned, I assume the privacy of the "donor" is preserved also in case of end-of-the month payments, right?

And how would a website possibly display "thank you for your support" content, since this would need to happen at a the next visit after a donation? The website would need to keep track of the sessionIds of payments or something like that?

[sharafian]

I am very interested in the tipping and end-of-month compensation use cases that @justmoon mentioned, I assume the privacy of the "donor" is preserved also in case of end-of-the month payments, right?

Yeah, the donor's identity is hidden from the site because the WM provider just doesn't send it (and the payment doesn't have any unique ID that could be tied back to the user or used to track them)

And how would a website possibly display "thank you for your support" content, since this would need to happen at a the next visit after a donation? The website would need to keep track of the sessionIds of payments or something like that?

It's tricky because you don't know whether the user is actually going to pay until the end of the month. If it's literally just a thank-you message there's not much to worry about, but I'd assume sites don't want to give away most exclusive content for free

The best thing we've come up with so far is 'per-provider accounting' where a site would look at payments made from a WM provider as a whole to determine whether it's profitable to serve content to that provider's members.

Imagine you have a provider called "WM provider A" which pays at the end of the month. And imagine users of WM provider A can give a token to the sites they visit in order to prove they're users of WM provider A.

A site can get a good idea of how much WM provider A pays by looking at their payments over time and content consumed by their users. They can make a calculation like 'we get average $0.05 per piece of content served to users of provider A.'

This means that without having to manually come up with a business agreement with every provider, sites could serve content to web monetized users without needing immediate payment. It's basically a really simple way of building trust with WM providers automatically (and each site can choose their algorithm for determining whether a provider is paying enough).

LMK if you have further questions, we've discussed this "per-provider accounting" issue on other issues but for some reason I can't find a thread dedicated to it specifically. Might be worth creating a separate topic for this.

[sbocconi]

Thanks for your reply @sharafian.
I guess the user agent could present websites with kind of "receipts" of payment? Or is this breaking some architectural principles of WM?

[sublimator]

@sbocconi

There is actually a "receipts" feature getting added to WM.
Check the PR list :)

[marcoscaceres]

We might want to add a note around in the spec. I think a lot of people will have this question(s)...

[marcoscaceres]

@sbocconi wrote:

I guess the user agent could present websites with kind of "receipts" of payment?

That is correct.

Or is this breaking some architectural principles of WM?

No, certainly not. The receipts are verifiable.

[sublimator]

This should probably be revisited, as people need to be able to make revenue comparisons between ads and WM. It would probably mean moving to a more WM "Copilot" UX as opposed to the current completely automated WM Agent.