The Venezuelan dual price, and the 0.14% that comes from reading it wrong
Venezuelan product pages show a dollar price and a bolívar price at once. Deriving the implied rate from the page's structured data rather than the rendered price is the difference between a stable number and one that drifts.
A Venezuelan Mercado Libre product page shows `US$ 580.80` and `Bs. 476,314` together, which makes it one of the few public sources carrying a market exchange rate as an observable pair rather than as an announcement. The Actor returns `price`, `price_local` and `exchange_rate_implied`, and the rate is derived from the page's structured data rather than from the rendered price — the rendered price splits the cents into a separate DOM element, and reading it as shown shifts the implied rate by 0.14%. Measured across product pages on one day, the structured-data rate came out identical on every single one, where the rendered figure did not. The pair exists on product pages only, never on listings.
Key points
Venezuelan product pages publish a dollar price and a bolívar price together, which makes the implied exchange rate observable rather than announced.
The rendered price splits its cents into a separate DOM element, so a rate read from what the page displays is 0.14% away from the rate the page actually encodes.
Deriving the rate from the page's structured data produced an identical figure across every product page measured on one day.
A 0.14% error is small per row and compounds into a visible drift once prices are converted and aggregated across a catalogue.
The dual price exists on product pages only, so it requires `scrapeDetail` and is never available from a listing row.
Most exchange rates are announced. This one is observable, because the page publishes both sides of it at once.
What a Venezuelan product page shows
US$ 580.80 and Bs. 476,314, for the same item, on the same page. The seller quotes in dollars and the platform shows the bolívar amount a buyer would pay. That pair is a market rate at a moment, attached to a specific transaction rather than to a bulletin.
Two ways to read the same price
The obvious approach is to read the two rendered numbers and divide. The obvious approach is wrong, because the rendered price splits its cents into a separate DOM element — so a naive read takes 580 where the page means 580.80, and the implied rate lands 0.14% away from the rate the page actually encodes.
The structured data carries both amounts whole. Deriving from that is a few lines more work and a different class of answer.
What the measurement found
Across product pages measured on one day, the rate derived from structured data came out identical on every single one. The rendered figure did not. A single consistent rate across an entire catalogue is what you would expect if the platform computes it centrally, and it is a useful check: a derivation that produces scatter where the platform produces consistency is reading the wrong element.
Why 0.14% is worth the extra work
Per row, 0.14% is noise. Converted across a catalogue and aggregated into a price index, it is a systematic bias in one direction — which is exactly the kind of error that survives a sanity check, because nothing about it looks random.
Getting the pair out of a run
price, price_local, currency_local and exchange_rate_implied arrive together, and only from product pages. Listing pages carry neither, on any marketplace, so this needs scrapeDetail and the cost that comes with it. For the wider rule this is an instance of, see why currency belongs to the row.
Frequently asked questions
▸Why does a Venezuelan listing show two prices?
Because the market is partly dollarised: sellers quote in US dollars and the platform also shows the bolívar amount a buyer would pay. Both are on the product page, which makes the pair, and the rate between them, directly observable.
▸Where does exchange_rate_implied come from?
From the page's own structured data, divided pair by pair, rather than from the two numbers as they are rendered. The rendered price splits the cents into a separate element, and using it as displayed moves the implied rate by 0.14%.
▸Can I get the dual price without scraping product pages?
No. The pair appears on product pages only and is absent from listing pages on every marketplace, so it requires `scrapeDetail` and is billed at the product-page rate rather than the listing rate.
Sources
Every URL below was requested and returned a page on the date shown.
In Uruguay, Paraguay, the Dominican Republic, Nicaragua, Guatemala and Panama the local currency and US dollars appear in the same list of results — which makes a per-country currency column quietly wrong.
Measured in September 2026: the plain paginated path returns the anti-bot wall and the `_NoIndex_True` form returns results — and robots.txt disallows the second by name. There is currently no polite pagination available.
