Auction theory – reverse auction example

As part of building next generation of adtech marketplaces i try and find & use as many different marketplaces as possible in other industries to see what lessons can be learned from the mechanics, and how it’s users behave. This time it’s home moving platform Anyvan!

 

AnyVan is a reverse auction platform allowing people who want things moved (buyers) to get the cheapest bids from people who can move them (seller/bidders).

 

I used it in my move to London placing a job which became a reverse auction, and had a good talk with the guy who won about how it works on the bidders side too.

 

In a reverse auction the roles of buyer and seller are reversed, and the clear price goes down with every bid. All bidders need to see the last bid price to know what they need to bid lower than.

 

FAVOR REVERSE AUCTION FAVOR STANDARD AUCTION
Many potential Publishers Few potential Publishers
Commodity or standardized product Specialized or custom product
Transactional prevalent relationships Long-term, strategic relationship is important
Excess Inventory Little or no excess Inventory
Price is the key selection criterion Other issues are as or more important than price

[ Perfect for Display not for Video? ]

The most common problem is each party being happy with the outcome. If the bidder makes a wrong assumption because there was not enough information from the buyer then she will be unhappy, if the buyer thinks the bidder knows what he’s buying but doesn’t honour the bid then they will be unhappy.

AnyVan solves this problem by forcing an exact job spec from the job poster (buyer), full transparency of every bids, each bidder, and with a slight risk to user privacy exposes all messages between a buyer and bidder to all the other bidders. This saves customer service acting as intermediary and creates a self informing auction. Bidders are scored by buyers to provide a self policing ecosystem.

adens-anyvanjob-dec-2015
[how my job went down]

The only thing it hides is the commission it charges. To users it’s fairly obvious because it’s the ‘deposit’ you make when accepting the winning bid. For bidders it’s not, they submit and see others bids without the commission applied. For me the winning bid total was £163, the deposit £40 , with the winner confirming he bid £123. So Anyvan’s commission was £40.

It’s a great example of how open transparency makes a vibrant marketplace with happy buyers, sellers and minimal overheads. With some polishing of the platform it could easily scale into other verticals or even to a Priceline model for travel & rentals.

How can this be applied to Adtech?

Reverse bidding is unlikely to happen anytime soon even for Display where there is a glut of inventory. Premium Publishers won’t get involved for fear of Advertisers using a lower bid price from a remnant Publisher to negotiate lower rates.

If however a DSP were to offer it’s own auction and invite Publishers to bid for their Ad spend then they would be swamped, albeit with remnant Ad networks.

[graphic here to demonstrate?]

Conclusion

The real lesson here is the importance of transparency which has always been missing in Adtech, limited by technology, publisher capabilities, fraud, and lack of incentives for the supply side to provide it.

The buy-side with its take it or leave it approach gives minimal information too, and big buyers like trading desks & large advertisers are only scored amongst publishers by rumours & backroom conversations amongst themselves.

Anyvan shows the kind of trust and vibrancy that can be created with a transparent marketplace. I for one am baking it into every product we build.

Read More

Video Ad Tech 2016 Predictions!

