Calculate query size

Use the Calculate Size button to find out the number of contacts that are included in your query.

Query size does not include opt-outs, undeliverables, or suppression list emails.

1. In Data, go to Queries.
2. Select the query.
3. Click Calculate Size.
4. Click OK to confirm that you want to calculate the selected query.
5. The Calculate Query Size Data Job page opens.
6. (Optional) If you want to receive an email that notifies you when the calculation is complete, select the Email Notification checkbox.
7. Click Submit.

   All criteria on all tabs of a query are calculated.

Calculate multiple queries

To calculate multiple queries:

1. Access Queries.
2. Select one or more queries by selecting the check box next to the query names. You can select classic queries and/or new queries.
3. Click the Calculate Size icon right under the Queries tab.
4. Click OK from the confirmation pop-up. You are taken to the Calculate Query Size Data Job screen.
5. Click Submit.
6. After you get to the data job confirmation page. Click on data job link in blue.
7. When each data job completes, the corresponding query is newly calculated.
8. You will have to click on those individual data jobs to see the results.

Why do identical queries calculate differently?

When making a copy of a query without making changes to the query criteria, we expect the new copy of the query returns the same result and has the same query size as the original query. However, sometimes an identical query may return totally different query size upon calculation even the query criteria is the same as the original query. Why?

Causes

The problem is a result of a circular "not in query" relationship. Normally when Query A is not in Query B, the result of Query A is relying on the result of Query B. But when Query B contains criteria of "is not in Query A", there is a circular logic occurs. Therefore, the Acoustic Campaign query engine may return different results due to the logical flaw.

Resolving the problem

Example

To resolve this issue, you should inspect all sub-queries used by "is not in query" to logically prevent the self-looping problem.

The parent database contains the following contacts:

Query A

email contains "evan"

and not in Query B

Query B

email contains "acoustic"

and not in Query A

If we start with Query A, the first expression matches contacts 1 and 2. We can't fully execute Query B, because it requires executing Query A, which needs Query B, and we end up in an infinite loop. When applying the second expression, the user is probably going to expect contact 1 is removed from the results because it matches the criteria of Query B. So, Query A results in just contact 2.

Starting with Query B, the first expression matches contacts 1 and 3. By the same logic we used before, contact 1 should be removed because it appears to match Query A. This results in Query B matching just contact 3.

In the first approach, we removed contact 2 because they were in Query B. But with the second approach (using the same logic from a different starting point), contact 2 is not in Query B, and thus should still be in Query A. We could reverse this and determine that contact 2 should be in Query B. Based on the logic of the two queries, contact 2 can't be in both, but there's no way to determine which one it should be in.

The query engine takes the approach of starting with the currently executing query, which filters out the contact that might be in either query. In this example, Query A matches contact 2, Query B matches contact 3, and neither query matches contact 1.

Now, we can copy Query A as Query C:

email contains "evan"

and not in Query B

We still have a circular relationship, but now it's deeper. We start with Query C, finding contact 1 and 2 for the first expression. Then we try to evaluate Query B, which looks just like the case when we started with Query B, which only matched contact 3. Therefore, Query C matches both contacts 1 and 2 even though it has the exact same criteria as Query A, which only matched contact 2.

Why does the query calculation not update contact summary numbers in the send experience?

Query calculations and contact summary numbers

While running a calculation job on a Query in order to send an email to it, at completion the Query showed around 40k contacts calculated. However, sending to the Query in the Send Experience, the Contact Summary numbers are not updated from the Query calculation job.

Resolving the problem

The Send Experience 'Contact Summary' section (that gives you a preview of how many contacts you can expect a send to go out to) does not involve previous Query Calculation jobs you've run. Running a query calculation on the query earlier in the day does not mean that the count would be updated within the Contact Summary section.

This is because a query calculation job simply counts how many records match the criteria, and the Contact Summary section is quite different because it kicks off a send process (without actually sending anything out) and counts the number of records, number of suppressed, etc... a Query calculation job doesn't look into how many contacts would be suppressed, for example.

To see the counts updated within the Contact Summary section, simply hit the refresh button and this will process a mock send and update the 'Last calculated' timestamp, providing you the most up-to-date numbers.

Query recently calculated

When calculating a query you may see the error message This query was calculated recently.

Try again later is displayed when running the same query multiple times. As calculating a query uses many resources, Campaign is set to not allow you to calculate the same query back-to-back. You will have to wait for about 10 minutes before you will be able to calculate that query again. There is no way to turn this off, as it is by system design to prevent system overload. However, if you modify your new query to add additional criteria, the query will recalculate as the query criteria has changed.

Optimize queries for decreased calculation time

You should optimize your query when the following error appears: This query contains values or arguments that are too long to be saved. Reduce the size of your query criteria.

This error message can appear when you run a query with any of the following operators.

• is in list
• is not in list
• contains one of the following
• does not contain one of the following
• is equal to one of the following
• is not equal to one of the following
• starts with one of the following
• does not start with one of the following

To fix this error, instead of using one of the operators listed above as query criteria, you can optimize your query by creating one of the following.

• Contact list
• Relational table (if applicable)

When you create a contact list, you can add contacts from a parent database based on fields or a query against the parent database, so you can retrieve the IDs and zip codes that exist in your database.

When using one or both of these lists in your query criteria, you can update the contact list and relational tables with new contacts and data without having to modify the query.

You can also add or update information in either area by using the following API calls:

• Add a contact to a contact list API call
• Insert and Update Records in a Relational Table API call

You can also use these methods when using a rule builder in dynamic content.

Note: Calculate list data jobs will prevent other jobs from running on that database. For example, a list import data job can’t run at the same time as a calculate list data jobs on the same database. This is done to prevent conditions that can result in incorrect list size results.