In app Advertising for content creators

[tiger5226]

Problem Statement

Content publishers fall into one of 2 categories, Those with Paid Content and Supported Content. This proposal focuses on those content publishers with supported content (the majority). Currently, those content publishers who enjoy using LBRY and generally like the idea of LBRY are forced to make a selfish call. Much of their content is ad supported. So they must continue to push their viewers to platforms like youtube where they can earn $$ for their work. By solving this problem, we are taking away this decision.

By providing an earning mechanism outside of individual support we do two things.

The first is we allow the content publisher to bypass the "Youtube Cut". Owning such a large % of the market for advertising, we can safely assume they take a big cut. Gaining a larger % of the advertising earnings for their content is a huge win in the perception.

The second is we are allowing content creators to not be as tied to sites like youtube. This means they themselves will be able to push traffic to LBRY. If they earn more on LBRY than Youtube, the majority will promote LBRY over Youtube out of their own self interest.

There is no competitive decentralized advertising mechanism that can woo content publishers that don't charge for content. Building something out(ad network) ourselves would be monumental. We need a near-term solution to this problem that can potentially be implemented quickly.

This proposal ventures out to find an ad-supported option for LBRY content publishers.

Requirements

• It should be a 3rd party service
• It must be self service and automated for content publishers
• LBRY Inc should not be responsible for the advertising ( for now )
• Easy integration into our current app and claim structure
• It would be nice to allow for LBC to be leveraged to an extent where possible

Questions

• What service should we use? Is OneByAOL the only viable option?
• What biz dev opportunities exist to leverage?
• How can we maximize the impact of such a game changer? Advertising this feature, news feeds, etc.

Owner

@tiger5226

[tiger5226]

Proposed Solution

OneByAOL has recently release a product, with easy integration. This makes the problem above solvable.

The OneByAOL solution allows for content creators to offer advertising for their content via a self service portal. The service allows individuals to create accounts and obtain an APID. This APID is what uniquely identifies a content creator and directs revenue appropriately.

The development kit is a great advancement in video based advertising.

window.mmAPI.placeAd({
        containerElementId: "adContainer",
        apid: "<YOUR_APID>",
        placementType: "interstitial",
        allowLocation: true
    });

This allows LBRY to include generic code in our claim landing page. So how do we get this linked to the content creator without LBRY involvement.

We add an APID field to the claim meta data. This field is read for each claim and the APID is inserted above dynamically for the specific claim.

This means that a content creator can sign up with OneByAOL, get an APID, set it on their claims, and what the ad revenue come in on their own account without LBRY involvement.

The main pushback I can think of, is that we are sidestepping lbry credits as an economic mechanism that is fundamental to the ecosystem. I would disagree. Having multiple means to an end is complimentary not adversarial. Adding this sort of mechanism, brings legitimacy for many of the lbry platform. This legitimacy, by association, brings legitimacy to lbry credits. There will always be paid content and supported content.

In the end something like this enables us to ramp up usage, with little effort, while still being able to devote efforts to scalability and usability.

[tiger5226]

Looked into some additional options that offer SDKs:

https://www.inmobi.com/sdk/ - They offer iOS and Android https://developers.mopub.com/docs/ui/quick-start/ - They offer iOS and Android https://dev.getpolymorph.com/docs/renderjs-v2-integration - They offer Web, iOS, Android

The barriers to entry are the traffic requirements. Many publisher platforms require certain levels of traffic. This limits the number of agencies we can work with.

[BrannonKing]

Ideal advertising is mixed into the content and relevant for the content viewer. Incorporating 3rd-party advertisement archives into our product is not the only solution, and that would make a mess of the site and the content. Suppose instead that we add 1st-class support for advertisers. They are essentially the same as a publisher. We just add an additional option to offer payment to other publishers that include our (the advertiser's) content. Example: publisher A agrees with publisher B to include a 15sec clip from B in the middle of A's movies. Now, when I buy a movie from publisher A, it shows that advertisement in the middle. (Since I own the file I could edit out that clip, but I would probably be exposed to the ad at least once.) We would want to point out the agreement on the website so that people are not surprised when they come across an advertisement.

[tzarebczan]

Someone on discord suggested https://www.adbutler.com/developers.spark also.

Reposting my question from our other discussion: "With a proper proof of purchase mechanism in place, wouldn't this require the advertiser to pay LBC to the creator in order to purchase the content? I'm sure there are ways around this, i.e. storing a key to decrypt it on a separate claim."

[kauffj]

@tzarebczan it's possible that implementation-wise, if not user-experience-wise, that they're fully decoupled. Theoretically, as an advertiser, I care that someone watched my ad and what I paid for that person to do so. I don't particularly care that they continue to watch a particular video, do I?

(There are lots of other designs and I'm not pushing for the above, but it's a thought.)

[tiger5226]

AdButler is a great way for us to service 1st class ad network support. However, what this is doing for us is enabling us to start our own ad network. This does not give us advertisers. Ideally we are able to jump on the bandwagon and get advertisers fast.

Maybe a good solution here is to offer both. So we get 3rd party advertising setup and running so content creators can set it up fast and start earning.

Then in the background we start building out a tool like ad butler. There is a bit of work there if we want it to be decentralized. Ad Butler is very centralized and LBRY Inc would be the money transfer agent even if we were exchanging LBC. The harder part though is reengineering that solution to be decentralized so we are not "in charge" of it. Then again, advertising is a potential revenue stream for LBRY Inc helping us to further our product development long term.

I would still like to create a OneByAOL POC. I think I could get that up and running in a week or two, produce a video, and get community feedback. then once in place we can start on an adbutler like solution for an ad network that is entirely LBC based.

[lyoshenka]

@tiger5226 whats the next step for this?

[tiger5226]

https://github.com/lbryio/internal-issues/issues/242#issuecomment-468948055 This is the last update on the big topic. I had a meeting with the ad butler people and they can make minor changes for us no problem. They do it for a number of customers.

Also it was iced by @kauffj @finer9 for now

However, to answer your question, the next step is to make a decision between 1st class support or 3rd party support. Personally given that something like ad butler has 90% of what we need already, we should probably just go the 1st class support route.