Labels
Store
- store_id (number)
- store_name (text)
- store (text or number) - store name & store id combined (will search in both)
- store_address_line_one (text)
- store_address_line_two (text)
- store_address (text) - line one & line two combined
Till
- device_description (text) - till name
- till_id (number)
- till (text or number) - device description & till id combined
Transaction
- date (date)
- operator (text)
- total (number)
- product (text)
- timestamp (number) - unix timestamp of the transaction
- delivery_email (text) - email addresses the email receipt has been sent to, including Datahub resends
- barcode_transaction_number (atom) - transaction barcode
- transaction_id (atom) - alias for barcode_transaction_number (only added in July, won't work with older transactions)
- transaction_number (atom)
- transaction (atom) - barcode transaction number & transaction number combined
- consumer_email (text) - email address of the first delivery (excludes Datahub resends; normally the same as customer_email; only added in July, won't work with older transactions)
- bounced (atom) - yes or no, e.g. bounced:yes
Customer
- postcode (text)
- given_name (text)
- family_name (text)
- name (text) - given & family combined
- customer_email (text)
- last_transaction_timestamp (number) - unix timestamp of the last activity (used for "Last contact on")
- address (text)
- bounced (atom) - whether an email receipt sent to this customer's email address has caused a bounce (only added in July, won't work with older records; yes or no)
Transaction & Customer
- email (text) - delivery email & customer email combined
- delivery (text) - short delivery method (paper, email, customer, timeout)
Search is not case sensitive. The combined forms are there to make the use of it more natural. You can just write: name=smith total > 50 transaction:12345.
Some of these fields are already baked into the interface - date, store, delivery method (partially), and bounced. Please let me know if you feel like you need to add more.
Data types
Now, there are a few data types, which behave differently:
- text - Supports equality operators. Supports full-text search, which means word order does not matter. Support stemming (the ~ operator for derived word forms, i.e. ~shoe will match shoe or shoes).
john will yield the same results as name:john, but will also include cashiers and products that contain the name, so the label can be used for disambiguation.
john smith will yield the same results as smith john. - atom - Support equality operators. Exact match only, i.e. if an atom field reads john smith, looking for john will not find it.
- date - Supports equality and inequality operators.
- number - Always needs a label, i.e. you can't query 17 instead of total=17. Supports equality and inequality operators.
This refers to number fields, and not actual numbers. In fact, many numbers, such as SKUs, are indexed as text, so they'll still match without a label.
When a one-value query, i.e. one that does not have spaces or is a string enclosed in quotation marks, the query is matched against the text, date, and atom fields. Sample queries:
- john
- "john smith"
- 2014-08-14
When a multi-value query, each label-less query term is matched against all the text fields + the entire query is matched against the atom fields. Generally, atom, date, and number fields will need a label to be matched. Sample queries:
- john smith
- john total > 10
The syntax is: label operator value.
label is the name of a field, such as email, total, name.
Possible operators are:
- : or = (equals, is, contans)
- NOT (other than; must be written in upper-case)
- - with no following space (other than); e.g. -store_id=10
- < (less than)
- <= (less than or equal to)
- > (greater than)
- >= (greater than or equal to)
- OR (alternatives; only needs to find one or the other; must be written in upper-case)