Query Rules and Constructs
All queries are subject to a number of rules and constructs to ensure that they filter your data as expected.
Query Structure
All queries are written in the following order:
[Query Type] [nth] [FROM/THROUGH/TO] [Journey Filters] [Customer Filters] [Query Filters]
Query Type
All engagement queries begin with you deciding which type of query you want to create. The query type determines the scope of the query.
MXO provides the following query types:
Statement | Scope | Summary | Notes |
---|---|---|---|
discover journeys | Return results for all identifiable journeys. | Discover data for all customer journeys, based on the specified filters. | |
discover nth | Return results for one identified journey. | Discover data for one journey where n is the _n_th matching journey, from the start or end of the full customer journey path. | |
export all customer data for date () | Return results for all customers. | Discover data for all customer activity, for a specified date range. | Replaces existing Data Export 7.5 functionality. |
Order of Filters
Individual Filters must be provided in a specific order, when writing queries, as shown in the following chart:
Journey Filters - FROM, THROUGH, and TO
FROM, THROUGH, and TO are journey cutting and splitting filters. Use these filters to split the full customer path into individual journeys based on specified attributes.
FROM and TO filters specify the start and finish interactions for the journey; THROUGH filters specify interactions that the journey must pass through to be included in the query results.
Journey Filters - WHERE
Journey filters provide statistical context, enabling you to create queries that ask ONE, for example, to include only journeys of a certain duration, or journeys where a customer has been delivered a particular action in query results.
Customer Filters - FOR CUSTOMERS WITH and HAVING
Customer filters provide a way of filtering the full population of customers according to known demographic attributes, such as age, gender, marital status, or recognition status. They can also provide statistical context, enabling you to create queries that ask ONE, for example, to include only journeys of a certain duration, or journeys where a customer has been delivered a particular action in query results.
Customer Filters - USING and EXCLUDING
Customer query filters allow you to include or exclude information about customers and journeys persisted in the results of existing queries, in other queries.
Interaction Context Entity Order
You must specify the entities of an Interaction Context (also referred to as an Interaction or Node, according to context) in the following order:
- Channel
- Touchpoint
- Stage
- Activity
- Proposition
- Date
- DeviceOS
- deviceType
Action Context Entity Order
You must specify the entities of an Action Context (also referred to as node, according to context) in the following order:
- Channel
- Touchpoint
- Proposition
- Action
- Action Response
- Asset
- Optimization
- DeviceOS
- DeviceType
Query Rules
Queries must conform to a number of rules.
Query Case
In general, queries are written in lower case. EQL automatically parses all filter names in lower-case. Where filter names are shown in UPPERCASE in this documentation, it is ONLY for illustrative purposes.
Names of individual entities and attributes you configure in MXO are auto-cased, according to their actual format.
String Comparisons
Case-sensitivity of string comparisons is dependent on database platform. As an example, Azure is case-insensitive.
Numeric Values
EQL supports only positive numeric values in queries.
Units of Duration
EQL uses only standard units of duration. Months are not calendar-specific; all are classed as having 30 days.
Boolean Trees
Certain query constructs require boolean trees, which affect the order of keywords. For example, these apply to THROUGH and NOT THROUGH:
through(interaction(stage="Purchase")) to interaction(stage="Leave")
through(not(interaction(stage="Purchase"))) to interaction(stage="Leave")