How QAiry Builds Production-Ready Audiences

‍

Most audience tooling stops at the moment the query is written.

That is the easy part. The hard part is everything between a query that returns rows and a data extension a campaign can actually send from.

‍

An audience is production-ready when it runs on schedule, writes to the right target, respects the send relationship, and does not quietly break the first time the underlying data grows.

In Salesforce Marketing Cloud, getting there usually takes several rounds between the marketer who wants the segment and whoever owns SQL in the org.

‍

This post walks through how QAiry closes that gap: what it reads before it writes anything, which SFMC constraints it builds around, and which decisions stay with you.

‍

What production-ready actually means in SFMC

‍

The audience has to survive the send

A query that returns the right people is not the same thing as an audience Email Studio will accept.

Sendable data extensions need a send relationship that maps a field on the extension to a subscriber, and SubscriberKey has to be present for that relationship to work. Without it, the rows exist but the send does not.

‍

The send relationship is also what ties each row back to All Subscribers, where subscription status is maintained across every email send.

Skip it and you have a list that ignores your own unsubscribes.

‍

The audience has to survive next month

The second failure mode is slower and more expensive.

A query that runs comfortably against 200,000 rows behaves differently at ten million. Salesforce is explicit that add and update query activities tend to increase in run time roughly linearly as the data footprint grows.

‍

Queries in Marketing Cloud also time out after 30 minutes, and the database enforces both hard limits, which reject a request outright, and soft limits, which you can exceed at the cost of performance.

Production-ready means the query was written with those ceilings in mind, not discovered against them at 3am.

‍

Starting from the request, not the schema

‍

How QAiry reads a plain-language brief

The starting point is a sentence a marketer would actually say. Something like "customers who bought in the last 90 days but haven't opened anything in 60".

QAiry parses that into its component parts: a population, one or more inclusion rules, one or more exclusion rules, and a time window for each.

‍

Each part then has to be bound to something real in your org. "Bought" is a table and a date field. "Opened" is the _Open data view joined on SubscriberKey. "Last 90 days" becomes a bounded expression rather than a hardcoded date.

‍

Where the ambiguity gets resolved

Natural language is ambiguous in ways SQL is not, and the useful behaviour is to surface that rather than guess.

Three questions come up constantly:

• Does "customers" mean everyone in the master extension, or only subscribed contacts?
• Is the 90-day window measured from the run date or a fixed campaign date?
• Should a contact with no engagement history at all count as unengaged?

‍

QAiry asks these back in plain language before generating anything. It is a short conversation, and it is the step that removes most of the rework.

‍

Grounding the query in your real data model

‍

Data extensions, fields and types

Generic SQL written without sight of your schema is a guess. It compiles in the abstract and fails in your org, usually on a column name or a type mismatch.

QAiry works from your actual data extensions: the field names as they exist, their data types, their lengths, and which field carries the subscriber identifier.

‍

That grounding is what lets it produce a query that runs the first time rather than one you spend twenty minutes correcting.

‍

Data views and their retention window

Engagement questions almost always route through the system data views: _Sent, _Open, _Click, _Bounce and _Subscribers.

These are queryable but they are not a full historical archive. They expose a rolling retention window, so a query asking about behaviour two years ago will return an empty result rather than an error.

‍

An empty result that looks like a valid answer is the most dangerous output in segmentation. QAiry flags when a requested window sits outside what the data views can actually answer, so the gap is visible before the send.

‍

Writing SQL that Automation Studio will accept

‍

The subset of SQL that runs in SFMC

Marketing Cloud runs a constrained dialect. It is close enough to standard T-SQL to be familiar and different enough to be frustrating.

Queries are SELECT only, and a long list of constructs available elsewhere are simply unavailable in a Query Activity.

‍

QAiry generates inside that subset by default: bounded date logic with DATEADD() and GETDATE(), exclusions expressed with NOT EXISTS rather than large NOT IN lists, and joins on indexed keys.

‍

Deduplication and the SubscriberKey rule

Duplicate rows are the quietest bug in SFMC segmentation, and joins against engagement data views produce them easily. One contact with four opens becomes four rows.

The audience then reports an inflated size and, depending on the target configuration, can send more than once to the same person.

‍

QAiry deduplicates on SubscriberKey as a default rather than an afterthought, using SELECT DISTINCT or a windowed row number when you need a specific record kept rather than any record.

‍

Choosing the target and the data action

‍

Overwrite, append or update

A Query Activity writes to a target data extension using one of three data actions, and the choice changes the meaning of the audience.

• Overwrite replaces the target contents on every run, which suits a recomputed segment.
• Append adds rows without removing anything, which suits an event log.
• Update matches on the primary key and refreshes existing rows.

‍

Picking the wrong one is a common cause of an audience that looks correct in week one and doubles by week three. QAiry sets the data action from the intent of your request and tells you which it chose and why.

‍

Making the target sendable

A target extension is only useful if the campaign can send from it, which means the send relationship has to be configured and SubscriberKey has to be carried through the query.

QAiry keeps the subscriber identifier in the output by default, so the extension you end up with is one Email Studio recognises.

‍

For very large add and update operations, Salesforce recommends staging results in an intermediate extension and letting an Import Activity handle the final write, since imports perform the same operation faster at scale.

‍

What happens after the first successful run

‍

Scheduling and failure notifications

A Query Activity can run once or on a schedule inside Automation Studio, and a recurring audience is where most operational risk lives.

Automations that fail repeatedly over an extended period get deactivated by the platform, with a notification sent to the address configured under Runtime Error or Skipped Run.

‍

That address is worth setting deliberately. A deactivated automation is silent otherwise, and silence looks exactly like success on a dashboard.

‍

Iterating without starting over

Real segmentation is iterative. The first version is directionally right, then someone asks to exclude a region, extend the window, or add a purchase category.

Because QAiry holds the audience definition in conversation rather than in a text file someone has to re-read, a change request is a sentence rather than a rewrite.

‍

The practical effect is that the person who understands the campaign is the person adjusting the audience.

‍

See QAiry in action

‍

None of this removes the need for governance. Someone still owns the data model, the naming conventions, and the decision about what a customer is.

What changes is the queue. The request that used to wait three days for a technical resource now takes a few minutes, and that resource reviews rather than transcribes.

‍

The shortest way to judge any of this is against your own data model, with a segment you have actually had to build before.

You can watch a walkthrough at qairy.com/product-demos, or start with your own SFMC org at qairy.com/try-it-free.