An app has no revenue observation in your dataset. A chart renderer replaces the missing value with zero. The page now appears to know that the app earns nothing.
It knows no such thing.
Preserve the distinction in storage
Use separate states for observed zero, unavailable, not collected, not applicable and collection failed when those distinctions matter to the product. Keep the reason and source context available to the interface.
For a hypothetical ads view, “no matching records found in the covered sources” is different from “this business runs no ads.” The first describes your observation. The second describes the world.
Test the arithmetic
Averages, totals and rankings can change dramatically depending on how missing values are handled. Report the number of observed values and the treatment of missing records.
If you calculate a revenue average from ten observed apps in a cohort of a hundred, do not imply that it describes all hundred without a defensible method. A conveniently complete table can conceal selection bias.
Make the UI useful anyway
Unknown does not have to mean a dead end. Show which evidence is available, provide the original source where appropriate and explain what could resolve the gap.
Avoid creating a fake estimate simply to fill a card. If an estimate is offered, it should come from an explicit method with a label and limitations, not from a design requirement that every tile contain a number.
Also check exports and API responses. A carefully labeled interface cannot protect the meaning if downstream files silently convert null to zero.
The discipline is simple and surprisingly valuable: describe what you observed, preserve what you do not know, and prevent convenient defaults from inventing facts. A product that handles unknowns clearly can be more trustworthy than one that always appears to have an answer.