Using Product Usage Context in Email Body Copy

Most SaaS email still runs on a static label from day one: a plan tier, a first name in the merge field, maybe a role picked at signup. This piece is about what happens when that label stops matching reality, and how product and growth teams can build copy from what a person is actually doing inside the product instead. Get this wrong and personalization becomes decoration. Get it right and it becomes the entire argument for the email.

What product usage context actually is, and what it is not

Start with the negative case, because most teams get this wrong before they get anything right. A first name in a subject line is not product usage context. A plan tier used as a stand-in for behavior isn't either, since "Pro" tells you what someone pays, not what they do. A role selected at signup, treated as a permanent descriptor six months later, is a static label wearing a personalization costume.

Product usage context is a record of what a specific person has actually done, or conspicuously not done, inside the product, tied to a timestamp and a workflow. That's the whole definition, and it requires two layers working together. Teams that only build one end up with copy that's technically accurate or actually useful, rarely both.

The first layer is product events: a feature getting triggered, an export running, a report getting created, a flow completed. These need to arrive in close to real time through a JS SDK, an HTTP API, or a webhook. A nightly CSV import doesn't cut it, because the delay between action and delivery breaks the timing that makes the message relevant.

The second layer is database state: plan, role, permissions, which features the account can even access. Database state is what keeps an event from becoming an embarrassment, since an event without it can produce a message recommending a feature the recipient's plan doesn't include. Database state without events just reproduces the static-segment problem from the top of this section, dressed up as something newer.

Here's where most vendors overstate what they've built. Tools that trigger on a tag or a list membership are not event-based, no matter what the pitch deck says. Tagging treats "did this thing once" as a permanent attribute stapled to the record. Genuine event-based systems stitch a person's full history into one profile, so a segment can reference what they did last week instead of a label someone assigned in January. That distinction, tag versus stitched history, is the whole difference between context and decoration.

One more layer worth naming: in B2B SaaS, the account and the individual person inside it carry different signals and deserve different messages. An admin needs setup guidance. A frequent user of one workflow needs depth on that workflow. Sending both the same message because they share an account ID throws away half the context already sitting in the database.

The behavioral signals worth building copy around

Not every event in a product analytics table deserves to become an email. The ones worth using share one trait: they imply a clear next action, not just a data point.

A few categories carry that weight. A user who opened a feature, started a flow, and didn't finish it is showing friction or uncertainty, not disinterest, and the copy should treat those differently. A user on a plan that includes a feature, with the right permissions, who has simply never triggered it, is showing unawareness rather than rejection. Someone doing manually, and repeatedly, what the product could automate is handing over the entire pitch: the gap between what they do and what the product can already do is the copy. Someone who tried a feature exactly once and never returned is telling you the first attempt didn't produce a clear win. Someone who just finished a significant workflow is sitting in a natural moment to hear about the feature that extends what they just accomplished.

Timing changes what these signals mean, and this is where a lot of teams miss the point entirely. A feature untouched for seven days carries different urgency than one untouched for ninety, even though both technically qualify as "hasn't used it." Reforge's product analytics database found that users who engage with a new feature within their first week show 3.7x higher six-month retention than users who delay past thirty days. That's not a footnote. It means the same behavioral signal, read at two different points in time, should produce two different messages, or in some cases no message at all versus an urgent one.

Low-signal events belong on the cutting room floor. A page view without action, a login with nothing behind it: neither connects to a next step, and copy built on them reads as vague because it is vague. Role and plan still matter, but as constraints rather than triggers. They tell you what you're allowed to say, not why you're saying it.

How to translate a behavioral signal into email copy that feels natural

A product event is a row in a database. Email copy is a sentence someone reads on their phone between meetings. Most teams flatten that gap into something robotic, or overcorrect into something that sounds like it's reading the user's diary back to them.

The governing principle is easier to state than to apply consistently: reference what you know about the person's workflow, not the fact that you tracked them. "We noticed you haven't used Bulk Export yet" announces the surveillance. "If you're still exporting records one at a time, there's a faster path" gets to the same behavioral implication without saying it out loud. The information content is identical. The feeling is not, and that gap is the entire skill.

A few moves make that shift work in practice. Name the workflow gap instead of the feature gap, describing what the person is probably doing manually before introducing the feature as the fix. Anchor to recency when it strengthens the pitch: "you just ran your first report" sets up "here's what most teams do next" using a real moment instead of manufactured urgency. Use role to make the use case concrete rather than generic, since an admin and a regular team member might lack the same feature for entirely different reasons. And frame absence as ongoing reality, not failure: "still doing X" describes where someone is right now, while "haven't done Y" implies they were supposed to and didn't.

Two examples show this working at different scales. Canva's email about unused AI credits frames the gap as money left on the table, a cost to the user, rather than a shortcoming in their behavior. Rebrandly's product release email leads with an outcome, "compare clicks and conversions," instead of the feature name, which keeps the copy in plain language without asking the reader to learn new terminology just to understand the pitch.

There's a quieter version of this that works as re-engagement: showing someone what they've already done. A usage-review email built around "you've done X" pushes harder toward a second feature than one built around "you're missing Y," because it starts from accomplishment instead of deficiency. None of this matters, though, if it doesn't survive the subject line. About 47% of recipients decide whether to open based on the subject line alone, so the behavioral signal driving the body copy needs to show up there, not get saved for the first paragraph.

Where context becomes surveillance, and the line product teams need to hold

Full behavioral visibility creates a temptation worth naming directly. A team with complete event history can write copy that lists exactly what a user did, when, and how often, and every word of it will be true. It will also feel invasive, and accuracy doesn't fix that. Truth is not the same as tact.

