Locale and number formatting noise
Numbers carry locale: a comma is a thousands separator in one place and a decimal point in another, and currency and date formats differ everywhere. When values are imported, parsed, or merged across locales without normalising, amounts are misread — a price becomes a thousand times larger or a decimal collapses. This page explains locale and number-formatting noise and how to normalise to avoid it.
How locale corrupts numbers
The same digits mean different amounts depending on locale conventions. In many European locales '1.234,56' is one thousand two hundred thirty-four and fifty-six hundredths, while in others '1,234.56' means the same value — the roles of comma and period are swapped. A parser assuming the wrong convention turns a decimal into a thousands separator or vice versa.
Currency symbols, grouping, and even digit shaping add further variation that breaks naive string-to-number conversion.
- Comma vs period swap roles across locales
- Currency symbols and grouping vary by region
- Naive parsing misreads the value, sometimes by 1000x
Normalising to avoid it
Decide on a single canonical numeric representation and convert at every boundary — import, export, and merge — using explicit locale information rather than guessing from the string. The ECMAScript Internationalization API (Intl.NumberFormat) formats and the wider locale data (CLDR) document the conventions to respect.
Validate by spot-checking known values after import and watching for the tell-tale 1000x and missing-decimal errors before the data reaches a report.
How it appears in analytics and logs
Values off by a factor of a thousand, or decimals that vanish, usually mean a comma/period separator was parsed under the wrong locale.
Diagnostic use case
Prevent locale-driven misreads of currency, decimals, and numbers when importing or merging data, by normalising formats before use.
What WebmasterID can help detect
WebmasterID records numeric event values in a consistent canonical form, so locale formatting is a display choice rather than a source of parsing error.
Common mistakes
- Parsing numbers without specifying the source locale.
- Assuming comma always means thousands and period always decimal.
- Merging multi-locale exports without normalising formats first.
Privacy and accuracy notes
Number formatting is a presentation and parsing concern, not identity. It carries no privacy implication.
Related pages
- Currency and locale mismatches
Revenue breaks when monetary events mix currencies or send locale-formatted strings. A value like "1.234,56" (European format) or "$1,234.56" is not a number GA4 can sum, and reporting many currencies without per-event ISO codes makes totals meaningless. GA4 converts to a property base currency only when each event carries a valid currency. This page covers currency and locale formatting faults.
- Data import errors in GA4
GA4 data import merges external files (cost data, item metadata, offline events, user attributes) with collected data by matching on a key. When the key, the column names, the date format, or the schema do not match exactly, rows fail to import or join to nothing — leaving partial or absent enriched data with no obvious error in reports. This page covers the join model and its failure points.
- Missing currency or value on events
GA4 monetary events such as `purchase` need both a `value` and a `currency` field, and currency must be a valid ISO 4217 code. If currency is missing or invalid, GA4 may not credit the revenue; if value is missing, the event records but contributes nothing to monetary metrics. This page explains the requirement and the silent failure modes.
- Documentation
Canonical numeric values free of locale parsing error.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.