Prepare a Mobile Phone Dataset Readers Can Explore

To publish a useful mobile phone dataset, start by deciding what each row represents: a phone model, a configuration, or a dated price observation. Then prepare a table readers can filter by manufacturer and compare using numeric specifications—not mixed-unit text or unexplained price labels.

This guide focuses on handset specifications, not subscriber records, call logs, or location traces. Keep sensitive information out of any public upload.

Choose a source that fits the question

Two downloadable datasets illustrate why the data card matters more than the title. Details below reflect their listings as of October 24, 2026.

Dataset	Useful for	Publication limitation
GSMArena Mobile Phone Devices	Historical device specifications and cleaning exercises	The uploader reports 10,000+ models, 86 specification fields, and an update dated June 23, 2020. Treat it as a historical snapshot, not a current catalog.
Mobile Price Classification	Practicing feature analysis and price-range classification	The task predicts a price range, explicitly not an actual price. The listing shows an unknown license, so resolve reuse permission before republishing its rows.

The GSMArena listing identifies scraped data, labels its license CC0, and says absent specification fields are populated with NA. Its preview also includes tablets and watches, so a phone-only release needs an explicit device-scope check. Preserve the upstream source attribution and review applicable reuse terms rather than treating a hosting platform’s license label as your entire permissions check. (Dataset documentation)

For a smaller, auditable comparison, build a curated table from manufacturer specification pages. For example, Apple’s iPhone 12 specifications list 64GB, 128GB, and 256GB capacities, a weight of 164 grams, and a nominal 6.1-inch display. That is enough for a clearly sourced example without inventing prices or filling undocumented fields.

Define the row before cleaning

Use one row per documented configuration when readers need to compare variants. Include storage capacity and, where relevant, RAM capacity and regional model code in the record’s identity. Do not merge records solely because their marketing names match.

Here is a small CSV structure example using the published iPhone 12 specifications. These are three capacity configurations of one model—not three different phones:

record_id,brand,model,storage_gb,weight_g,display_diagonal_in,source_record
iphone12-64,Apple,iPhone 12,64,164,6.1,apple-iphone12
iphone12-128,Apple,iPhone 12,128,164,6.1,apple-iphone12
iphone12-256,Apple,iPhone 12,256,164,6.1,apple-iphone12

In the accompanying reference sheet, map apple-iphone12 to the linked manufacturer page and record the date checked. Define display_diagonal_in as the nominal diagonal; Apple separately gives a 6.06-inch standard-rectangle measurement and notes that the actual viewable area is smaller. (Apple specifications)

Extend the schema only when your sources support it:

• ram_gb and battery_mah: numeric values with documented units and sources.
• release_date: the release date, not the announcement date; preserve partial dates without inventing a day.
• price_amount, price_currency, price_market, price_date, and price_basis: enough context to distinguish launch prices, retailer offers, and other observations.
• source_record and checked_date: a traceable source reference and verification date.

If you collect repeated prices, keep them in a separate table with one row per variant, seller, market, and observation date. Otherwise, repeated observations can look like duplicate devices.

Clean the comparison fields

Keep the original download unchanged and create a separate publication copy.

1. Separate raw text from numeric values. Preserve 190 g (6.70 oz) in a raw field and put 190 in weight_g. For dimensions, use separate height, width, and depth columns in one declared unit.
2. Do not flatten ambiguous variants. A cell listing multiple RAM or storage combinations needs a configuration source before it can become several reliable rows. Do not generate every possible combination automatically.
3. Distinguish missing from zero. Convert documented missing markers consistently, but retain confirmed zeros and explicit “No” values. Explain unresolved blanks using a missing-value policy.
4. Check identity and scope. Flag duplicate record IDs, exclude non-phone devices if required, and separate canceled models from released models.
5. Verify the fields driving your analysis. Check influential values against original specifications. Do not present a classification label as a currency amount or treat an old “Available” status as current availability.

Document column definitions, source references, exclusions, and conversions in a dataset reference sheet. State whether the table is a selected sample or a defined catalog; a large row count does not establish market coverage.

Publish and test the public page

Export the reviewed table as CSV or a supported spreadsheet file. TablePage supports CSV, TSV, XLSX, and XLS uploads and generates a public dataset page with a filterable table and charts.

Before sharing that link, check:

• The displayed row count matches the release file.
• Numeric comparison fields behave numerically, rather than as strings containing units.
• Missing values remain distinct from zero.
• Source notes, coverage dates, and definitions are available alongside the table or through linked reference material.
• Charts count the intended entity: three capacity variants should not become a claim about three distinct phone models.

Use a title such as “Selected Mobile Phone Specifications—Historical Snapshot” rather than “All Mobile Phones” unless you can substantiate complete coverage. Readers should be able to identify a row, understand its units, and trace its values back to a source.