The 6 layers I build on every lifecycle marketing engagement.

By Ron Davenport. Published 2026-05-23.

$150K in 2024. $700K in 2025. 367% YoY. Thats the lifecycle revenue line at a DTC SaaS at ~$50M ARR where I joined as the lifecycle program had two things running: webinar invites and a salesy upgrade flow pushing trial users to higher tiers. No activation logic. No segmentation strategy. No dollar-tracked attribution. Lifecycle revenue lived inside the marketing forecast as a guess.

Twelve months later it was a $700K channel with attribution clean enough to show up in board decks. Nothing about that build was clever. It was the same six layers every operating lifecycle program runs on, and the work was making each layer agree with the others.

Tbh, lifecycle marketing gets confused with a campaign calendar, with a welcome series, with whatever the ESP UI lets you build. Its actually the system that watches what users do, decides what to say next, and reports whether it worked. Below is what it looks like when you build it end-to-end: the six-layer infrastructure, the ESP tradeoffs by stage, the org-headcount reality nobody else writes about, and the three case-study numbers underneath the methodology.

Every working lifecycle program runs on the same six layers. The ESP changes, the volume changes, the vertical changes. The layers dont. If any layer is missing, the ones above it run on assumptions.

1. Data layer

The events your product emits and the attributes you collect at signup. Account connected. Product imported. Trial started. Plan upgraded. Last-login changed. The data layer is the source of truth that every other layer reads from. If event names drift, if attributes are inconsistent, if engineering owns events but marketing owns the use, the layer above breaks silently. Most lifecycle problems are data-layer problems wearing a different hat.

The operator decision: build vs buy. A warehouse-first stack (Snowflake, BigQuery, Postgres) gives you flexibility and one place to fix things. A data-aggregator stack (Segment, RudderStack) gives you speed and integration coverage. Most teams under 50 employees should pick the second option and invest the saved time in segmentation. See when to build lifecycle infrastructure for the decision framework.

2. Segmentation layer

The rules that turn raw events and attributes into useful audiences. Trial users who connected an account but didnt import. Paid users dormant for 30 days. High-LTV customers approaching renewal. Free users who hit the activation milestone but didnt convert. Segmentation is where most teams get sloppy because they create one-off lists for individual sends and never name them, never document them, never reuse them.

The operator decision: where segments live. Inside the ESP (fast, but ESP-coupled). In a CDP-adjacent layer (slower, but stack-portable). Or computed in the warehouse (slowest, most flexible, hardest to staff). The right answer depends on how often segment definitions change. If they change weekly, ESP. If they change rarely and you have a data team, warehouse.

3. Trigger layer

The logic that decides what fires when. A user hits an activation milestone, and the trigger has to decide whether the next message congratulates them, pushes them to the next milestone, or stays quiet. A users payment fails, and the trigger has to decide whether to send the dunning sequence, escalate to CSM, or both. Triggers are where business logic lives. Most teams hide triggers inside the ESP, which means nobody outside marketing can audit what fires.

See behavioral conversion scoring for how to architect a trigger system that scores user behavior instead of routing on time elapsed since signup.

4. ESP / CRM layer

The execution layer. Klaviyo, Customer.io, Iterable, HubSpot, Marketo, SFMC. This is where messages actually send, and its the smallest part of the lifecycle program even though most teams mistake it for the entire thing. The ESP renders, schedules, and tracks. Dont ask it to also be the data warehouse, the segmentation engine, and the BI tool. It will do all three badly.

The operator decision: which ESP fits which stage. ESP choice is downstream of your data model, integration lift, team capacity, and next 12 months of plans. See the ESP tradeoff section below if youre considering a switch, or read Customer.io vs Klaviyo for the head-to-head most teams are debating.

5. Suppression layer

The rules that prevent a user from being in two places at once. A trial user inside the conversion sequence shouldnt also receive the upgrade nurture. A churned user shouldnt receive the win-back AND the reactivation. Suppression is boring, nobody writes about it, and skipping it is what makes lifecycle programs feel spammy at scale.

