Otto Data Scraping Services

Payment terms are a competitive lever, not a checkout detail

Payment on invoice and instalment purchase are mainstream in Germany to a degree that surprises teams used to card-first markets. Whether an item can be bought on invoice, and over how many instalments, affects the purchase decision independently of price.

Why a price-only dataset misses it

• Two listings at the same price are not equivalent if one offers invoice payment and the other does not.
• Instalment availability and the number of instalments differ by offer and by seller.
• Payment terms are a merchandising decision, so changes in them are competitive activity that price monitoring cannot see.
• Terms differ between retailer-sold and marketplace offers, which compounds with the offer split.

We capture payment_invoice_available, payment_instalments_available and instalment_count_max where published, as separate fields alongside price.

We do not compute a single effective price from them, for the same reason we do not on Mercado Libre instalments: whether the terms matter depends on whether your buyer is price-sensitive or cash-flow-sensitive, and that judgement is yours.

Retailer stock and marketplace offers price differently

Otto sells its own inventory alongside marketplace sellers. The distinction matters commercially and is routinely collapsed.

• Otto-sold offers are the retailer's pricing decision, and for a brand that is a buying-relationship question.
• Marketplace offers come from third parties setting their own prices, which is a channel-control question.
• Payment terms often differ between the two, so the split interacts with the field above.
• Grey stock concentrates on the marketplace side, as on every platform with a marketplace layer.

We capture offer_source as otto_retail or marketplace, plus seller identity where displayed. A price observation attributed to the wrong party leads to the wrong conversation with the wrong counterparty.

High return rates make variant availability oscillate

German return rates in fashion and home categories are among the highest anywhere. That has a specific consequence for availability data that most datasets misread.

A size or variant sells out, returns arrive, it comes back. A weekly snapshot cannot distinguish that from a replenishment order, and the two mean opposite things about demand — the same problem we handle on Zalando.

• Variant-level collection is necessary, since availability at product level hides the pattern entirely.
• Restoration events need timestamps so returns re-entering stock are separable from genuine reorders.
• Daily continuity is required; sampling produces a dataset that reports noise as signal.

We collect at variant level daily with variant_restored_at, and we report availability transitions rather than implying they are sales. On a returns-heavy market, treating an availability change as a demand signal without that caveat is the most common error in the data.