Quick definition: Audience targeting is the process of selecting the users, accounts, devices, locations, or request contexts that may receive a product experience, message, feature, or experiment. In testing, it defines where a result can reasonably be applied.
What is audience targeting?
Targeting rules can use pre-existing attributes such as country, language, device capability, app version, account plan, acquisition channel, lifecycle state, or product settings. They can also use contextual facts, such as whether a request is for a supported page. A rule may include or exclude an audience, allocate a percentage of it, or route it to a different experience.
Targeting is broader than randomization. Randomization decides which variant a qualifying unit receives; targeting decides which population reaches that decision. It is also different from personalization: a personalized experience may choose content for each user without a randomized comparison. And it differs from feature access, although the same rules often support both.
For an experiment, targeting is part of the scientific scope. A test conducted only among English-speaking, logged-in mobile users can support a conclusion about that prespecified population, not necessarily about anonymous visitors, desktop users, or all customers. The narrower scope may be exactly right when a feature is unavailable or irrelevant elsewhere.
Building reliable targeting rules
Start with a product reason. A collaborative workflow may require accounts with two active seats; an iOS interaction should target supported app versions; a regulated offer may be available only in permitted jurisdictions. Translate that reason into explicit, testable predicates and identify the source of each attribute. Prefer stable, pre-treatment data where possible.
Rule order matters when exclusions overlap inclusions. Document whether internal accounts, employees, bots, consent-restricted users, ongoing migrations, or existing feature users are excluded before allocation. Decide the unit: if a setting is account-wide, account-level targeting prevents teammates from receiving incompatible experiences. If an experience is a single request-level recommendation, request context may be the appropriate unit.
Version target definitions. Product databases change, identity joins can fail, and a seemingly innocuous new default can widen an audience. A version ID, evaluation timestamp, and reason code for each inclusion or exclusion make launch behavior auditable. Do not rely only on a dashboard’s current rule representation after the rule has changed.
Targeting and experimental validity
Prespecify the target audience before looking at results. Selecting a subgroup because it appears to perform well after treatment begins creates a post-hoc comparison and increases the risk of misleading findings. Similarly, do not require a behavior that treatment could influence—such as clicking a treatment-specific control—as an inclusion condition for the main analysis. That can introduce post-treatment selection bias.
Log the funnel from potential traffic to eligible units, assigned units, delivered units, and observed outcomes. Compare allocation by high-level target dimensions; an unexpected imbalance can signal identity, caching, or implementation defects. If a rule changes during the run because of a legal, operational, or product requirement, record the cutoff and consider analyzing phases separately. The original estimand may no longer describe all observed traffic.
Targeting can improve safety and signal by avoiding unsupported users, but it reduces sample size and external validity. It also interacts with subgroup analysis: a deliberately targeted audience is not a license to make unplanned claims about every subgroup within it. Estimate uncertainty and avoid overstating a small segment’s result.
Concrete engineering and product scenario
A B2B platform tests a shared approvals workflow. The feature needs two or more active account members, so the experiment targets paid accounts meeting that condition, on supported browser versions, excluding employees, test tenants, and accounts in a migration. Assignment is persisted at account level so all members see the same workflow. The user interface receives a target-rule version and experiment ID from the backend.
The team records why every evaluated account was included or excluded. Its launch dashboard shows eligible accounts, assignment split, render success, approval completion, support contacts, and latency. When a migration rule is updated halfway through, the team records the effective date and does not pool the new audience indiscriminately with the original one. A positive result is described as evidence for eligible collaborative paid accounts, not every account on the platform.
Monitoring and diagnostics
Monitor audience size and composition over time, inclusion and exclusion reason counts, missing-attribute rates, allocation by target dimension, and assignment stability. A sharp drop can expose a broken identity feed; a sudden growth can signal a default value that changed meaning. Examine diagnostic samples for boundary cases and test rule evaluation against fixtures representing consent changes, old app versions, bot traffic, and account merges.
Respect privacy and fairness constraints. Do not collect or use sensitive attributes without a justified, permitted purpose. Derived segments can still be sensitive, and targeting criteria may produce disparate delivery even without using a protected attribute directly. Involve the relevant privacy, legal, and product owners for high-impact decisions.
Trade-offs and limitations
Focused targeting protects users from incompatible experiences and can make a hypothesis more precise. It adds rule complexity, can shrink power, and limits generalization. Real-time targeting may be fresh but slow or failure-prone; cached targeting may be fast but stale. A default path must be safe when attributes are unavailable.
Targeting does not establish causality by itself. A carefully selected audience still needs appropriate assignment and measurement. Nor does it justify excluding inconvenient users after outcome data are known.
Common failures
- Changing rules to improve a result: this changes the population after observing evidence.
- Post-treatment filters: engagement caused by a variant should not define primary eligibility.
- Unlogged exclusions: analysts cannot audit the denominator or diagnose a traffic drop.
- Wrong unit: user-level rules can give one account conflicting account-wide experiences.
- Overgeneralization: a result for a narrow audience is not evidence for everyone.
FAQ
Is audience targeting the same as eligibility?
They overlap. Eligibility is the explicit set of units that can enter a decision; targeting is the broader operational act of selecting and routing an audience. See audience eligibility.
Can targeting use behavior?
Yes, when the behavior is measured before assignment and has a product justification. Avoid using behavior that treatment can change for the main experimental denominator.
Should we target by country using IP address?
It can be practical, but IP-based location is imperfect. Define a fallback and avoid treating it as a precise legal or identity attribute without appropriate validation.
What happens when a target attribute is missing?
Specify a conservative default, log it, and monitor the missing rate. Do not let an undocumented default silently broaden exposure.
Summary
Audience targeting determines who can receive an experience and therefore the population behind an experiment’s claim. Use prespecified, versioned, pre-treatment rules; record inclusion and exclusion reasons; monitor composition and delivery; and state conclusions at the scope the rule supports.