A query is a set of criteria that, when executed, creates a list. This list is dynamic and changes over time as the data changes for each contact.

Integrating queries with your marketing strategies enables you to deliver highly engaging personalized content geared toward specific audiences, thereby increasing conversions.

The query functionality enables you to send messages to smaller numbers of contacts or to select contacts based on targeting criteria. The resulting databases appear on the Query tab. Segments and queries are not separate databases but are simply sets of contacts in the parent database. However, segments and queries can be mailed to and exported just like standard databases.

Benefits of using queries

Query a database when you want to create a subset of an original database based on some criteria related to the contacts, such as opened email, orders, or other information in the database.

• Send messages to a subset of the database.
• Send to a subset of the database with contact behavior and actions included.
• Export results so you can see which contacts perform specific behavior and action combinations.
• Personalize emails with relational table content blocks through a relational table query.

Note: To disable the query feature, contact Support.

Build rules for queries

You can build rules for data fields, contact lists, queries, and channels. Some criteria are visible only if you use a mobile push-enabled database.

1. To define profile criteria, activate the rule builder by clicking in the appropriate screen location.

   For example, when you configure a decision point, click the These Rules link, which opens the Rule Builder.

2. Click a profile option from the list to open an expression in edit mode.

   Options are Data Fields, Contact List, Query, and Channel.

   Note Available operators depend on the field type.

   1. For data fields, select the desired field and construct an expression that defines an operator and a value to which the field is compared. The value is not case-sensitive.

      To use a field as the value, enter the field's name in brackets. For example, [First_Name].

   2. For Contact List, select a contact, an operator, and a target contact list.

      Operator options are Is and Is Not.

   3. For Query, select a contact, an operator, and a target query.

      Operator options are Is and Is Not.

   4. For Channel, choose a channel behavior and apps for the Mobile channel.

      Mobile channel behaviors are:

      • Is Opted-In to
      • Is Opted-out of
      • Has Never Joined
3. Click Done.
4. Click Save & Close to move to your next task.

Behavior criteria

Note: Certain contact actions recorded in Campaign can be used as part of a query in your program.

1. Activate the rule builder by clicking on the appropriate screen location.

   For example, when you configure a decision point, click the These Rules link, which opens the Rule Builder.

2. Click Behavior, and then choose a behavior category.

   This places an expression, in edit mode, into the rule builder.

3. Select Has or Has Not, depending on the query you are building.
4. If more than one behavior is available, choose a behavior.

   This enables the Target and Timeframe options.

5. Select the required target(s).
6. Note the time frame, which displays how far the contact actions are available for searching in the past.
7. Click Done.
8. Click Save & Close to move to your next task. Data used in programs' behavior queries and rules are subject to retention limits.

Query criteria character specification

The maximum number of characters query criteria can contain is 32767 characters. An error will occur if your query has more than 32767 characters. You must remain within the limit of 32,767 characters. Also, there must be 1000 or fewer different values to compare. For example, if there are 1,001 Zip Code values within an 'Is In List' rules, the email or data job will result in an error. Make sure your query criteria are under this amount.

Assign a VMTA to a specific query

To assign a VMTA to a specific query, go to the query and click Settings.

In the dialog box, select the VMTA Name to assign to the query. If you segment a query into new/multiple segments/queries, you must go into each new segment/query and assign your VMTA, as it does not carry over from the original query.

Query processing time

You set up a query with different criteria, including field data (Field1 is equal to 'Yes'), sending history (Has been sent Email1 in last 60 days), and web tracking (Has visited Page1 in last 60 days). When you calculate it on Monday, it takes only a minute or two, but on Tuesday, it takes 20 minutes or more. Why would your query processing times fluctuate, despite the criteria remaining identical?

To understand why the time would fluctuate, review what Campaign does when a query is processed:

What happens when Acoustic Campaign "processes" a query?

A query is nothing more than a set of criteria that can be leveraged at any time to filter down the contacts in a database based on their field data, behavioral history, etc... Every time a search is done within a query, or when it is calculated, or when it is sent to, Acoustic Campaign "executes" the set of the logic constructed within the query to evaluate if specific contacts within the parent database belong to the query.

Technically speaking, Campaign takes the English criteria you've built in the query to construct a single SQL statement against the various tables that hold the needed data. Behavioral data relating to opens and clicks is held in a different table than visits to a web page or relational table data. This SQL statement collects or counts the Recipient Ids (Campaign's unique identifier) that match your inputted logic. When the statement is executed against the database, the platform evaluates the resources needed to complete the process. It optimizes a path for the statement to run efficiently through the necessary tables. For a query calculation, in particular, we run the statement. After the Recipient ID list is built, we count how many records are returned, which is reflected in the updated size description. We similarly build out a list of Recipient IDs for an email using a query. We then employ those Recipient IDs for sends paired with the associated email addresses, field data, etc.

Why would a query process slowly/differently than before?

While not exhaustive, the following are common reasons for slowness and fluctuations when processing a query:

1. The SQL statement Campaign built out based on the English criteria can become large and complicated, especially when "Is In query" sub-queries are included.
2. The data the statement has to read can fluctuate in size and complexity.
3. Other processes have modified the data the Campaign is reading while the query is still processing.
4. The data needed by the query was recently accessed and remained in the cache.
5. There could simply be "System Load" on the platform, and read times could be slower than a non-peak time.
6. The underlying data is invalid.

What happens when multiple queries are running at the same time?

This might occur most often when multiple emails (with a query as their contact source) are processed simultaneously on the same parent database. If the data that one query is accessing is required by the other, the other will need to wait temporarily. And while it's waiting, it cannot process other query elements. So, in a way, queries queue against each other for resources when they simultaneously need the same block of data. That's why we recommend staggering emails to queries, so one has time to complete before the other, or using 'pre-processing' so queries can execute with plenty of time before the send time.

Default query settings

An organization administrator can change the default settings in Settings > General settings.