Sent from Customer.io: How we decide which moments get a message 

Every product generates a flood of behavioral data. Someone logs in. Someone downloads a guide. Someone clicks into a feature they've never touched before. For PLG companies especially, all of that activity is tempting to react to.

We use Customer.io to run our own customer messaging, so the events we're deciding whether to act on are the same events any product-led team is staring at: content downloads, feature adoption, logins, plan changes.

This post walks through how we decide which moments are worth a message, how the same event means something different depending on what someone's done before, and how we message people through our own feature launches using in-app.

• Event-based triggers decide who gets messaged and when, but the same event (a content download, a login) can route to completely different journeys depending on history and engagement score
• A first-time content download starts a nurture sequence, a third download from the same person skips straight to delivery, because repeat behavior is a stronger intent signal than a single action
• New feature launches get in-app messages first, because that's where a user's attention already is when the feature ships
• Engagement scores update on every event, factoring in whether the person is already a customer, which changes how aggressively we message them going forward
• None of this holds up without reliable delivery: Customer.io processes multi-channel sends at 99.98% infrastructure uptime, and sent 100B+ messages in 2025

An event only becomes a trigger once it clears two questions:

1. Does this tell us something new about the user?
2. Is there something useful to say right now?

A login on its own usually fails both tests, so it only updates a profile. A content download, a feature click, or a plan change usually passes at least one, which is why those are the events we build journeys around.

The trigger itself lives in a journey in Customer.io: when a customer.io event fires (say, content_downloaded), it checks conditions like download count, engagement score, and customer status before deciding what happens next. The event is the entry point, and everything after that is based on who the user is and the contextual data we have associated with their profile.

Someone downloading a piece of content for the first time gets added to a content nurture track. Someone downloading their third piece of content from us gets the next piece delivered directly, no nurture in between.

Engagement scores update on every download regardless of which branch someone's in. That score factors in whether the person is already a customer, how recently they've engaged, and what they've downloaded before. It's the variable that decides how quickly someone moves from "nurture" to "direct" as their behavior repeats.

We lead with in-app for many of our user actions, because that's where the person already is when a new feature ships or when they need help with a specific feature. When we shipped an LLM step for automations, the in-app message showed up right where someone was already building, named what the feature does, and pointed to a course for anyone who wanted more depth before trying it.

For broader launches, we send a "what's new" recap in-app that groups several shipped features into one message, links out to a deeper look, and lets people opt into an RSVP if they want a walkthrough.

The first message someone sees after signing up is an in-app nudge to finish setup, not an email. It's timed to the moment they're already in the product looking for what to do next, and it's built to feel like a next step rather than a sales touch. If someone hasn't invited teammates yet, a second in-app follows: a direct nudge to bring in the person who'll help with data setup, because account setup is rarely a one-person job.

Both messages are triggered off account state, not off a calendar. Someone who invites a teammate on day one never sees the invite nudge. Someone who hasn't touched setup after a few days sees the onboarding nudge again, through a different channel.

Timely triggers are only as good as the infrastructure behind them. A journey that's supposed to fire the moment someone downloads their third asset is worthless if the send lags by hours, or if it doesn't land at all.

Customer.io runs at 99.98% infrastructure uptime and sent 100B+ messages across channels in 2025, process 12B+ API calls daily, and send at rates above 20,000 requests per second.

For a PLG company, deliverability and reliability are what determines whether a well-timed trigger actually reaches someone at the moment it matters, or shows up late enough to feel irrelevant.

A welcome series doesn't know if someone opened your product yesterday or never opened it after signing up. It knows it's day three, so day three's email goes out regardless. That's the downside of calendar-based lifecycle marketing: it treats "days since signup" as a stand-in for intent, when the two often have nothing to do with each other. Event-based messaging swaps the stand-in for the real thing.

Calendars still earn their place: renewal reminders, monthly digests, anything tied to an actual date rather than a guess about engagement. The distinction worth drawing per message is whether it's responding to something the person did, or to the fact that a certain number of days has passed. A program built mostly on the second answer is a newsletter with conditions attached, not lifecycle marketing.

We build our own messaging the same way: nurture sequences keyed to download count, feature launches matched to what someone's built, onboarding nudges tied to what's been set up rather than days elapsed. It takes more setup than a drip sequence. It also means the message someone gets reflects what they did, rather than only when they signed up.

• Filter every event through intent and usefulness before it becomes a trigger. If a message wouldn't add anything, let the event update the profile instead.
• Let repeat behavior change the journey, not only the profile. A third action deserves a different response than a first one.
• Update engagement scores on every event, and factor in customer status. The same behavior means something different from a prospect than from an existing customer.
• Match the channel to where attention already is. New feature adoption belongs in-app, not in an email someone won't open until after they've already found (or missed) the feature.
• Trigger onboarding and setup nudges off account state, not off a fixed send schedule, so people stop seeing prompts for things they've already done.
• Treat delivery reliability as part of the strategy. A perfectly timed trigger on unreliable infrastructure is a delayed message.

What is event-based messaging? Event-based messaging sends a message in response to something a customer does, like downloading content or logging in, rather than on a fixed schedule. The trigger is the action itself, not the calendar.

How does customer engagement scoring affect which message someone gets? Engagement scores factor in behavior history and customer status to decide how a person moves through a journey. A high engagement score can shift someone from a nurture sequence to direct delivery, and it updates with every new event.

Why do in-app messages work well for feature launches? In-app messages reach people while they're already active in the product, which is when new feature context is most useful. That timing tends to matter more than the channel itself for adoption-focused messages.

What's the difference between a first-time and repeat customer journey? A first-time action typically starts a longer nurture sequence meant to build familiarity. A repeated action is a stronger intent signal, so the journey usually skips straight to more direct content or outreach.

Does message volume affect delivery reliability? It can, if the underlying infrastructure isn't built for it. Customer.io is built to handle multi-channel sends at enterprise scale while maintaining 99.98% infrastructure uptime, which is what makes event-based triggers dependable rather than aspirational.

Can this approach work for any PLG company, not only ours? Yes. The mechanics (event triggers, engagement scoring, channel matching) apply to any product generating behavioral data. The specific thresholds and journeys should reflect your own customers' behavior, not ours.