How Mercado Libre guesses a parcel's size before anyone measures it
In 2020 Mercado Libre described a model that predicts the weight and dimensions of a listed item by finding similar products and taking the median of what they weighed and measured when they shipped. It answers 20,000 requests a minute.
A marketplace ships millions of things it has never seen. A seller lists a cordless screwdriver and types a title, a price and a photo, but often not the weight or the box size. Yet the shipping price, the courier bill and the shelf space in the warehouse all depend on those four numbers. In June 2020 Kevin Clemoveki of Mercado Libre, the Latin American marketplace, described one of the company's answers: guess the numbers from similar items that have already shipped. It is a lookup with a smart search in front, and that is exactly why it is worth copying.
The problem: the numbers that set the price are the ones sellers skip
"From a shipping perspective, some of the most important information related to an item is its dimensions (weight, length, width and height), used to predict costs and forecast the occupancy of our fulfillment centers." But "Since it is a user-driven market, this information is not always available". Mercado Libre's shipping arm, Mercado Envíos, prices shipments by size, so a wrong or missing number costs money twice: once in the price shown to the buyer, and again when the real parcel turns out bigger. The post says it plainly: better estimates minimise "the costs of Mercado Envíos (shipments) when it comes to taking on faulty estimates."
The data exists, just not for the new item. Every past shipment of a product left a record of its weight and size. The trick is to find past products similar enough to borrow from.
How they built it
One line of text per item. Similarity is judged on four fields: "According to the metadata defining an item as such, we have considered the criteria of similarity in title, category, brand and model." Those are joined into a single text, cleaned (accents removed, tokenised, spell-checked, lower-cased) and turned into a vector with FastText, a fast word-embedding library.
One clean answer per past item. A product that has shipped many times has many measurements, so the team collapsed them: "it is necessary to assign to each item a single set of dimensions, obtained in this case by estimating their respective medians so as to eliminate outliers." The data is split by item, so no product appears in both training and test.
Search, filter, take the middle. All item vectors go into an Annoy index, a library for fast approximate nearest-neighbour search. For a new listing: "The item with a vector representation consults the previously populated Annoy index to obtain the K nearest neighbors with their respective distances. Then, this set of candidates is reduced by applying a distance filter in accordance with a given threshold T, where all the candidates with a distance greater than such threshold are discarded." The survivors' stored dimensions give the answer, "using the median of each dimension." The post never says what K and T are.
The worked example, in the table at the top of this page, shows why the median matters. For a cordless screwdriver kit, the search returned six similar listings with weights from 750 g to 5,150 g. Two of them claim a 10 x 10 x 10 cm box, one of them for a 3 kg carry case that cannot fit in it. Those look like placeholder values someone typed. The median ignores them and lands on 2,802.5 g and 29.3 x 23.25 x 10 cm. An average would have been dragged around by every bad row.
Fast enough for the listing page. The model runs in two places: "the product publication page and the fulfillment center packaging calculator to forecast the occupancy of the shelves and the right envelope to use at the final product packaging stage." And "The API currently serves 20k predictions a minute or 29M a day. The mean inference time for our model is 5ms and we serve it on a 32GB RAM + 8 cores instance."
What it delivered
The post reports speed and load, nothing about accuracy. There is no error measure, no share of items it can cover, no test against the previous model and no saving in money. The one metric it names, coverage, comes without a value. Read it as a clear description of a design, not as proof that the guesses are good.
What has changed since
The 2020 model replaced a heavier one. A 2019 guest post on the TensorFlow blog by the same team described a neural network that served "3k predictions a minute or 4M a day" at 30 ms. In March 2021 Mercado Libre listed package dimension prediction among its production machine-learning uses. No later post about it has appeared.
The rules around the numbers have tightened. Mercado Libre's developer documentation, updated in 2026, asks sellers for packed dimensions in centimetres and grams, says the platform checks that they are realistic, and lets the warehouse override them for stock it holds. Its shipping-cost API returns a billable weight. The stakes grew too: Mercado Libre's annual report for 2025 names a $1,912 million increase in shipping operating and carrier costs as the first reason its costs rose.
Why it matters for your business
Indonesian couriers bill by volume as well as weight. J&T Express, Ninja Xpress and Pos Indonesia publish the same formula: length times width times height in centimetres, divided by 6,000, gives a volumetric weight, and you pay for the larger of that and the actual weight. JNE publishes a divisor of 5,000 for its trucking and international services, which makes the same box 20% heavier on paper. Actual weight is rounded too: at both J&T and JNE a 1.4 kg parcel is billed as 2 kg.
Marketplaces now pass that bill straight to sellers. On TikTok Shop and Tokopedia, since February 2025 the seller pays on the higher of the weight they declared and the weight the courier measured, so declaring too little saves nothing. Since May 2026 a per-order logistics fee there also depends on parcel size. A wrong size field is no longer a rounding error. In the screwdriver example, one neighbour's 76 x 40 x 20 cm box would bill at about 10 kg at a divisor of 6,000, twice its real weight.
How we would build it today
- Keep a dimensions table first. One row per product: packed length, width and height in cm, gross weight in grams, and where each number came from (measured, courier, predicted or seller).
- Measure in the warehouse. A tape, a scale and a phone photo of the packed parcel for every new product. Couriers bill the packed parcel, not the item.
- Standardise boxes. Eight to twelve box sizes, the box id stored per product, and the expected billable weight computed with each courier's divisor.
- Predict only the gaps. For products not yet measured, find similar ones by title, category, brand and variant. Character n-grams or a multilingual embedding cope with Indonesian shorthand like "isi 12" or "500 gr". Use FAISS, Annoy or pgvector, keep close matches only, take the median, and answer "no estimate" when too few qualify.
- Distrust defaults. Drop 1 x 1 x 1 and 10 x 10 x 10 rows, and flag items whose weight-to-volume ratio is far from their category.
- Show the guess to the seller. Pre-fill the form with "perkiraan" and ask for one tap to confirm or fix. Only the person holding the box can correct it.
- Close the loop. Write the courier's measured figures back to the table, and re-measure products where the gap keeps repeating.
For a small seller the model is optional. A spreadsheet of 100 measured products and the courier's own calculator stop most of the leak.