This post is more on the technical side. It's a follow-up to the previous development update, in which I shared the two classes of ad time that will be available: scheduled and unscheduled ads.
Here, I explain how I'm designing the features that concern the actual purchasing and allocation of ad space and ad time.
Since the project is still in pre-alpha, some minor changes may occur, when I start writing the code to push this project to a beta release.
I'm trying to create a free market for a community's attention, by monetizing space and time directly. This quest introduces a number of challenges. I identified a set of problems to solve and requirements to meet.
To deal with the above, I came up with a solution that uses a combination of JSON Metadata (posts) and Custom JSON operations. Data from both ad creators and moderators will be stored on the blockchain. Hivemind will maintain the states of the various ads and expose data sets that front-end developers can use to create efficient interfaces.
The most important aspect of this system is having s universal unit of measurement. To have a dynamic unit of measurement that adapts to changing demand, minutes are used as a unit of measurement. This results in a per unit-of-time price for an ad's bid.
price_per_unit_time = total_bid / total_minutes
For example, bidding $50 on an ad to be displayed for an hour, would result in a price_per_unit_time of ~ $0.83.
Using minutes to control the allocation of ad space and ad time has three effects:
Sortable bids (by value)
It's possible to calculate price_per_unit_time of bids no matter how long the ads want to be shown for or how much is willing to be spent. This can be used to sort ads by bid value, with the highest taking priority.
Public and verifiable market value
It helps determine real-time market value; people can actually see how much other people are willing to pay for ad time and ad space in a particular community
Self-regulation of market
The market will self-regulate. A person will adjust their time or budget on their own. So some will pay higher for certain time periods and some may choose to wait for lower rates, creating a responsive market that's sensitive to demand.
To be competitive and increase their ads' price_per_unit_time, ad creators can either increase their budget amount (tokens) or they can decrease the time units they want to reserve.
Bids made for an ad are treated as progressive commands, which means custom JSON commands are broadcast and saved that effect change on the amount of tokens an ad creator is willing to spend on their ad (budget) and how long they want their ad shown for (time units).
Community owners/managers will be able to set a number of attributes that affect the flow of ads in their community.
max_time_bid: maximum number of time units per purchasemax_time_active: maximum number of active time units per account (discourages time squatting)scheduled_ads_delay: minimum notice or advance period for placing a scheduled adscheduled_ads_timeout: how long a scheduled ad's time slot is reserved for, awaiting paymentPutting a maximum number of units a person can purchase in one go helps to avoid a denial of service attack and gives other people a chance to buy within a reasonable time frame. Community owners/managers will be able to set a maximum, for example six hours. In this case, you will only be able to purchase ads in six hour blocks.
How this works
Let's say there is low enough demand for a person to purchase an entire month of ad time, say for $50 worth of tokens. Without max_time_bid and max_time_active, this purchase would be made and even if demand picked up at any point in time during its campaign, those new ads would not get a chance to be shown. These two settings effectively rate-limit the creation of ads and allocation of ad space and ad time.
To cater for review and payment delays, scheduled_ads_delay gives both parties (moderators and ad creators) time to go through the ad submission and payment process. If the delay is set at two days, the scheduled ads can be set at a minimum notice of two days.
Without scheduled_ads_timeout an attacker could reserve a scheduled ad time slot and not pay the tokens, just to block other people from making ad placements. Ad creators should make payment for their scheduled ads within this time limit.
With these checks and balances, there will always be free time slots that people can bid for, with minimal disruptions due to bad actors. People who genuinely want to advertise for lengthy periods can do so by competing on a level playing field with other people who want the same ad space and time.
Knowing the definite time that your native ad is supposed to be shown makes it easy to verify. Extremely high show rates, delivered on time will help build confidence in the hosting front-end's implementations and intentions.
I'm working on more ways to incentivize high ad show rates and encourage responsible ad display practices, but at its least, this system is way more transparent than incumbent ad systems that just ask you to trust them on whether or not your ads are being shown.
The features mentioned in this post also allow for the creation of two user interfaces.
Moderators UI: moderator review interface, with ads sorted by price_per_unit_time and segmented into days
Ad Dashboard: ad manager interface for people buying ads, through which they can submit ads, manage the bidding process and see realtime stats on highest bid price for the day and remaining time slots. They can bid strategically to get ads reviewed and approved.
And that's all for this update!
Native Ads is a proposed future update to hivemind. For an overview of how it will work, read this doc.
If you would like to take a look at the code, visit the GitHub repo.