Possible native ads feature

[imwatsi]

Hi @roadscape,

I recently started investigating if a native ad system could be added to hivemind in a future update with minimal changes to core codebase.

This would augment the "promoted" post feature, giving developers more options and flexibility. For those who don't want to have a promoted section, but prefer more integrated/varied means to offer ad space.

I forked this repo and began working on /docs/native_ads/ to develop more detailed specs. It is still in pre-alpha and I was hoping to get your feedback.

The links are below:

• Native Ad System - Overview: https://github.com/imwatsi/hivemind/blob/master/docs/native_ads/native_ads.md

• Development Scope: https://github.com/imwatsi/hivemind/blob/master/docs/native_ads/dev_scope.md

• Idea origination: https://steemit.com/communities/@imwatsi/what-about-steem-s-utility-value-as-an-attention-token

[roadscape]

This is excellent.. thanks for starting the discussion.

A native post is structured just like an ordinary post in a community. The difference is that it is marked "sponsored" and it declines payout.

I like this idea.

Interactive polls give community members a chance to share their opinions on a certain topic/question as well as see what other community members think. These will differ from the normal polls that members can make in that they will be displayed on sections set aside for such polls, will be marked "sponsored" and will decline payout.

Are you suggesting hivemind implement polling or would this be handled via different service? What usage of sponsored polls do you envision?

Ads that don't get approved by moderation or that are cancelled by the creator should trigger a refund

Refunds are tricky on-chain, it may have to either work on trust, or use escrow.

And an idea I've been mulling over: promoted post could be a single top slot; the promoted post shown is picked at random among all current promoted posts, with the probability of being chosen proportional to promote cost. E.g. if there are two promoted posts, one for $10 and one for $90, the first would be shown on 10% of views.

[imwatsi]

Awesome. I'm glad you like the ideas.

[imwatsi]

Oops, fat finger mistake.

Overnight, I had time to think and the vision is getting clearer. I will write a comment to add more meat to the ideas.

I totally agree with the refund issue, it might have to be trust or escrow (as some do it now).

[imwatsi]

Your idea blew my mind. It's a neat gamification of the legacy promotion feature. The two options can offer different forms of exposure. Wow. I'll be mulling over that idea myself for a while.

[imwatsi]

I compiled this from my notes (it's quite long):

Okay, so the approach I have in mind uses a combination of JSON Metadata (posts) and Custom JSON operations.

e.g.

New operations: ad_submit, ad_approve, ad_revise, ad_reject

JSON Metadata:

   {
    "community" : "example_community",
    "ad_type": "native_ad",
    "ad_properties" : {"devices: "mobile_only"}
   }

Or....

{
    "community" : "example_community",
    "ad_type": "slideshow",
    "ad_properties" : {
                        "total_slides" : 3,
                        "slide_links" : ["https://...jpeg", "https://...jpeg", "https://...jpeg"],
                        "time_delay" : 5,
                        "devices" : "all"
                      }
}

So we only publish syntax/guidelines/technical documentation that devs should follow for compatibility with hivemind, but it's still flexible enough to add more ad types. Front-ends will access to this JSON data from DB so they can parse and display.

---

Another important aspect is that it will use a time based approach, where JSON Metadata (post) would be:

{
    "community" : "example_community",
    "ad_type": "native_ad",
    "ad_properties" : {
                       ...
                       ...
                       "start_date" : "1970-01-01T00:00:00"
                       "end_date" : "1970-01-01T00:30:00"
                       "duration" : 30 # minutes
                      }
}

From a time-based approach you get:

1):

• Per unit time measurement (minutes)
• price_per_unit = total_bids/total_minutes`
• total_bids because you can send more tokens to push your ad higher up review queue (more on this in 2) below)

Since each ad will have a price per unit:

• sort this descending, highest gets reviewed first
• filter views by dates/days and you get highest for that day, at that time
• max time units per ad e.g 12 hours (can be set by owner/moderator in community settings)
• max total time units (approved and active) e.g. 3 days (also customizable)
• the above prevents denial of service when demand is low, i.e. if someone tries to buy up the whole month or year. It gives newcomers a chance.

2):

The above enables the creation of two front-ends:

• moderator review interface, with ads sorted by price per unit time and segmented into days
• ad manager interface for people buying ads, where they see realtime stats on highest bid price for the day and remaining time slots. They can bid strategically to get ads reviewed and approved.

Another emergent benefit is that it will be easy for someone to check if an ad is being displayed in a community, at the set time and throughout purchased time span. It also makes planning for time sensitive ads possible.

DB will need a table for ads, with aggregated info like price per unit time and dates, and ad status. I'm still working out kinks in logic before writing any code.

Other ideas I'm working on include data integrity checks to avoid exceptions, checks and balances, and expanding data states seen by front-end developers.

[roadscape]

What's the ad_revise op? Might it be better for admins to reject an ad, then have the creator submit a new one?

[imwatsi]

Yes, that's a good point. Admin can issue ad_reject and advise a revision in notes.

Creator can then edit the post and issue another ad_submit op.

P.S. About your question on polls: I will work on a way to have polls as post types used in communities, so the same type can be leveraged for ads. Were you already working on a polls implementation?

Also, to avoid the refund issue, we can use ad_bid op for creators, so that ad space and time is allocated only after a valid payment (giving creator time to verify go-ahead). Bids can be changed/cancelled at will, leaving refunds only for rare cases like downtime. It'll be more of a customer service issue.

I'm updating the specs doc and dev_scope as I work, so you can get more details there.

[imwatsi]

Hi @roadscape

Could you help me get access to the communities beta? I would like to discuss Native Ads with the dev community. You can send credentials to [email protected]