What "customer data health" actually means

Most Shopify stores don't have a data problem they can see. They have thousands of small ones they can't.

A customer types [email protected] at checkout. A spreadsheet import strips the leading zero from a Boston ZIP code and turns 02113 into 2113. A point-of-sale system writes every name in capitals, so your abandoned-cart email opens with "Hi JENNIFER." A Canadian customer enters G6E3S5 instead of G6E 3S5. None of these break anything loudly. They just quietly degrade everything downstream:

• Email deliverability. Typo domains bounce. Enough bounces and your sender reputation drops for everyone else on the list.
• Shipping. Missing states and malformed postal codes cause failed address validation and returned parcels.
• Personalization. Merge tags render "Hi MARIA DAS FLORES" and your email looks automated, because it is.
• Segmentation and reporting. Inconsistent casing and stray whitespace break exact-match filters, so your segments quietly undercount.
• Support. Agents can't find the customer who's on the phone.

Data health is the practice of finding those defects systematically and correcting them at the source, instead of discovering them one angry support ticket at a time.

What Singulary fixes

Singulary checks every customer during a scan and groups what it finds into five categories. Each one has its own detection logic — none of it is a blanket find-and-replace.

Misspelled email domains

Singulary compares each email domain against a list of known providers using Damerau–Levenshtein edit distance, which treats a transposition like gmial as a single typo. A correction is only suggested when exactly one edit separates the domain from exactly one known provider.

That last constraint matters more than it sounds. hotmail.ir is one edit from both hotmail.it and hotmail.fr, so Singulary suggests nothing rather than guessing and rewriting a real customer's email to the wrong provider. Domains ending in a two-letter country code are also left alone — yahoo.gr and yahoo.ie are legitimate national variants, not typos of yahoo.fr.

Name formatting

Four distinct repairs, applied together:

• Casing. A name written entirely in capitals or entirely in lowercase is title-cased. Names that already mix cases — McDonald, de la Cruz — are never touched, because they were cased deliberately and a naive title-caser would damage them.
• Initials preserved. Inside an all-caps name, short tokens like AJ and J.R. and generational suffixes like III stay as they are.
• Surname particles. MARIA DAS FLORES becomes Maria das Flores, not Maria Das Flores. Portuguese, Spanish, Italian and Dutch joiners (de, da, das, do, dos, van, von, di, der…) stay lowercase, because that's how those names are actually written. This works out of the box with nothing to configure.
• Garbled characters. Double-encoded imports that turned José into José are repaired — but only when the repair round-trips cleanly to valid text, so a genuinely unusual name is never mangled.
• Split names. A full name crammed into the first-name field with an empty last name is split. Only exactly-two-word names, because Maria del Carmen is ambiguous.

Addresses, ZIP codes and missing states

Three separate checks run against each customer's default address:

Missing states are filled in from the postal code itself. A Canadian postal code beginning G6E is always Quebec — this is a lookup against static tables, not a guess, so the fix is exact. Only the state field is touched.

ZIP formatting covers two real, mechanical corruptions. Canadian postal codes missing their space (G6E3S5 → G6E 3S5) — in one store we analyzed, 1,640 of 16,975 Canadian addresses had this. And US ZIP codes that lost a leading zero to a spreadsheet on import (2113 → 02113), suggested only when the restored ZIP actually falls inside the state already recorded on the address.

Notably, Singulary doesn't try to fix six-digit US ZIP codes. Deleting a digit looks safe but is ambiguous — a real case we hit was 989226 in Bellingham, WA, which trims to a valid Washington ZIP in the wrong city. When a repair can't be verified, no suggestion is made.

Address capitalization title-cases ALL-CAPS or all-lowercase street and city lines, with street conventions preserved: compass directions stay uppercase (NE 5TH AVE → NE 5th Ave), ordinals go lowercase, and tokens containing digits are left alone. Turkey is excluded entirely, because dotted and dotless i don't survive a round trip through standard casing rules.

What to look for in a Shopify data health app

If you're comparing options, these are the questions that actually separate them:

Does it show you the change before making it? Bulk-editing customer records is not reversible in any convenient way. Singulary shows every suggested fix in a review table — current value, proposed value, and what specifically changed — and nothing is written until you approve it. Toggle a row off and it's dismissed permanently; future scans won't suggest it again.

Does it verify the record before writing? Between the scan and your approval, a customer may have updated their own address. Singulary re-reads the live record and confirms it still matches the reviewed snapshot before writing. If it changed, that fix is skipped rather than overwriting the newer data.

Does it touch only the field it's fixing? A ZIP correction should not rewrite the street. Each fix type writes exactly its own fields and verifies exactly those fields, so applying a spacing fix never invalidates a separate state fill on the same address.

Does it preserve marketing consent? When Singulary corrects an email address, customers subscribed to email marketing keep their subscription on the corrected address.

Is it conservative by default? The principle throughout Singulary is false negatives over wrong rewrites. It would rather miss a fixable record than corrupt a good one. Every rule above has guard rails built specifically to avoid confident, wrong corrections.

Does it handle duplicates too? Data health and deduplication are the same problem seen from two angles, which is why they're in one app.

Duplicates and data health work together

Singulary's core feature is finding and merging duplicate customer records — the same person who checked out twice with [email protected] and [email protected].

These two features are deliberately connected. If a customer is sitting in an unresolved duplicate pair, Singulary skips them for data health suggestions entirely. Merging may pick a different surviving email, so fixing the record first would be wasted work, or worse, applied to the record that's about to be merged away. Resolve the duplicate, and the data health suggestions follow on the next scan.

You can also export a complete record of every merge performed on your store as JSON — merge date, and the resulting and merged customer IDs and emails — so the changes are auditable and reconcilable against other systems.

Security

Customer names, emails and addresses are encrypted at rest. All writes go through Shopify's official APIs, and Singulary never modifies orders, fulfillments, or anything outside the customer fields described above.

Getting started

Install Singulary from the Shopify App Store and run a scan. Data health suggestions are collected automatically during the scan and grouped on your dashboard by category, with counts. Free plans see how many issues each category contains; paid plans open the review tables and apply the fixes.

Frequently asked questions