Certain moves reliably cross the line. Reciting a sequence of actions ("On Tuesday you opened the dashboard, clicked Reports, and closed it without saving") is accurate and unsettling in equal measure, and it tends to produce the opposite of the intended reaction. Phrasing that implies continuous, granular monitoring, rather than an understanding of a workflow, pushes the recipient toward the same discomfort. So does building a whole message on a single, ambiguous action: weak evidence produces presumptuous copy, even when the underlying tracking is perfectly sound.

The test that matters is simple. Would the recipient feel understood, or would they feel watched? The same fact lands either way depending entirely on the framing around it, which is why translation, the work covered in the last section, isn't a stylistic nicety. It's the mechanism keeping context from curdling into surveillance.

Skipping deserves to be treated as a real outcome, not a failure state. When the evidence behind a message is thin, one event, ambiguous intent, nothing to corroborate it, not sending is the correct call. A message built on weak evidence damages trust more than silence does, and teams that measure themselves purely on send volume will keep making this mistake.

Frequency compounds the same risk differently. A string of emails, each one individually well-framed, each one referencing something recent, adds up to a pattern that feels like monitoring even when no single message does. Frequency caps and quiet hours belong at the send-time decision layer itself, not bolted on afterward to fix a system that over-contacts by default. And some people should sit outside the system entirely: explicit opt-outs, recently churned accounts, anyone who's signaled discomfort. That exclusion has to hold at the moment of execution, not just get noted in a campaign brief and forgotten.

How the signal-to-copy process works at the level of a real campaign

A campaign starts with a specific adoption gap, not a vague engagement goal. "Improve engagement" doesn't tell anyone what to build. "Get users who export one record at a time to successfully use bulk export" does.

From there, the eligible cohort has to answer three separate questions, not one. Does the person have access to the feature, checked against plan and permissions in the database? Have they not yet used it, checked against event history? And have they actually shown the workaround behavior the feature is meant to replace? A person can pass the first two checks and still not belong in the send, because being technically eligible for a message and actually warranting one are different questions. Eligibility defines who could receive it. It says nothing about who should.

The approval structure follows from that distinction. A person approves the campaign's goal, its eligible audience, its copy guidance, its send limits. Individual messages then get executed inside those approved parameters, evaluated person by person, rather than approved one at a time by a human reviewing every send. That's the only way this scales past a handful of users.

What happens after the send is where most measurement stops too early. Opens and clicks aren't the outcome that matters here, actual product behavior is: did the recipient go use bulk export. Research from 2025 found that each additional core feature adopted reduces churn probability by 8 to 12%, and accounts using five or more features retain at 94% annually versus 62% for accounts using only one or two. That's the number the campaign should get judged against, not the open rate sitting in the email dashboard.

One honest caveat belongs here: a user who adopts the feature after getting the message might have adopted it anyway. Observed adoption confirms the outcome happened. It doesn't prove the email caused it, and teams treating every post-send adoption as a marketing win are fooling themselves a little.

The infrastructure that makes behavior-grounded copy possible, and where teams get stuck

None of the copy described above works without instrumentation underneath it. Behavioral email copy is only as good as the events feeding it, and when a key action isn't tracked, the system quietly falls back to static segments, whether anyone notices or not.

Genuinely event-based infrastructure needs specific pieces: a JS SDK, HTTP API, or webhook accepting structured events with properties, arriving close to real time, event stitching so a person's full history lives as one profile instead of a scattered pile of disconnected timestamps, and segment logic capable of referencing what someone did last week rather than a static attribute someone set by hand months ago.

Teams get stuck in a few predictable spots, and the most common one is mistaking tags for behavior. Triggering on tag application or list membership does not meet what this kind of copy actually requires. Some track events at the account level without identifying which specific person triggered them, a real problem in B2B SaaS where the admin and the end user need entirely different messages from the same account activity. And some instrument events cleanly but never connect them to database state, which is exactly how a feature-use event turns into a message recommending something the recipient's plan doesn't even include.

Getting this right pays off in measurable ways. Personalized subject lines get meaningfully higher open rates than generic ones. That specificity has to survive the format it's read in, too: a majority of email opens now happen on mobile, where Gmail's app shows roughly 37 characters of email preview text and iPhone Mail shows around 40. Behavioral specificity has to land in the first few words or it doesn't land at all.

The gap between average and strong execution is wide. Average core feature adoption sits around 24.5%, while the top quartile of teams clears 45%. Some of that gap is strategy. A meaningful part of it is just infrastructure, teams that built the instrumentation properly versus teams still running on tags and static lists.

AI agents in this workflow: what they handle, what still requires human judgment

AI agents have a real, bounded role here, and it's worth being precise about where that role starts and stops. They're well suited to evaluating each eligible person's signals independently against a campaign's criteria, since that's a repetitive judgment call applied at volume. They can write copy grounded in one specific person's behavioral context instead of a template with merge tags dropped in. They can decide, at the moment of sending, whether the evidence clears the bar set for that campaign, and skip the send when it doesn't. And they can check, afterward, whether the recipient's product behavior actually matched the campaign's intended outcome.

A few production examples show what this looks like: agents writing customer-facing emails from real-time product data and internal playbooks, sentiment-detection agents connecting dissatisfaction signals back to specific product gaps, and agents that take a natural-language prompt describing an outcome and decompose it into the subtasks and campaign logic needed to build it. That's a distinct capability layer from older tools that just suggest subject line variants within fixed constraints.

What doesn't move to an agent is the upstream judgment: setting the campaign's goal, defining who genuinely belongs in the eligible audience, setting the copy guidance and send limits the agent then operates inside. Those decisions carry real consequences for how a user experiences the product. They still need a person weighing them, because agents work well inside boundaries someone else has to draw first, and no agent should be the one drawing them.