Demand from data

Which rows. Delivered orders only, purchased before 1 September 2018. The second half of that rule comes from the marketplace itself: the export's last timestamp is 17 October 2018 but only 20 orders are dated September or October and none was delivered, so the file effectively stops at the end of August. The retention and RFM courses hit the same ragged edge and chose the same date; reusing it means the customer table there and the panel here describe the same months.

What price. An Olist item row carries two money columns: price, which the seller listed, and freight_value, which depends on how far the buyer lives. The seller's decision is the first one. The buyer's cost is the sum. For an elasticity of the seller's price, use price; the freight-inclusive version is run as a check in session 2 and moves the answer by about 0.1, which is inside the range the honest sentence already carries.

What grain. One row per product per calendar month: units sold, and the mean item price that month. Monthly is the finest grain at which most of the 203 products have more than one sale in a row, and it is the grain at which a seller actually changes a price. Weekly would give more rows and more zeros; quarterly would hide most of the price moves.

An order can hold several items, each with its own product and price, so "units of product X" is a count of item rows, not order rows. Grouping by order would count a basket with three of the same product as one unit and merge two different products into one price. The item table is the one where a unit and a price sit on the same row, which is the only shape a demand curve can be read from.

The 2,453 items dropped by decision 1 are undelivered, cancelled or unavailable orders, plus the twenty stragglers after the snapshot. They are not errors; they are sales that did not complete, and a demand curve is about sales that did. Keep the count in a comment. If it ever changes on a re-run, the export changed and every number downstream is due a re-check.

Thirty items is a data floor: below it a month with two units and a month with three units differ by 50 percent for no reason a price could explain. 376 products pass. Three distinct prices is an economics floor: a slope needs the price to have been in more than one place, and two prices give a line through two points that is fitted to nothing. 226 of the 376 pass. Six months with a sale is an identification floor: one price change in a two-month product cannot separate "the price did it" from "the month did it". 203 pass all three.

The thresholds are choices and the page says so. Lower them and more products enter with noisier rows; raise them and the panel shrinks toward the handful of bestsellers. The right move is to write the three numbers as constants at the top of the script and re-run the whole ladder under two other settings before quoting anything, which session 10's bench does with two of them as switches.

The 203 are not a random sample of the marketplace. They are the products that sold a lot and repriced, which is the population any pricing decision is about anyway; the honest sentence says "for the products that can be read", not "for the marketplace".

A product's price can change mid-month, and the month's row then carries a mean of two prices weighted by how many units sold at each. That mean is the price the average unit that month was sold at, which is the quantity a revenue calculation needs. The mode would hide the change; the median would jump. In the headline product, January 2018's mean of 69.98 is 121 units, all but a few at 69.90 and a handful at 75 before the cut took effect. The rest of the year's rows are single prices.

For the same reason, "units" is a count of item rows and not of orders. A basket of three is three units at one price, and it belongs in the month's total three times.

Read the thirteen rows again. Five months at R$ 75 selling 5 to 45. A cut to R$ 69.90 and five months selling 43 to 121. Then R$ 89.90 and R$ 103, selling 2, 2 and 3. A line through that has to pass near the bottom-right dots, and it comes out at -10, which would mean a 10 percent rise loses 62 percent of units. Nobody's bath mat behaves like that.

What the last three months look like is a product going out of stock or being delisted, with a price raised on the way out, or a seller clearing the last units at a higher price with no promotion behind it. In either case the units did not fall because the price rose; both moved because the product was ending. The rows cannot distinguish demand from supply here, and a slope fitted to them is a description of the product's life, not of its buyers.

This is the general lesson and it is why the track fits the panel and not the product: one product's thirteen months carry every accident of its life, and a slope has no way of knowing which dots are accidents. Two hundred products' months average the accidents out, and what is left is the part they share.

Elasticity is a ratio of percentage changes, and the derivative of log x is one over x, so a small change in log x is a percentage change in x. A straight line in logs, log units = a + b log price, therefore says: a one percent change in price goes with a b percent change in units, at every price. That is the constant-elasticity demand curve, and b is the elasticity.

Two consequences worth holding. First, the fit is only as good as the assumption that the elasticity is the same at R$ 70 and R$ 100, which the bench's session tests by fitting on subsets. Second, zeros cannot be logged: a month with no sales is not in the panel at all, which is one reason the eligibility rule asks for six months with a sale rather than six months.