How CodeMosaic, a global developer community, runs event-triggered email at scale on Spreeflo, hitting a 13% CTR across multi-language lifecycle journeys.
Spreeflo Team
Author
Open rates on most developer-facing newsletters sit around 18%. CodeMosaic's average is 37%, with their top campaign hitting 76%. Here's how they got there.
CodeMosaic is a global community where software engineers share reusable code snippets, design patterns, and architecture diagrams. The marketplace runs on a contribution-consumption loop: developers upload patterns that other developers download, comment on, and adapt. The whole engine breaks if either side of the loop stalls.
Which is why CodeMosaic's marketing team is, in practice, a lifecycle marketing team. Their job is to keep the loop turning by making sure each developer sees a relevant notification at the moment it matters. Across 50 countries, 12 languages, and roughly 2.5 million emails a month.
Event-triggered email campaigns are marketing sends that fire in response to a specific user action, rather than on a fixed schedule. A new sign-up triggers a welcome email. A pattern download triggers a related-content email three hours later. Two weeks of inactivity triggers a re-engagement journey.
The opposite is the "weekly newsletter" pattern: same content, same time, same list, every Monday. Event-triggered campaigns trade simplicity for relevance. They demand more from the data layer (you need to know what each user did and when), but the engagement difference is significant. CodeMosaic's case study makes that concrete.
CodeMosaic's growth depends on a single dynamic: developers who download patterns eventually contribute their own. Without that flywheel, the marketplace turns into a static library and engagement decays.
Their lifecycle program lives or dies on four pillars. There's onboarding, which catches new developers in the first 72 hours after sign-up, a window where most of them either become contributors or churn out. There's the transactional layer (auth, password resets, edit confirmations) that fires reliably enough to make the platform feel responsive. There's the re-engagement journey for developers whose download cadence has slowed. And there's the feedback loop that surfaces what the community wants without anyone running a manual survey.
Of these, conversion flows are the most important by a wide margin. The single most critical campaign in CodeMosaic's program is the one that nudges high-value consumers (active downloaders) toward becoming contributors. If that campaign underperforms, the marketplace's supply runs thin within a quarter.
CodeMosaic's audience is spread across 50 countries and roughly 12 working languages, but those are the easy variables. What makes their segmentation interesting is the technical dimensionality on top: primary programming language, stack and framework, experience level, contribution history, and download cadence, each combinable with the others.
In Spreeflo, segments are evaluated continuously with nested AND/OR conditions on attributes and behavior. So a query like "Python developers in Europe who've downloaded three or more patterns in the last 14 days but haven't contributed one themselves" isn't a one-off export. It's a live segment that updates as users behave. Anyone who matches it that morning enters whatever journey is wired to it; anyone who stops matching it that afternoon exits cleanly.
The team uses these segments to pick what to send and to whom, but the timing question is handled differently. Rather than schedule sends by timezone, CodeMosaic triggers most of their lifecycle email off the action itself (a pattern downloaded, a comment posted, a syntax error reported), which means the email reaches the developer at the moment that triggered it, regardless of where they are.
We used to schedule everything by timezone, early-morning sends for Europe, midday for the US, and so on. The moment we shifted to triggering off the action that the user just took, the timezone problem mostly evaporated. The relevant time is when the event fired, not when we got around to sending.
Across CodeMosaic's tracking, the team pushes roughly 1,500 unique event properties into Spreeflo: which pattern was viewed, in what language, by which user, in what context, with which prior session, and so on. That richness is what lets the lifecycle program get specific.
A developer who downloads a React pattern and then bounces gets a different follow-up than one who downloads it, reads three comments, and edits the file locally. Same starting action, very different signal. The follow-up for the second user references the discussion thread they were reading; the follow-up for the first user just nudges them toward a related pattern with a working demo.
Most of these journeys are condition-triggered: a user enters the first time they match a set of conditions, then the journey continues based on what they do next inside it. In Spreeflo's sequence builder, this lives as a tree of Custom Event triggers, If/Else branches, and Wait Condition steps. Once it's built, the journey runs forever. New developers enter as they meet the conditions, and the team's daily work is iterating on the content inside each path, not rebuilding the routing.
We send around 1,500 event properties into Spreeflo, and the first instinct is to use all of them. The harder lesson is which ones actually move the needle. Eighty percent of our lift comes from maybe a dozen properties. The rest are nice to have but they don't change behavior.
Event-triggered journeys with Custom Event triggers, If/Else branches, and Wait Condition steps like CodeMosaic's live in Spreeflo's visual sequence builder.
Across all sends, CodeMosaic averages a 37% open rate, with their top-performing campaign sitting at 76%. The top campaign is the supply-flow nudge mentioned earlier (the one that turns active downloaders into contributors), and after a year of iteration on copy and timing, it now drives a 13% click-through rate. Industry CTR benchmarks for B2B developer marketing typically sit in the 2-3% range, so 13% is unusually high.
The volume is non-trivial too. CodeMosaic sends roughly 2.5 million emails a month, and almost none of them are batched broadcast sends. The vast majority are triggered by user behavior, segmented down to the language and discipline level, and personalized using event properties pulled from the user's recent activity.
None of these numbers came from sending more. They came from sending more precisely.
The biggest shift wasn't a single metric, it was what we stopped doing. Once the segments and events were in place, we cut the volume of generic broadcast emails by about 80%. The smaller, behavior-triggered sends do more work than the broadcasts ever did, and the unsubscribe rate dropped along with the volume.
Most lifecycle programs eventually run into a version of CodeMosaic's problem. The audience is too varied for one message to land everywhere, the timing is too inconsistent for a single send schedule, and the data is too rich for a Tuesday-9am newsletter to make any real use of it.
The way out isn't a bigger team or a different list. It's a layer underneath the marketing that watches behavior, sorts it, and acts on it without anyone in the room. That's what segmentation plus event triggers does at scale, and it's what's behind the gap between a 3% CTR and a 13% one.
If you're running lifecycle marketing for a community, a marketplace, or any product with a steady stream of user actions worth responding to, the question isn't whether to do this. It's whether your tooling actually lets you. Most platforms quietly cap out at a few segments and a handful of events. The interesting work starts after that.
Spreeflo gives community-driven and marketplace products the SDK, segments, and event-triggered journeys to run lifecycle marketing like CodeMosaic's, at a fraction of what most platforms charge.
CodeMosaic's full program (tracking, segments, and the first ten journeys) took about three months from a standing start. The tracking instrumentation usually takes the longest because it needs engineering buy-in on what events to fire and what properties to attach. Once that's in place, the segment and journey work moves much faster. If you already have event tracking running, a single behavior-triggered journey can be live in a day.
Yes, with one caveat. Event triggers don't need scale to be valuable. They need predictable behavior patterns. Even a few hundred users a month is enough to validate that a given journey is converting better than the broadcast equivalent. The 2.5-million-email-a-month number is what the program looks like at maturity; what it looks like in month two is more like a few thousand triggered sends a week. The principles are the same.
Scheduled sends force a tradeoff between simplicity and relevance, and the tradeoff gets worse the more international the audience is. A newsletter sent at 9 a.m. local for one timezone lands at 4 a.m. for another, and the content (which doesn't know what the recipient just did) is generic by definition. Event-triggered sends bypass both problems at once. The trigger is the user's action, so the timing is right by definition; the content can reference the action, so it doesn't have to fall back on a one-size-fits-all framing.
They're related and often used together, but they answer different questions. Behavior-based segmentation answers "who should get this email": it groups contacts by what they've done. Event-triggered email answers "when should this email fire": it sends in response to a specific action. CodeMosaic's program uses both: segments decide who's in each journey, events decide when the journey moves them to the next step.
Discover more insights on similar topics
How PassReady, an online exam-prep startup, lifted activation 29% with behavior-based email segmentation built on Spreeflo. A lifecycle marketing case study.
How TripStash moved from 0.4% to 9.8% browser push click-through by climbing from broadcast to behavioral to contextual. A three-tier framework with a worked example.
Most small teams say they do event-driven marketing. Few actually do. Four timing failures that masquerade as automation, and how to fix them.