How QAiry Works

‍

Most audience requests in Salesforce Marketing Cloud start the same way. Someone on the marketing team knows exactly who they want to reach, and someone else has to turn that into SQL.

That handoff is where the days go.

QAiry removes the handoff. You describe the audience in plain language, QAiry produces the query, and you keep control over what actually runs.

‍

This post walks through what happens between your first sentence and a populated data extension.

There are five steps, and none of them require you to open a query editor.

‍

What SFMC segmentation costs you today

‍

The queue is the real bottleneck

In most orgs, the SQL itself is not the hard part. Waiting for someone with the skill and the time to write it is.

A campaign brief lands on Monday. The query request goes into a backlog. The audience arrives Thursday, and by then the offer has changed.

‍

The cost is not one query. It is the segmentation ideas that never get requested because the round trip is too slow to be worth it.

‍

Institutional knowledge lives in a few heads

Knowing that engagement history sits in system data views rather than in your own tables is learned knowledge.

So is knowing which of your forty data extensions holds the current subscriber status, and which one is a stale import from a migration two years ago.

‍

When that knowledge sits with two people, every audience depends on their calendar.

‍

It also makes the work fragile. When one of those people changes role, the queries stay behind but the reasoning behind them does not.

Teams end up reusing old SQL they cannot fully explain, adjusting a date here and a table name there, and hoping the rest still holds.

‍

Step one, QAiry maps your SFMC data

‍

Reading data extensions and their fields

Before QAiry writes anything, it builds a picture of your account: which data extensions exist, what fields they contain, and how those fields are typed.

That map is what lets a request like customers in Belgium who bought in the last 90 days resolve to real column names instead of guesses.

‍

It also means QAiry can tell you when the data you are asking for is not in the account at all, which is a far better answer than a query that silently returns zero rows.

‍

Knowing which data views are available

Engagement history in Marketing Cloud does not sit in your data extensions. It sits in system data views such as _Sent, _Open, _Click, _Bounce and _Unsubscribe, which you query through Automation Studio.

These views have their own rules. Salesforce updated its retention policy on 16 June 2025 so that subscriber engagement data is kept for 730 days, which means anything older than that window is simply not there to query.

‍

QAiry treats those views as first-class tables, so a request about openers or bouncers routes to the right place automatically.

‍

Step two, you describe the audience in plain language

‍

What a useful request looks like

You do not need to phrase anything like a query. A sentence works.

Everyone who received an email in the last 60 days, never opened, and is not already on the suppression list.

‍

That single sentence contains three separate table lookups, a date window and an exclusion. QAiry's job is to unpack it, not to make you unpack it first.

‍

What happens when the brief is ambiguous

Real briefs are rarely complete. "Recent buyers" could mean 30 days or a quarter, and "active" means something different in every org.

Rather than pick silently, QAiry asks. One short question, then it proceeds.

‍

This matters more than it sounds. A query that runs perfectly against the wrong definition is worse than no query at all, because nobody catches it until the send report looks strange.

‍

Step three, QAiry writes SFMC-shaped SQL

‍

Choosing the tables and the joins

Once the intent is clear, QAiry assembles the query: which tables to hit, how to join them on SubscriberKey, how to express the date window, and where the exclusions belong.

Joins are where hand-written SFMC SQL usually goes wrong, particularly when engagement data is combined with a profile or purchase table and duplicates quietly multiply.

‍

Because QAiry knows the shape of both sides of the join before writing, it can pick a grain that returns one row per subscriber.

‍

Writing for the platform's constraints

Marketing Cloud SQL is not generic SQL. Query activities time out after 30 minutes, and the more data a query touches, the more likely it is to hit that ceiling.

Salesforce's own guidance is to narrow scope aggressively and to name the exact fields you need rather than reaching for SELECT *.

‍

QAiry writes to those constraints by default: explicit field lists, tight date filters, and no unnecessary passes over large tables.

‍

The same applies to functions. Date arithmetic built on GETDATE() behaves differently from the hard-coded dates people often paste in from a previous campaign.

A query written with a moving window keeps working next month. One written with fixed dates quietly returns the wrong audience the moment nobody remembers to edit it.

‍

Step four, you review before anything runs

‍

Reading a query you did not write

QAiry returns the SQL along with a plain-language explanation of what each part does.

You do not have to be able to write the query to check the logic. You have to be able to confirm that "last 60 days" means what you meant and that the exclusion list is the right one.

‍

If something is off, you say so in the same conversation and the query is rewritten. No new ticket, no new wait.

‍

Checking the size before you commit

An audience of 12 when you expected 120,000 usually means a join went wrong or a filter is too tight.

Seeing the count before the audience is used gives you a cheap sanity check on logic that would otherwise only surface after a send.

‍

It is also the moment to compare against what you expected. If last month's equivalent audience was 90,000 and this one is 400,000, something in the definition drifted.

Catching that before the send costs a minute. Catching it afterwards costs a deliverability conversation.

‍

Step five, the audience lands in a data extension

‍

Target data extension and data action

A query activity in Automation Studio writes its results to a target data extension, and you choose how: Append, Update, or Overwrite.

That choice has consequences. Add and update operations spend most of their runtime checking whether each row already exists, which is a common reason a query that used to finish in minutes starts brushing against the timeout as data grows.

‍

QAiry surfaces that decision instead of burying it, so a refresh-every-morning audience does not accidentally become an append-forever table.

‍

Reuse and scheduling

Once an audience is right, it rarely stays a one-off. The same logic gets reused with a different date window, a different market, or a different product line.

Because the query is saved and readable, adjusting it is a sentence rather than a rebuild.

‍

• Same logic, new date window
• Same logic, different business unit
• Same logic, scheduled to refresh before each send

‍

The result is a library of audience definitions your team can actually read, rather than a folder of queries only one person understands.

‍

See QAiry in action

‍

The short version: you describe the audience, QAiry maps your data, writes the SQL, explains it, and writes the result to a data extension you control.

If you want to see that run against a real brief, there are recorded walkthroughs at qairy.com/product-demos, or you can try it on your own account at qairy.com/try-it-free.