The operator decision: where suppression rules live. Same answer as segmentation, wherever you can audit them. If suppression is a tribal-knowledge spreadsheet, it breaks the day someone leaves the team.

6. Measurement layer

The reporting that connects each lifecycle decision to a dollar outcome. Not opens. Not clicks. Conversion rate per segment. Revenue per send. Lift per cohort. The measurement layer is the only thing that makes the rest defensible. Without it, every quarterly review is a debate about taste. With it, the next 30 days of work are obvious.

See the trial-to-paid lifecycle gap for what happens when measurement is missing: teams optimize the wrong part of the funnel for months because the data they trust is a vanity metric.

Vendor blogs skip this section because they dont have an answer that doesnt involve buying their tool. Operators care about it constantly. Lifecycle marketing works when one person owns it end-to-end. When ownership splits across email, product, and engineering, the layers stop agreeing with each other and the program decays.

10-person SaaS

Lifecycle is a part-time slice of the founder or first growth hire. Pick the smallest viable system: ESP-native segmentation, three or four core triggered flows, manual reporting from a spreadsheet against ESP exports. The goal isnt elegance, the goal is that one person can run it without context-switching all day. The right ESP at this stage is the one with the lowest integration lift, usually whatever the product already speaks natively (Klaviyo if youre Shopify-attached, Customer.io if youre event-driven SaaS, ActiveCampaign if youre creator-tier).

50-person SaaS

Now theres a dedicated lifecycle marketing manager, but no engineering support and no analyst. The system has to be runnable by one operator with occasional product favors. Segmentation lives in the ESP. Events come from a data-aggregator stack (Segment, RudderStack). Reporting is half ESP-native, half spreadsheet. This is the stage where most teams hit the wall: they hire a lifecycle manager, hand them a Klaviyo seat, and expect retention to compound. It doesnt, because the segmentation layer underneath is built on whatever the product happens to fire.

200-person SaaS

Dedicated lifecycle team (lifecycle marketing manager plus an associate or specialist), an analyst with at least dotted-line ownership, and engineering capacity for event work. The ESP is now one component in a stack that includes a warehouse, a BI tool, and a CDP-adjacent layer. The org question shifts from “who runs lifecycle” to “who owns each layer.” Best practice: data layer with engineering, segmentation with lifecycle, triggers with lifecycle plus product, ESP/CRM with lifecycle, suppression with lifecycle, measurement with the analyst. Six layers, three teams, written contracts at every boundary.

The pattern across all three stages: lifecycle marketing fails when nobody owns it end-to-end. Adding more headcount doesnt fix this. Naming an owner does. Every audience I work with (subscription DTC, creator tools, AI consumer tools, productivity, education) runs on the same six layers. The org chart that wraps them is what differs.

The shorter the list of things lifecycle is, the longer the list of things it gets confused with. Five common ones:

• A content calendar. Calendars are channel outputs. Lifecycle decides whether the calendar entry should fire for this user, this week. A calendar without a decision layer is broadcast-and-pray.
• A welcome series. Welcome series are one trigger inside one layer. Theyre the easiest thing to point to and the smallest fraction of the actual work. If your lifecycle program is mostly your welcome series, the program isnt built yet.
• Batch and blast. Even highly-segmented batch sends are still batch. Behavioral triggers fire when the user does the thing, not when the marketing team has time to send the thing. The difference is everything.
• Lead scoring for sales handoff. Lead scoring belongs to a sales-led motion. PLG and individual-buyer SaaS have a different problem: product-qualified intent at scale, no human handoff. Lifecycle automates the handoff to the next product moment, not to a human.
• An ESP. The ESP renders messages. The ESP is not the program. Anyone selling you a lifecycle program based on which ESP you bought is selling ESP setup, not lifecycle.

And one boundary worth naming: lifecycle programs amplify retention. They cant fix product-driven churn. If your retention is bleeding because users arent getting value from the product, lifecycle is a multiplier on a negative number. The diagnostic for that lives in the churn analysis cornerstone, built around reading cohort retention curves and matching the intervention class to the archetype. Activation problems get fixed in the onboarding cornerstone. Both link back here for the lifecycle-amplification side.