Budget , Banker implementation in my DSP framework

[vladimir venediktov]

Hello developers,

I am designing budget controller in my DSP library .

I was thinking to make it simpler then in RTBkit.

I seems as all those credit/debit segregation and splitting balance into transactional buckets ( inFlight , allocatedOut , **increased , **decreased ) is really  unnecessary.

It seems as designers of RTBkit over complicated the issue .

The way transactions are stored DB style are:

amount | type-of-action | timestamp

 

this is how I see it in the audit table or in the log , but not embedded in a class. The class should have been

class AccountBudget {

Amount a;

AmountType at; // Begining balance, out, in , etc, etc

Timestamp ts;

};

But why this detailed information is kept in the RTBkit stack as type listed as finite number of variables of C++ class ?

I am trying to  finish my implementation by end of March and will share with anyone interested.

First of all , I want to simplify things and deduct from balance only on receiving Win notification . 

Here is my rational :  is out of all bids we submit the number of wins is incredibly small . 

Even if you are worried about over-trading , it's never going to be more then 1-2$ . 

Because those DSPs are bidding fairly small amounts and it takes 3-4 seconds max to get win notice back .

I don't see how huge overtrading can occur .

So I would not even bother tracking all intentions and therefore simply deduct amount from the balance when Win arrives.

 

It seems with this complex set up where you stop trading for 3-4 seconds when balance is exhausted due to outstanding bids is not needed ?

 

Let me know what you think .

Cheers,

Vlad.

[james....@blis.com]

I know nothing about how RTBKit does things, but anyone using your approach runs the risk of going bankrupt very quickly.

[Ian Davis]

You can't assume your win rate is constant. For example it may be low because you are competing against another DSP. When they stop bidding you might suddenly win every bid you make and overspend very quickly.

--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ian Trider]

Datacratic has some good articles on the topic of pacing and budget management:

http://datacratic.com/site/blog/rtb-pacing-everyone-doing-it-wrong

Otherwise, as others have said, this approach will not work.  It would work alright-ish in a simple world with very few bidder nodes, but that is not the world we live in. 

[vladimir venediktov]

I though in this business most important is CPA - the conversion rate , the point this article is going over
But having this sort of 'dead time' where we don't bid at all bothered us, so as soon as we spun up our own bidder we added options like "bid on X% of the request stream" and when we looked at the resulting data we noticed something really interesting: the impressions we were buying before were actually among the most expensive of the day!

Which means to me that even though DataCratic bidder was bidding without over-selling or under-selling it was winning the auctions more then any other DSP ?
I can see in the scenario when the bidder is bidding higher then every other bidder connected to exchange that over-sell is possible , but to me it points to
the problem with the bidder, so fix the problem with the bidder - its algo is broken.

For situations with over spending though , it's not so hard to have a thresh-hold when you slow down your pacing when reaching the thresh-hold below campaign balance , the pacing can be adjustable ( not fixed through out the day )
The bidding is done in micro dollars , so in the end even without some hard stop thresh-hold , DSP can loose 3-4$ on oversells.
I don't understand when DataCratic said clients are not happy when DSP oversells , yea if you charge them for oversell possibly not happy, I guess
the oversell has to be covered by DSP and I believe clients don't just give you $50 for one , the campaign goes for much longer time.
I also don't believe in situations described by James "only one - e.g my DSP is connected to exchange " ,  the exchange can't make anything with a single DSP business , right ?

There is a thing called probability in math , and I thought it applies rather better here then logical necessity for implementation to hold the transaction.
It reminds me of a time when we used bitmaps BMP uncompressed images and wasted so much bytes, JPEG is using idea that human eye can only detect
up to certain frequency , therefore those frequent changes in pixels were excluded - one can say wait a minute you just removed a lot of information .
Same applies to what humans hear , or see on TV ( up to 24 frames/sec ) , no need to broadcast 32 frames/sec.  if only 24 can be seen , unless we want to show it to your
pets.
Logically , I understand the idea behind transaction, when the transaction is really intended , but biding is an auction with low probability, the actual transaction occurs when you win the auction.

Thank you guys for taking time , I haven't decided yet , but your points are valid.

Vlad.

[james....@blis.com]

 > so fix the problem with the bidder - its algo is broken

Yes, but by the time you find out your algo is broken, or your model needs recalibration, you can be very deeply in the red.

> The bidding is done in micro dollars , so in the end even without some hard stop thresh-hold , DSP can loose 3-4$ on oversells.

That's a somewhat optimistic view.

Best of luck with what you're trying to do though, statistically it could work.

James