Defining a Campaign Goal and Audience Before Writing a Single Word

A SaaS feature campaign dies long before anyone opens an email editor. Everything downstream, from subject lines to send cadence, inherits that failure.

Why Feature Campaigns Fail Before the First Word

A product team ships a new feature. The announcement goes out to the full user base. The actual cause sits upstream of all three: no one wrote down what "success" meant in terms of a specific behavior, and no one specified which users were in a position to take that step at the moment the message arrived.

Three structural failure modes follow directly from skipping these two decisions. The team can't tell whether the next campaign should look different, because nothing about this one was specified clearly enough to learn from.

The fix starts before any copy gets written. It starts with two questions: what specific behavior change is this campaign trying to produce, and who is actually eligible to produce it right now. The rest of this piece works through both.

What a campaign goal means: behavior change, not a send metric

A campaign goal names a specific, observable behavior that a defined person hasn't performed yet but is capable of performing now.

Descriptive metrics like opens, clicks, and impressions tell a team the message arrived somewhere. Treating that open rate as a success metric mistakes delivery for outcome.

A workable goal statement needs four components. It names the feature or workflow in question. And it names what durable use looks like, since a single click on a feature is not the same claim as a habit forming around it.

Take a vague goal like "increase awareness of the new reporting feature." Rewritten as a behavior-change goal, it reads: "Get users who have created at least one dashboard to export their first report within 14 days of dashboard creation, and get them to repeat that export at least twice within 30 days." The second version can be measured. The first version can't, because awareness isn't a product event; it's a mental state nobody can query.

That rewrite rules out a whole category of goals that sound reasonable but defer the real objective somewhere unmeasurable. "Improve NPS" measures a survey response that may have nothing to do with the feature the campaign is about. Both goals push the actual question (did behavior change?) downstream of anything the campaign can observe.

B2B campaigns carry an added wrinkle: the unit of activation is often the account, not the person. A collaborative milestone, three teammates on an account using a shared workspace feature together, is a structurally different goal than one person trying the feature solo. A campaign brief has to say which of these it's chasing, because the eligible audience and the message both change depending on the answer.

This is the distinction behind why adoption platforms like Userlens are built on the premise that a goal has to specify the behavior change to measure, not a send volume, so the system can later query actual product data to confirm whether that behavior occurred. A goal stated as a metric the platform can check against events and database records is a different kind of object than a goal stated as an intention.

Activation Events and Time Windows in the Brief

A behavior-change goal is incomplete without two more pieces: a precisely defined activation event, and the time window in which hitting that event actually matters. Both belong in the brief before a single message goes out.

An activation event is a specific product action that signals real value was experienced, a first dashboard built, a first file shared, a first report exported. An activation event measures a person doing the thing the product is actually for.

Research summarized in available time-window studies shows that users who hit a key milestone within a short early window after signup retain at substantially higher rates than users who reach that same milestone later. That gap is the entire argument for front-loading outreach toward the start of a user's lifecycle rather than spreading messages evenly across a 90-day drip sequence. If the data says early matters, the campaign has to act early, not eventually.

Acting on that requires tracking the activation event at the individual level and measuring the actual time from signup to activation for each user, not an aggregate rate across the whole base. A 24.5% activation rate across a cohort hides the fact that a user who activates in hour one is behaving nothing like a user who activates on day three. Averaging the two together erases the signal the campaign needs to act on.

Superhuman's onboarding history illustrates the sequencing to pay attention to here, not a template to copy wholesale, and the order mattered: humans worked out what fast value actually looked like for a given user before software was asked to detect and scale that pattern. A smaller SaaS team without the resources for concierge onboarding can still take the lesson, which is to find the real activation event through direct observation of early users before trusting an automated system to find it for them.

Writing the activation event and its time window into the brief before any outreach happens lets the campaign operate on a different footing entirely: reaching a specific person at the moment their behavior shows they're ready, instead of broadcasting to everyone and hoping something lands. That's the line separating a campaign from a broadcast, and it's the premise behind how account intelligence platforms approach adoption work in general.

Defining the eligible cohort: who can take this step right now

With the goal and its timing specified, the next upstream decision is the audience, and "audience" here means something narrower and more precise than most teams assume.

The eligible cohort is the specific set of people who have completed whatever prerequisite behaviors the target feature depends on, who have not yet completed the target behavior itself, evaluated right now against two separate inputs.

Firmographic and time-based segmentation fails at this job for a simple reason: acquisition date and plan tier say nothing about whether someone has used the adjacent feature that makes the target feature useful, and nothing about whether their account is already covering this need through a competing workflow inside the product.

Two inputs define real eligibility. The first is product events, meaning behavior over time: has this person completed the prerequisite steps the target feature depends on, and have they already adopted the target feature themselves? The second is database state, meaning current account and role context: are they on a plan that includes this feature, does their role suggest they'd use it, and has the account already adopted it through a different user on the team?

