Can I change price granularity in prebid header auction as per our need ? Prebid has the following price granularity- Low, Medium, High, Dense, Custom. I want to know if I set my DFP line items in a way where I will have a flexibility to use Price Granularity according to my preferences so that when required I can use low and when required medium or high. But I don't want to make changes to our DFP line items for that every time.
Can this be achieved ?
I've created DFP line items already in a increments of $0.05 like 0.05, 0.10, 0.15, 0.20, 0.25, 0.30 .... so on.
I want to understand for example if I set the line items at 0.05 increments capped at $20.00 then let's say if price granularity is set "low" then the increments will happen at 0.05 while in "medium" may be 0.10 increments. While I don't want to change DFP line item values every time I wish to change price granularity.
Also, please suggest, if we get $20 and above CPM, then how will we get it because prebid wil automatically round off and reduce the highest cpm to $20 bid.
You can use multiple price granularities if you wish, as long as your line items have price buckets to match at the most granular level. For example, if you are using "medium" granularity and setup line items at $0.10 increments, switching to a "high" granularity ($0.01) would cause you to lose bids at those bids that didn't land exactly on a $0.10 increment (i.e. $1.17, $1.23 etc). However, switching to a lower granularity (ie "low") would be fine.
Related links:
http://prebid.org/adops/before-you-start.html#decide-on-price-bucket-granularity
http://prebid.org/dev-docs/common-issues.html#price-granularity-mismatch
http://prebid.org/dev-docs/publisher-api-reference.html#setConfig-Price-Granularity
Related
I've got a few products where I need the quantities for a specific product to start at a number, 240 for example and then the customer can select in intervals of 240, and for a different product, say 100 units. I need a way to separate a list of quantities for separate products.
You can examine the documentation related to InventoryItem endpoints which leads to InventoryLevel endpoints. Once you get a handle on Locations, you are free to set inventory levels. Note that setting explicit amounts is no longer the fashion, instead you ask how much is there, and then modify that amount with a delta change.
So if you ask for a product's variant level, and it tells you the current availability is 0, your delta might be +240.
I am currently trying to run a simulation in SQL, the query is to monitor cost against a pre-defined target.
The amount being monitored is a 91 day moving average cost so this uses a correlated sub query to get the correct amount, but on days when the performance target is breached, the amount is adjusted to the target. (if moving average is 110, the monitor for this day from next day forward will take 100 instead of 110 as the payment would have been reduced on this day.)
Example, want to measure on what days costs breach a target of say 100, the costs are monitored on a 91 day moving average. When the target is breached there is a reduction in payment and the amount included in the monitor is adjusted to the target. I have been able to implement this but now I need to adjust for 91 days moving instead of the beginning of the time period. This would be possible if I could have 2 recursive queries but I don't believe this is possible. I have also tried various joining methods but they all become circular.
Any suggested approach would be greatly appreciated.
I'm new to optaplanner and im trying to tweak the VRP example to solve a "similar" problem... but with some differences:
We have a central depot, n customers and a fleet of one or more vehicles.
Each customer has a certain "maximum capacity" (not the same for all of them).
Same for each vehicle.
Initial conditions from the problem include:
"actual capacity" and "desired capacity" for each customer, so that:
actual capacity is >=0 and <=max capacity
desired capacity is >=0 and <=max capacity
"actual depot capacity" is the amount of items available at the depot
We want to REDISTRIBUTE some items so that each customer gets his "desired capacity".
(Tipically most items will be redistributed from one customer to another)
Hard constraints are "maximum capacity"s cannot be excedeed
Soft constraints are vehicle distance (minimize) and difference from "desired capacity" (minimize)
I started by generating a data file for the VRP example with negative customer demand (to simulate desired capacity < actual capacity) but quickly discover that constraint in drl that sums up all customers demands to satisfy vehicle capacity restriction is not what we need here.
¿Do you think that this problem is "similar enough" to worth modifying VRP example?
Yes, it's definitely worth taking the OptaPlanner VRP example (with or without the example GUI) and customizing it to these needs. Start from OptaPlanner 6.0.0.CR1 or better yet CR4 which will be released next week normally. Don't use CR3 because it might have a bug related to shadow variables in VRP.
A) Let's presume customerDemand = customerDesired - customerActual. This can be positive (need more items) and negative (need to get rid of items).
Question: How do we validate the Vehicle capacity? We can't just sum it, because it fluctuates from customer to customer. Answer: We use a shadow variable (let's call it freight) on Customer to calculate how many items the vehicle is transporting from the previous customer to the current. This is very similar to how arrivalTime works for the TimewindowedCustomer example. Then use a score constraint rule to verify freight on every customer is lower than the vehicle's maximum capacity. And also that freight is >= 0 at every customer.
Now, A) works well if there are plenty of vehicles. Even if there aren't enough items, checking the soft constraint is pointless because it's a fixed constant number (the number of items lacking). You could even decide to spread that shortage fairly over the customers and adjust their customerDesired accordingly, before scheduling.
B) However, if there aren't plenty of vehicles, relative to the number of customers, then A) might be insufficient. We 'll want to allow to deliver/pickup less than customerDemand, making it more flexible (and therefore complex :). In this case, a Customer has 2 genuine (=non-shadow) planning variables (instead of just 1): the previousStandstill (~ previous customer) and the deliveryPickup (<= demand * 2).
I am curious what the best practice is. For example we have product entity, it has two fields: Price and VAT. What to save in Price value? Base price, and then calculate result price based on base price and VAT code. Or save calculated price and save VAT just for information purposes.
Without VAT, since it can change independently from prices.
Edit: by the way, why are you storing the VAT for each product? Isn't it better to categorize your products (if you have different types of VAT) instead?
Since VAT can change, I recommend storing the base price and the VAT percentage at the time of the sale. Then you can display the calculated price and the VAT percentage depending on what you need to report on.
Aside: The standard rate of VAT in the UK is due to change at the beginning of January 2011 from 17.5% to 20%, any solution should handle this kind of change.
The solution I've used previously is to have the following:
Product: NetPrice (MONEY, NOT NULL)
VATRateId (INT, NOT NULL, FK ->
VATRate.VATRateID)
VATRateVATRateId (INT, PK NOT NULL)
Description (TEXT NOT NULL)
VATRateValueVATRateValueId (INT, PK
NOT NULL)VATRate (MONEY NOT NULL)
EffectiveToDate (DATETIME NULLABLE)
That way I can store that Product X has a net price of 1.00, with a VAT Rate of {1, Standard Rate VAT}, which will apply the following rates { 17.5% until 2010/12/31, 20% thereafter}
The one thing this solution doesn't cater for is you changing the price of the product to ensure that, irrespective of the current VAT rate, the price always remaining at a certain "price-point" such as 4.99. What you could do here, for maxium flexibility (with increased complexity) is move the NetPrice field from the Product entity to a ProductPrice entity:
ProductPrice
ProductPriceId (INT, PK NOT NULL)
ProductId (INT, NOT NULL, FK -> Product.ProductId)
Price (MONEY, NOT NULL)
EffectiveToDate (DATETIME NULLABLE)
VAT in the UK has varied several times in the last year or so. I would keep Base Price separate from the variable VAT.
Product prices are best saved without VAT as already mentioned VAT rate can change independantly of prices, many of the databases I work on have the VAT rate(s) stored in a separate table, the price + vat is then calculated by picking a VAT rate from the VAT table.
Changes are easier to implement this way too, such as if the VAT rate changed from 17.5% to 20% you only have to change one row to have all your prices updated accordingly, rather than change every individual price.
If you store price + VAT, your database's integrity can be comprised if you update the VAT and forget to update the price + VAT. This won't occur if you store the raw price. In short, it is better not to store values that can be obtained by a calculation over the columns of a row.
In situations where there are three values to be stored in a database, such that knowing any two one can compute the third, I sometimes favor storing all three values along with an indicator of which two are "real" and which one is computed. The three values should always be equal; if they're not, one should examine what's going on and ascertain why.
For example, it may be useful to store timestamps as time zone, UTC, and local time, along with a "what is known" indicator. For example, if some time stamps are found to have been recorded using the wrong time zone, the "what is known" indicator can be used to determine whether the UTC or local time should be adjusted.
With regard to prospective rather than historical pricing information, I would think it might be helpful to store VAT-exclusive price, expected VAT, and VAT-inclusive price, along with a mode flag indicating various scenarios, such as
The VAT-inclusive price (VIP) should precisely track the VEP+VAT, to the nearest pence
The VAT-inclusive price (VIP) should precisely track the VEP+VAT, to the nearest 5p
The VAT-inclusive price (VIP) should precisely track the VEP+VAT, to the nearest 20p-1
The VAT-inclusive price (VIP) should precisely track the VEP+VAT, to the nearest 50p-1
The VAT-inclusive price (VIP) should precisely track the VEP+VAT, to the nearest 100p-1
The VAT-inclusive price should remain fixed if the VAT changes, but ip updating the VAT causes the VEP+VAT to exceed the VIP, the record should get flagged to suggest that someone consider increasing the VIP.
Basically, figure out what should happen if the VAT changes and adjust things accordingly.
Lets say I have a website that sells widgets. I would like to do something similar to a tag cloud tracking best sellers. However, due to constantly aquiring and selling new widgets, I would like the sales to decay on a weekly time scale.
I'm having problems puzzling out how store and manipulate this data and have it decay properly over time so that something that was an ultra hot item 2 months ago but has since tapered off doesn't show on top of the list over the current best sellers. What would be the logic and database design for this?
Part 1: You have to have tables storing the data that you want to report on. Date/time sold is obviously key. If you need to work in decay factors, that raises the question: for how long is the data good and/or relevant? At what point in time as the "value" of the data decayed so much that you no longer care about it? When this point is reached for any given entry in the database, what do you do--keep it there but ensure it gets factored out of all subsequent computations? Or do you archive it--copy it to a "history" table and delete it from your main "sales" table? This is relevant, as it has to be factored into your decay formula (as well as your capacity planning, annual reporting requirements, and who knows what all else.)
Part 2: How much thought has been given to the decay formula that you want to use? There's no end of detail you can work into this. Options and factors to wade through include but are not limited to:
Simple age-based. Everything before the cutoff date counts as 1; everything after counts as 0. Sum and you're done.
What's the cutoff date? Precisly 14 days ago, to the minute? Midnight as of two Saturdays ago from (now)?
Does the cutoff date depend on the item that was sold? If some items are hot but some are not, does that affect things? What if you want to emphasize some things (the expensive/hard to sell ones) over others (the fluff you'd sell anyway)?
Simple age-based decays are trivial, but can be insufficient. Time to go nuclear.
Perhaps you want some kind of half-life, Dr. Freeman?
Everything sold is "worth" X, where the value of X is either always the same or varies on the item sold. And the value of X can decay over time.
Perhaps the value of X decreased by one-half every week. Or ever day. Or every month. Or (again) it may vary depending on the item.
If you do half-lifes, the value of X may never reach zero, and you're stuck tracking it forever (which is why I wrote "part 1" first). At some point, you probably need some kind of cut-off, some point after which you just don't care. X has decreased to one-tenth the intial value? Three months have passed? Either/or but the "range" depends on the inherent valud of the item?
My real point here is that how you calculate your decay rate is far more important than how you store it in the database. So long as the data's there that the formalu needs to do it's calculations, you should be good. And if you only need the last month's data to do this, you should perhaps move everything older to some kind of archive table.
you could just count the sales for the last month/week/whatever, and sort your items according to that.
if you want you can always add the total amonut of sold items into your formula.
You might have a table which contains the definitions of the pointing criterion (most sales, most this, most that, etc.), then for a given period, store in another table the attribution of points for each of the criterion defined in the criterion table. Obviously, a historical table will be used to store the score for each sellers for a given period or promotion, call it whatever you want.
Does it help a little?