Shopify customer search versus filters: two different matchers

You type `en` into Search, hoping for empty locales after a CSV import. The grid shows someone with `en` in a tag. The actual blank-locale rows are on another page, or outside this query. Tomorrow’s ticket says “we searched”.

Shopify customer search versus filters is a real split in OO - Bulk Customer Data Editor. Choose columns, filters, and sorting:

• Search asks Shopify for customers matching name, email, phone, and tags.

• Filters also run store-wide. Common fields (name, email, tags, address, marketing state, orders, spend, …) go to Shopify’s customer search. Other fields — the docs name some metafields, note, locale — are matched while scanning results, not as a Shopify search field.

The app is Free. 0 reviews on the listing; do not invent a rating. Open it from Customers → More actions → Edit in bulk, or Start editing in the app.

Select all matching (50,000 cap) follows current search plus segment plus filters. Wrong search, wrong selection. This article is that fork.

Admin search will not list “locale is empty”

Shopify’s own customer search uses what Shopify indexes. After an import, Customer Locale is often blank, store-default, or the old shop’s language. Typing `nl` does not mean “everyone whose locale is Dutch”. Tax exempt is the same class of pain: one profile at a time in the native editor.

This app’s listing highlights bulk locale and tax-exemption, plus filters and saved views. Do not pitch another Online Origins app. Excel is still just a CSV. The matcher above lives in the spreadsheet editor.

Mix-ups that waste the 50,000 cap

Everything in Search. “tax exempt”, “empty”, a metafield key. Search sends name/email/phone/tags. The rest is coincidence or silence.

Assuming the current page is the full set. Filters reload across the whole list, combined with search and segment — not page one. People still tick twelve rows and call it done until they use Select all matching.

Skipping the segment. On a large shop the docs want search or a segment first, then filters.

None of that is: Search for people you know by name, Filter for locale/note/metafield, then select-all.

How they stack

Search

A slice of an email, a last name, a tag. Fast when you want one person or one tagged group. Useless when the attribute is locale is empty.

Filters

Filters → field, condition (`contains`, `is`, `is empty`), value. Multiple filters allowed. The table reloads with shop-wide matches.

The listing pain maps here: Locale is empty (or equals the wrong language). That is scan-matching, not a Shopify search field. Same family: note contains “B2B”, a given metafield. Not every metafield type is editable.

Common filter fields may still go through Shopify search. Locale, note, some metafields do not. That is the “versus”.

Select all matching

Apply a value to many customers: selection follows search + segment + filters, up to 50,000, with progress. Then bulk apply (locale dropdown, tax exempt yes/no, …), review the grid, Save on the Shopify bar. Nothing writes before Save. Keep the tab open on large jobs.

A leftover Search of `en` plus a locale filter is an intersection. Empty Search plus a locale filter is everyone who matches the filter (up to the cap). Do not “just type something” in Search for luck.

Example: migration CSV, locale blank

Three thousand rows. Tags survived. Email survived. Notifications go out in the wrong language.

1. Open the editor.

2. Leave Search empty (or pick a segment for the import cohort).

3. Filter: Locale is empty. A second filter on tax exempt is a second action, not the same column.

4. Show the Locale column. Spot-check.

5. Select all matching. Bulk apply the right locale. Review. Save. Tab stays open.

If an `imported` tag exists, Search or a tag filter can narrow first, then locale. Search-only `imported` without the locale filter also grabs people who already have the correct locale. Re-applying the same value is mostly waste against the 50,000 ceiling.

Notes: bulk-edit customer notes. Note is on the scan side; Search will not treat note text the way a filter can.

Start here

1. Install OO - Bulk Customer Data Editor (Free).

2. Customers → More actions → Edit in bulk.

3. Decide whether the attribute is a Shopify search field (name, email, phone, tag) or scan-side (locale, note, some metafields).

4. Combine Search and filters on purpose. Large shop: segment first.

5. Select all matching, bulk apply, Save. Cap 50,000; narrow if you are over.

Saved views remember columns/filters/sort for the whole shop. Useful if empty locale comes back every month. No paid tier on the listing.

Sort is the third control in the same docs: Sort or a column header, ascending or descending. It does not change what Search or a filter matches. It only changes the order you spot-check before Save. Columns: the picker remembers the choice in this browser; identity columns stay visible. Hiding Locale while filtering on it is allowed — the filter still runs, you just cannot see the value. Show the column before bulk apply.

Shopify segments in the dropdown narrow the set first. “Edit in bulk” from a segment is the same editor; search and filters stack on top. Segment features depend on Shopify permissions for the shop and the staff account — FAQ. If protected customer data is blocked, editing stays limited until access is approved. That is not a search bug.

Marketing consent (email, SMS, WhatsApp) follows Shopify’s rules. Filtering on consent is fine; bulk-applying “subscribed” without a valid opt-in fails or is invalid. That is not locale scan-matching. Keep consent out of this locale fix.

Wrap-up

Shopify customer search versus filters: Search is Shopify’s name/email/phone/tags. Filters cover the full list; locale and notes match while scanning. Select all matching follows both, plus a segment.

Do not type `en` into Search when you mean empty locales. Filter that, then Save. Listing: OO - Bulk Customer Data Editor.