Typical causes

A query is simply a set of instructions within Campaign. It does not possess records in the way that contact Lists retain them. When a query is calculated, those "instructions" are executed against the database and whoever matches the criteria at the time the query starts processing will be included.

• If an email, SMS, or push message is sent against a query after calculation, Campaign always evaluates the query again, so if a contact's field values have changed in a way that excludes them based on the same criteria between the calculation and the send, they will not be included in the send.
• For clients with flexible databases, email may not be a required field; It's possible for a record to have no value in the email field. query calculation does not require email unless email is specifically referenced in its criteria. However, email is required for an email type send, so only contacts who match the query criteria and have an email listed are eligible for the email. If you are calculating a query specifically to determine approximately how many emails will send, it's a good idea to add criteria stipulating "AND Email is not blank".
• Similarly, for SMS/push, a query might not explicitly state that contacts must be opted in to a certain Mobile App or Text to Join Program, but SMS/push sends only go out to contacts who match the query criteria AND are opted in to the app/program used for sending.
• When Campaign evaluates which contacts to include in a mailing, it interprets behavioral criteria that leverages ‘Today’ as the time the mailing was scheduled. This differs from how a query calculation operates, which is to evaluate ‘Today’ as whatever the system time is. If you schedule a mailing to send on June 15th and it goes to an approval group to review, and they wait a few days to approve the mailing, this can result in different contacts being sent the mailing than what currently exist in the query because criteria like ‘Has been sent mailing [x] before Today’ really means ‘Has been sent mailing [x] before June 15th’

Troubleshooting

The best way to troubleshoot is to identify at least one specific contact who you believe should/should not have been included in the send. Even if there are hundreds of thousands of contacts in question, asking narrow questions of the data will save you time, so identifying those example contacts is key. Obtaining the recipient ID(s) along the way might also prove helpful in case you do need to create a support ticket, as recipient ID is the Campaign unique identifier that ties together the backend data leveraged by Queries.

After isolating the issue down to a few contacts, verify that their data hasn't recently changed. The last modified column within the database search for the record will indicate the last change though it won't illuminate what changed. You will want to prioritize finding contacts who have older last modified dates since their data is more likely to be the same as it was in the past.

If the query references data outside of the database itself, such as relational table criteria or send history, then you will want to verify that this data remains the same as well. Relational Table records do not show the last modified date in the UI, but you will at least want to check that a matching record exists for the contact (based on the mapping). Send history is often a "trending" reference that stipulates a contact must have been sent "in the last 30 days". Because of the trending nature, you may need to note the exact send date and email you believe should/should not have included them in the send.

Following your own troubleshooting, if you still believe certain contacts should/should not have been sent, then you may create a Support case with the proof you've obtained while troubleshooting.

Support Limitations

Support will be happy to investigate but may not be be able to prove anything went unexpectedly if the data or query has changed. Here are some limitations to be aware of:

• Campaign does not retain the previous field values of contacts, so after a contact has been modified no one can be sure what exactly their field data was before the modification date. In the same way, if relational table data has been updated or removed, support is unable to see the previous records or values.
• In the majority of instances, query criteria is completely overwritten with each save to the query. support is not able to see what the criteria was before the last configuration, so it's highly advised that you not modify a query in any way following a send if you believe there was an issue. If you need to reuse the query, then performing a "Create Like" on the query is preferred.

If the query has been modified since the issue's occurrence and/or the underlying data has changed, then a reason may not be found for the discrepancy.