There’s a rising tide in Ad spend, upcoming US election, Rio Olympics, European football, users demanding more respect, and new wave of premium inventory coming through – it’s going to be a busy year! Here’s what I hope or expect will happen in video ad tech.

  1. Rise of Ad-Supported-VOD (AVOD) over Subscription-VOD (SVOD) like Netflix, Now TV & Amazon, and the BBC are there first offering people strong content for a monthly fee. There are however only so many subscription services people will pay for, probably 3 or 4- it’s a zero sum game. There are however many media companies about to jump in and translate their strong brand recognition and original content into online platforms and apps. The big opportunity is to have these Ad supported instead of subscription based to gain market share quickly.
  2. Video SSPs bought or white labeled. This year there’ll be publishers creating more video, and traditional TV media companies taking their brand recognition and viewer base online. They will want to take their current Ad spend deals and run them against their new online inventory. This will require either whitelabeling or buying to help them vertically integrate to the demand side, take out more of the middle men and create a stronger proposition. On the flip side, 2nd gen ssp/exchanges who started in Display and didn’t move fast enough to Video will face a tough year.
  3. Shakeout of DSPs – They act as the gateway to the market for advertisers. As advertisers bring this knowledge in-house the DSPs built & modelled for this will survive. Ones that can provide a real point of difference, and can make the account managers using them look good will do well. Ones that present no points of difference are in danger, especially older ones with expensive legacy infrastructure & heavy manpower overhead.
  4. Trading desks under pressure as route to market becomes further commoditised. Those without their own compelling Ad products will be swept away.
  5. Agencies surviving by innovating creative, and partnering with supply tech providers to enable new innovative ways of storytelling. VR giveaway as with New York Times gives a good example of how cheap IoT hardware will be combined with Ad spend to tell both the publisher and marketers stories.
  6. Push back on in-banner, especially on mobile. Publishers themselves are already red-lining it. It won’t go away entirely, but just as small flash players were auto paused in chrome, the HTML5 <video> element which is now being used for in-banner video, could quite easily be auto-paused too. This would force the in-banner guys to go the HTML5 canvas route where the video is spliced into frames and sent to the browser as one large long image creating sudo video Ads that look like gifs. Mobile browsers are likely to clamp down on this harder to protect users data plans, but better 3rd party validation tech will achieve the same thing.
  7. Thinning of margins for the middlemen on the open web. If the content creator gets a bigger cut then this is a great thing. There is of course the danger of walled gardens like Facebook double, triple & quadruple dipping on charges in their closed ecosystems with new tech elements in their end-to-end stack, meaning pubs who put their content in them could end up with less revenue, especially with lack of available competition.
  8. Blocking of interstitials by browsers. Chrome already has ad blocking built in blocking popups. Browsers will do the same with Interstitials, especially full page “high impact” ad units. Of course email signup ones will get caught in this too, but you won’t find a user who’ll be put out by that.
  9. Leveling off of Adblockers. You can analogise it to other popular apps that users download, like Google maps on iOS – incredibly useful but only has ~30% install base. Android ad blocking is a pain, as more impressions move to mobile and connected devices like chromecast, then the net will start to level off.
  10. Mobile video to continue to grow, still lower fill than desktop, but stronger on in-app inventory where it can be properly validated. Fraud on mobile is the big issue not being talked about enough. The process by some mobile SSP’s of taking a video ad and transcoding it into a gif like animation to get around iOS not allowing autoplay video, thus creating muted sudo in-banner video will come out into the open.

Read More

Smarter Coffee machine + Raspberry Pi = IoT coffeetime

smarter-coffee-raspberry-pi

The wifi coffee machine by smarter coffee is not a secure device. It can’t be allowed to connect to your main router, but it needs to be controlled by a group remotely …plus it’s fun to play around with right?

Solution:

Connect it to a satellite router with only a RaspberryPi for company. This satellite router can then be locked down to allow only these devices to connect. As no phones can be connected their iOS and Android apps can’t be used, so to make requests we’ll have the RaspberryPi make requests to the coffee machine instead. We can then call they by having Hubot on the Pi we can also have it connected to the office chatroom (hipchat or slack), or run a web server on it and have a secure REST API.

githubLink

You’ll need:

  • 1 Smarter Coffee machine (untested but might also work with iKettle 2.0)
  • 1 Raspberry Pi or Pi Zero
  • 1 Router – highly recommended to be a satellite off your main router

How to install, test and run it:

We’re going to create a project directory, clone the code into it, edit it for your network, and run it to test.

Open the terminal on your RaspberryPi or have it boot to command line.

$mkdir project-coffee

$cd project-coffee

$git clone https://github.com/AdenForshaw/smarter-coffee-api.git

Use Fing app or nmap to find the IP address of your coffee machine. e.g. 192.168.1.61

$cd smarter-coffee-api

$nano smarter-coffee-api.py

$change the IP address to you coffee machines

Now we’ll test it with the ‘reset’ command

$python smarter-coffee-api.py reset

If the machine lit up and says ‘reset’ then test complete!

If not then check the IP address, connections, and router settings.

Now set brew size/ strength/ brew type physically on the machine, and call the brew method –

$python smarter-coffee-api.py brew

Toast to your success!

bill-murry-coffee

Your hack is complete! What next?

Security: With any IoT device, hacked or not, you should do a security audit once its installed. In this case check the wifi router the project is on is locked down

Ai: You could store the date/time each brew method is called, then use this to predict when the next brew would be called!

Expand: You could expand on the basic API i’ve made in GitHub, and add more methods yourself, like brew size/ strength etc, and add it to the repo!

Team access: You could have a web server on the RaspPi, and have this project called as a REST API, or install Hubot and have it called from your team hipchat/slack/etc

Home automation: Create a smartthings device type and control it with your home automation switches, triggers or voice!

Whatever you do please let me know, i’m always interested!

Read More