A price displayed beside a green indicator looks current even when the number was copied into a page months earlier. The visual treatment can imply more than the underlying data supports. A useful market-data card therefore needs an identifiable asset, a quote unit, a source, a time basis and a clear policy for unavailable or stale observations. This guide concerns the meaning and presentation of data, not a trading strategy. Every numerical exercise is invented. No price in the examples is a present quotation, and the restored historical catalogue should not be used as a live market-data service.
Identify the asset more precisely than its ticker
A short symbol is convenient for display but can be ambiguous. Different assets can use the same symbol, and an asset represented on several networks may need additional context. A data provider's stable identifier is therefore useful alongside the human-readable name. Record which identifier your request used, which result it returned and the quote currency. Do not assume that a familiar ticker resolves every identity question. A plausible-looking price can belong to the wrong instrument, making a beautifully formatted card misleading before any question of freshness even arises.
In a fictional exercise, two records both use the symbol SAMPLE but have different provider identifiers. A request based only on the symbol may not express which one the editor intended. The display should be tied to the resolved record, not just the typed label. The same discipline applies when importing an old table: preserve the historical label as captured, but do not silently map it to a current asset with a similar name. An archive records what the source displayed. A live integration requires an explicit, separately maintained identity mapping that the old table cannot supply by itself.
Name the price's unit and observation basis
A number needs a unit and a defined source context. A quotation in one currency is not directly comparable with a quotation in another, and a provider's aggregated figure is not necessarily an executable offer on a particular venue. A card should avoid implying that a user can transact at the displayed value unless that specific proposition is supported. Explain whether the data is a provider estimate, a venue observation or a historical sample. The label can remain compact while still telling a reader what kind of number is actually being shown.
Suppose a fictional provider returns 42 units of a quote currency for one unit of an identified asset. Showing only 42 omits both sides of the relationship. Adding a currency symbol helps, but the record should also preserve the source and requested pair. A later conversion introduces another observation and another time basis; it is not simply a cosmetic substitution. If the application cannot establish the intended unit, the correct display is an unavailable or unresolved value. Filling the gap with a previous number creates apparent continuity while concealing a change in what the measurement means.
Separate source update time from retrieval time
An application knows when it received a response, but that is not necessarily when the provider updated the underlying price. CoinGecko's simple-price documentation, for example, describes an optional last_updated_at field and identity-based lookups. Such metadata can help establish the age of the returned observation. The general design lesson is to keep the provider's timestamp separate from your request completion time. A fresh HTTP response can contain an older cached observation, and a newly rendered page does not make every value embedded in it newly measured.
In a deliberately invented timeline, a provider observation is stamped 12:00, the application retrieves it at 12:04 and the browser renders it at 12:05. The value has three relevant clocks. Calling it updated at 12:05 erases the four-minute gap before retrieval and the later rendering delay. A useful interface can show the observation time and, where necessary, the retrieval time. If the provider supplies no interpretable update timestamp, say so. Do not substitute the browser's current time merely because it is easy to obtain and makes the card appear reassuringly recent.
Give stale data a visible state
Choose a freshness rule based on the product's actual purpose and document that rule. There is no universal age threshold that makes every observation live. A historical research page and a rapidly updating dashboard have different needs. Once a value exceeds the stated threshold, change the display state rather than continuing to show the same green badge. A previous successful observation can remain useful if clearly labelled as the last available value. The failure should be visible in the interface, not confined to a log that ordinary readers never see.
A fictional card refreshes at a regular interval but loses access to its provider. The application can display the last successful value, its observation time and an unavailable-refresh label. It should not advance the displayed update time on every failed request. Nor should it replace missing data with zero, which is a possible numeric value with a very different meaning. Distinguish loading, unavailable, stale and current-under-the-defined-rule states. These labels help a reader understand the evidence behind the card without needing to inspect the application or guess whether a motionless number is still being checked.
Explain what the percentage compares
A change figure requires a baseline, an interval and a compatible measurement. A daily percentage can refer to a rolling window or another provider-defined convention. Two cards can therefore display different changes without either calculation necessarily being wrong. Preserve the definition supplied by the data source and avoid mixing a current price from one source with an unexplained baseline from another. A percentage shown with excessive precision can still be conceptually ambiguous. The useful question is which two values were compared, over which interval, and whether those values describe the same instrument and unit.
In an invented exercise, an asset moves from 40 to 44 quote units, a ten-percent increase relative to 40. Reversing that movement from 44 to 40 is not a ten-percent decrease, because the baseline changed. The arithmetic illustrates why a change label cannot be interpreted without its comparison basis. An archive may preserve a captured percentage, but recalculating it from unrelated current data would create a new statistic rather than restore the original. Keep captured values, new calculations and current observations as separate categories so that a reader can tell what was saved and what was later derived.
Use historical snapshots as historical evidence
When restoring a website, an old price card can be evidence of the interface and values displayed in a particular saved version. It does not become a current market feed merely because the surrounding site has been redesigned. If the old values are important to the record, label the capture date and the limitations of the source's own time metadata. If they add no necessary historical context, remove the simulated-live presentation from the new homepage. Honest absence is more useful than a permanent green indicator attached to a number nobody is maintaining.
The current reading room focuses on new explanatory essays and a separately identified historical source catalogue. It does not operate a live quotation service. That separation is a concrete interface decision, not a claim that historical observations have no value. A reliable card makes the asset, unit, source, clock and failure policy understandable together. If any of those components is missing, narrow the claim the display makes. A number can be a helpful snapshot without being live, and a website can be useful without decorating static content as a continuously updated market terminal.
Sources & further reading
Primary documentation informs the definitions. The worked scenarios and explanations are newly written; hypothetical examples are not historical events.