The gap between what should be happening and what is actually happening is the signal to act on. A user on the identical plan who already uses that feature weekly is not, regardless of how recently they signed up or what tier they're on.

PLG teams get the most out of this by segmenting on behavior, usage patterns, activation milestones, feature adoption sequences, rather than on acquisition date or firmographic attributes that describe the account without describing its actual product use.

B2B introduces a further complication: people and accounts are not the same unit, and a cohort definition has to say which one it's measuring. If three of five seats on an account have adopted a feature, the remaining two users are individually eligible for a nudge, but the account itself isn't at churn risk on that particular dimension, because the workflow is already present inside the org. A campaign goal and its audience definition both need to specify which unit, person or account, the campaign is actually chasing.

What gets excluded from the eligible cohort matters as much as what gets included. Users who already perform the target behavior come out, because there's nothing left to prompt. Skipping a weak signal is part of a correctly specified cohort, not a deviation from it.

Writing an Eligible-Cohort Definition a Data Team Can Build

An eligible-cohort definition is a set of conditions written against data a team already has, specific enough that a query or an automated rule can evaluate each person independently. It is not a Venn diagram sketched on a strategy slide.

Four questions have to be answered in writing for the definition to hold up. What must be true about this person's past behavior, meaning which events they've completed and which features they've used? What must be true about their current database state, meaning plan, role, and account configuration? What must not yet be true: the target behavior hasn't happened, or has happened fewer times than some stated threshold. And what is the time window during which eligibility actually holds, after which the person either no longer needs this campaign or needs a different one?

That audit is the real test of whether the definition is any good. A RevOps engineer or a growth lead should be able to pick one specific person out of the cohort and explain, in plain language, why that person qualifies. If the explanation requires guessing, or falls back on "well, they're probably the kind of user who," the definition isn't specified tightly enough yet.

Being in the eligible cohort does not mean every person in it automatically gets a message. A cohort with ambiguous signal for a given individual should exclude that individual, even if they technically meet every stated condition.

Setting the measurement standard before the campaign runs, not after

The measurement model belongs in the brief next to the goal and the cohort definition, written down before the first message goes out, because a goal statement isn't actually complete until it's paired with a method for checking whether the behavior changed.

A well-defined goal implies a measurement ladder with several distinct rungs: eligible cohort size, then feature discovery (did the person encounter the feature at all), then first activation (did they perform the target action once), then repeated use within the defined window (did they hit the threshold number of times), then account-level adoption (did the role-appropriate users across the account reach repeated use), and finally NRR contribution.

Each rung can fail for a different reason, and knowing where the drop-off happens is the only way to improve the next cycle of the campaign. Collapsing all of that into a single "adoption rate" number throws away the information a team needs to fix anything.

A genuine limit applies here: observed adoption following a campaign is not proof the campaign caused that adoption. A measurement model built honestly notes this constraint rather than claiming credit for every adoption that happens to follow a send.

The metrics that hold up in a pipeline review are activation rate (the percentage of signups hitting a first-value milestone inside a target window), feature adoption rate, and net revenue retention. Opens and clicks don't hold up the same way, because they describe delivery, not outcome.

B2B measurement needs both a person-level and an account-level report. A single power user adopting a feature inside an account does not mean the account itself has adopted it, and a campaign that only reports person-level numbers can look like a win while the account-level picture stays unchanged.

The same upstream thinking extends to send logic: what counts as a non-response significant enough to justify a follow-up message, what counts as a signal too weak to act on at all, and how long the eligibility window stays open before a person gets reclassified into a different cohort. These aren't communication-team decisions made on the fly. They follow directly from how the goal and the cohort were defined in the first place.

What changes when goal and cohort are defined before any copy is written

Once a campaign has a specified behavior-change goal and a precisely built eligible cohort, writing the actual message turns into a constrained problem with a defensible answer for each recipient.

The question a writer asks changes shape. It's no longer "how do we announce this feature broadly." It becomes: what does this particular person need to do next, and what evidence from their own product use would make that next step feel like the obvious continuation of something they're already doing, rather than a generic pitch aimed at no one in particular.

Personalization that works means grounding a message in what a person has done and hasn't yet done inside the product, which is only possible when the cohort definition has already specified both of those things with precision.

For a long time, teams defaulted to broadcasting generic feature announcements because writing a distinct, evidence-grounded message for every eligible person wasn't practical at any real scale. That cost constraint has largely disappeared. If a team cannot say which behavior change counts as success, or which users are capable of taking that step today, there's no campaign to run, only a broadcast to send; the upstream work of defining goal and cohort is what separates the two. Tools like Lumi build on this premise directly: a campaign starts from an adoption goal and the audience that qualifies for it, then generates guidance personalized to each person in that audience, with a clear, auditable reason attached to every match.

That's the shift upstream definition makes possible. Specifying the goal and the cohort first turns a feature launch from a broadcast into a set of individual, evidence-based decisions, one per eligible person, each one answerable in plain language.