Skip ⬇

Revenue Models for the Web

Facilitator: Ali Spivak, Adrian Hope-Bailie

Minutes (including discussions that were not audio-recorded)

Previous: Memory copies & zero-copy operations on the Web All breakouts Next: WebID, a federated SignIn API

Skip ⬇

Skip ⬇

Transcript

Okay, so thanks everyone for joining.

I appreciate you coming to talk about revenue models for the web.

As I mentioned earlier, my name's Adrian Bailey.

I'm from Coil.

I'm a AC rep and also co-chair the payments working group.

Coil is a San Francisco based company.

I'm in Cape town with a small team of us based here.

And our mission is to build a sustainable human friendly business model for the web.

So how do we find a business model for the web that is a little bit different to the advertising model that we have today this harmful potentially to users, and addresses the needs of the long tail of creators and shares the revenue available to be earned for content and services and the web more equitably amongst the people who build on the web?

The problem we have today is that, you know, the majority of content services are are monetized by advertising, but in, a large proportion of web users today are actually blocking ads.

Number continues to grow, and we're looking for alternative ways that people who are building on the web can monetize what they do.

We've seen you know, great solutions in for example, app platforms, and we're trying to bring something similar to that into the web.

Our proposed solution, which we have are working on through the web incubator community group is a standard called Web Monetization.

It's a declarative API that websites can use to declare how they can be supported.

So declare the address of an account where they can accept payments.

Websites provide that address you know, in a link tag, we're in the process of migrating from using a meta tag which was our original proposal, and then browsers who find one of these tags in our site, can stream, you know, very low value payments to the site, either as the users visiting the site, or users could explicitly instruct the browser to send payments.

So tips donations for, you know explicit tips or purchases or whatever the case may be.

So a very simple for browsers to implement, sorry, very simple for websites to implement to get started from.

In addition to the declarative aspect of the API, there is an imperative side which websites can exploit to make the payments interactive.

So rather than just having an account, that's sitting receiving money and hoping that users will make donations or payments out of the goodness of their hearts, browsers can actually update the way their services are delivered based on those payments.

So they add an event listener and they receive these progress events every time they receive a payment, and, you know, as payments come in, they can do things like, you know, providing access to exclusive content or you know, just providing some sort of interactive experience for the user that makes users feel like their contribution to the site is appreciated.

And lot of detail on the standard itself, the API, there is tools that have been built around the API available on webmonetization.org.

So if, you know, first one, I look at more detail there, that's very high level of how it works and very interested to hear some of the other ideas that people in the room today have for monetization.

That's me, thanks very much.

Allie Thanks Adrian, I guess Danielle and P Jade.

I know you had prepared like a quick overview of some of the things you're working on and thinking about if you want to take over from here.

Alright?

Hey everyone, my name's Danielle I'm from Chrome and here's PJ.

He's going to, okay good.

So PJ, do you want to give our statement?

Thanks.

Be more than happy to give me just a moment here and present myself at it.

(typing) Okay.

I'm gonna be introducing the digital goods API, as a background for what we're trying to do here.

For payments API, we see the challenge being that the current payments APIs are complex because they're generalizing all the problems.

We're wondering, how can we create a simple method for online monetization that serves the more specialized needs of payments for digital goods and in so doing allow more merchants to participate in revenues.

Additional aspect of this problem is, there's more types of payment virus in this case.

So there's beyond just sort of banks and the more typical payment acquirers that you might see for generic goods.

We also have some specialized acquirers in a form of app store.

So we designed something that would support both cases of someone who's setting up digital codes for example, and a catalog on their own personal website but would like to use a simpler API to facilitate the payments of those goods, let's imagine a private software vendor who has you know, maybe two or three SKUs or a dozen different softwares to use, and they would like to use you know, kind of generic acquirer, but they would also like to use a very similar API perhaps on the open web if we were to enable open web store ecosystem for, through, you know, a traditional acquirer that chooses to implement the backhands for the API as well.

So the interactive adherence to the digital goods API which you'd like to discuss today, this is generalizing digital goods specific cases, making it more to trivial for payment acquirers, official goods as well as for the merchants who have digital goods.

Just a couple of things that differentiate this API from current payment KPIs.

The first is a simplification of features for the use case.

So for example, no shipping, no shipping, no gift wrapping, et cetera.

And second, we're taking a more SKU/inventory-centric work to you rather than a price you used.

For example, in a typical payments API, the focus is not on what inventory specifically is being purchased, but what is the sum total of that inventory?

And then of course like you know, taxes and other kind of shifting and other kinds of additional costs that are involved in a transaction.

In a case of digital goods, the focuses were around, which SKU is it?

And the backend has some awareness of this.

That's all looked forward to the discussion.

Thank you PJ.

I hope everybody could could hear, I know it was a little crackly a bit Pete, I think you had said something that on this, on brave, I saw you here.

Nope.

No.

All right.

We might have was say we might've lost Pete.

I thought I, I saw Brian is on, if you did have anything prepared that you wanted to share.

Nope.

I agree with Toby, I do hear purring cat.

That's me.

I'm sorry.

(laughs) I have a choice.

I can either have a purring cat in my lap or a screaming cat at the door.

So we've got a purring cat.

Okay.

Is there anyone else who has any other super pay statements with hosts they wanna share with us before we kick off?

Yeah.

I don't know if we had Marcos or David wanted to talk about any of the things they're working on or thinking about?

Okay.

I'm just listening if you're referring to me. (laughs) Okay, then.

Sorry, PJ, by the way, you're still screen-sharing just so you know.

Cool.

So that's, I mean, the those are the two proposed APIs that are out there at the moment for revenue generation on the web.

Allie, do you have any other models specifically, you thought we should cover today?

I mean we, we did say in the prep that we'd be interested to hear from folks who about the advertising model as well, whether there's still a place for ads or whether, you know, just better ad based revenue.

There's also a solution we believe it should be looking at.

If we've managed to get anyone in from the, the advertising position group, Wendy I think you're involved in that work and don't know if there's anything you wanna add from that side as well.