Query optimisation

A query rule reads a search before it runs, spots a format — a postcode, an order number, a barcode — and turns that part into a constraint (“only records with this postcode”) instead of words to match.

• The mirror of gates: a gate shapes a record on the way in, a rule reads a search on the way out. Both sit on the list header — this icon, the shield for gates.
• Live on the next search.

The problem they solve

With no rules a search matches the text as typed: flat 2 zz1 1zz is four words, competing with every record containing “flat” or “2”. A UK postcode rule reads it as “flat 2”, narrowed to postcode ZZ1 1ZZ.

Rules belong to a list

• Created on the list, not on the account as a gate is — a rule ties a format to a field, and postcode on your properties list is not postcode on your customers list.
• Only a facet can be targeted. No facets yet? The dialog says to add one first.

What a match does

• Narrows or pins is decided by how many records share a value, not by the format. Pinning is safer: a missing pin costs one row, a narrow matching nothing returns an empty page.
• Shipped formats arrive with the answer chosen, stated in the dialog as a sentence about what the customer sees. Change it if your data disagrees.

When a rule should act

Recognising a format is not knowing the value exists: ZZ1 9ZZ is a well-formed postcode nobody lives at. Rules ship on the right position; the ⋮ menu offers the other two.

• That last one with narrows is the only combination that can return an empty result set, and the only one the console labels — the row reads Can return nothing.
• With pins it is harmless, so the identifier formats (ISBN, IBAN…) ship set to it, unlabelled.
• Letting a rule act more often only ever makes it act more often, never less.

The order rules run in

• Searches meet rules top to bottom and the first rule to claim part of a search wins; the rest see only what is left.
• So the position column settles two rules wanting the same words — four digits as a postcode or as a year, not both.
• Move up / Move down in the ⋮ menu; the rows slide to their new positions.

On, test only, off

Put a new rule in test only, leave it a week, then read what it did; live searches are untouched meanwhile. Start there from Try it without changing anything?, under Options in the add dialog.

What a rule has been doing

Choose What has this been doing? from a rule’s ⋮ menu for the last seven days:

• How often it fired — or would have fired, in test only — as a share of all searches.
• Matched values your data does not hold — the number that decides it: those searches would have returned nothing.
• Typical results — the median results the searches it fires on currently return.
• Too few searches to read? It says so before showing a figure. A test-only rule can be switched on, or discarded, here.
• No “340 results → 4 results” comparison — it would double the cost of every search the rule touches.

Work out my rules

Work out my rules reads your records, works out what each facet holds, and adds the rules your data calls for.

• UK postcodes get a postcode rule; thirteen-digit barcodes get a barcode rule.
• A field matching no shipped format but repeating enough to be a set to choose from (a dozen brands, four countries) gets a rule from its own values — “scotland” narrows to the country.
• Fields of plain numbers are left alone: a rule on a building number would read any number as that field, so “4 bedroom” becomes building number 4, and no setting prevents it. Add it yourself if customers search that way.
• The report names the fields it skipped and why. Rules added this way are labelled with the evidence behind them.

It runs on its own after an import. While a run is going the page says so, rules appear as created, and Add a rule is paused. The button asks for a run now, past the spacing-out that keeps a ten-thousand-record import to a single run.

Try a query

The box below the table answers how will this search be read? Type a search, choose Read it.

• Returns what reaches the search engine and which part became a constraint. Nothing is searched, nothing saved.
• Includes rules in test only, so a rule can be checked before it is switched on.
• If a rule changed since the answer was worked out, it says so rather than showing a reading that no longer happens.

The formats we ship

Eighteen formats come with your account, already set to narrow or pin:

• Narrow — UK postcode, US ZIP code, Canadian postal code, Australian postcode (with or without the space; a UK postcode is recognised across two words as readily as one); Date (YYYY-MM-DD); IP address; Price (an exact amount like £19.99 — ranges such as “under £20” are not a rule).
• Pin — Email address, Phone number (international), UK phone number; ISBN-13, ISBN-10, Barcode (EAN-13) (with or without hyphens); IBAN, Identifier (UUID), MAC address; Vehicle identification number, UK vehicle registration.
• Watch the Australian postcode: 2019 is a Sydney postcode, a year and a quantity. If your records hold both, set that rule to act only on values it can confirm.

A rule on your own values

• One of this field’s own values matches search words against the values already in the field — your brands, categories, cities.
• No format to get wrong, and fixed to the cautious position: the field’s values are the whole test.
• Use it when dyson cordless should read “dyson” as the brand, not a word in a description.
• The rule’s row names the values themselves — “NSW, QLD, VIC and 5 more” — so a rule on Australian states reads differently from one on American states. You can search the rules by any of them.
• This is the tool for a word that is one of a field’s values, not a synonym. A synonym for vic would expand victoria back into the text and match every Victorian record; a rule filters to them.

A format of your own

For part numbers, internal codes and ticket references, choose Something else — I’ll describe it.

• Describe the values in your own words (“ACME, a dash, four digits, a dash, one letter”) and an AI model drafts the pattern.
• You see which of your own values it matched and missed; nothing is created until you approve it.
• It is an AI model call, so it needs one of your saved credentials.
• No hand-written pattern box in the console. The API takes a pattern directly, and so do the client packages:

await client.QueryRules.create("acme", "parts", {
  name: "part-number",
  target_field: "part_number",
  pattern: "^ACME-\\d{4}-[A-Z]$",
  state: "Shadow",            // watch it for a week before it counts
});

// Nothing is searched and nothing is stored.
const read = await client.QueryRules.test("acme", "parts", { query: "acme-4471-b blue" });

The whole page is on client.QueryRules in the TypeScript and .NET packages: list, create, reorder, switch on and off, read what a rule has been doing.

Add a rule

1. Open the list, then the query-rules icon in its header, then Add a rule.
2. What does the format look like? — a shipped format, this field’s own values, or one you describe.
3. Which field holds it? — any facet on the list.

Those are the only two questions; the sentence above Options says what the rule will do and whether it counts yet. Options holds the prefilled What should a match do? and Try it without changing anything?, plus the Name, built from your two answers — change it if the list needs a second rule on the same field, since a billing postcode and a delivery postcode are two rules.

Notes

• Read on every search of the list, including searches through a group the list belongs to.
• Nothing is rewritten — a rule changes how searches are read, never what your records say, and never anything already answered.
• Deleting a rule takes effect on the next search.
• A rule firing on values your data does not hold shows up in What has this been doing? Reach for Only when your data has the value before Off.