Trigger-based marketing = event-driven programming with “no code” martech in every stack

Last week, I shared some interesting stats on trigger-based marketing from a benchmark report by Blueshift. A couple of eye-popping, high-level findings:

• Email triggers are 497% more effective than batch emails
• Mobile push triggers are 1,490% more effective than batch push notifications

Directionally, this isn’t surprising, although the magnitude of the difference is remarkable. Marketing messages that are “triggered” by a prospect/customer’s actions — or a specific milestone they’ve crossed — are focused, relevant, and often engage their recipient at the right time and place.

In contrast, batch emails and push notifications — of “batch-and-blast” fame (infamy?) — are less discriminate and are sent on the marketer’s timetable rather than recipients’. Naturally, click-through and conversion rates are lower. Much lower.

For a deeper look in the data, here’s the click-through rates for different kinds of triggered emails versus batch sends in Blueshift’s benchmark report:

When I first shared these findings, there was some pushback that the analysis fails to take scale into consideration. Sure, triggered marketing is more effective — but you’re limited in scale by the number of triggerable moments you have and the volume of users flowing through them. This is especially challenging for B2B marketers.

In contrast, batch email marketing can reach a large audience, quickly. Any time the marketer wants. And even if the percentage of click-throughs and conversions is a fraction of the rates seen in response to triggered marketing touches, the absolute number can still be larger. Small slice of a larger number instead of a larger slice of a small number.

Fair enough. The pragmatic marketing operations leader would point out that this isn’t an either/or choice. Use both, each for the right reasons, in the right way.

I’d also suggest that it’s an incentive for marketers — especially B2B marketers — to think more creatively about identifying and even generating more triggerable moments in their customer journey maps. Some B2B marketers have gotten really good at this with free services layered around their core offering that are entirely about establishing a channel for continuous engagement.

Sending triggered emails? Congrats, you’re “programming.”

But I want to connect the dots with another topic: the rise of “citizen developers” in marketing.

I was wondering how many marketers were using “no code” tools — everything from Airtable to Zapier — in their marketing stacks and what their use cases were. (In fact, I’m running a quick survey on that topic. I’d be grateful if you’d participate. It’ll take less than a minute.)

But then I was struck by one of those right-in-front-of-your-face realizations: essentially all marketing stacks today have widely used “no code” programming capabilities built into them.

Triggered marketing touches are a perfect example. Every major marketing platform today — HubSpot, Marketo, Oracle Eloqua, Salesforce, Blueshift, etc. — has the ability for a non-technical business user to listen for an “event” (a triggerable moment, such as the download of a marketing report or the abandonment of an onboarding flow) and then, based on some logic, take an action (e.g., send an email, alert an account manager, change a status, etc.).

This is event-driven programming.

There may be some pushback on that claim. For instance, at what point does using any app through a friendly UI constitute a “no code” management of software control flow? Does using a drag-and-drop editor to build an HTML email count as a “no code” experience?

My pushback to the pushback would be two-fold:

First, explicitly mapping out a series of steps, including if/then branching logic, to execute the right actions in response to a triggered event seems like a pretty legit claim to programmatic thinking. If you were to draw it on a whiteboard, it would certainly look like a software flow diagram. (In fact, this is how most marketing platforms visually represent such automation workflows in their UI.)

Second, the blurring of the line between what qualifies as a “no code” experience versus just using software to get stuff done, is actually the larger revelation. Great “no code” products are giving users programming-like superpowers while making it all seem like business-as-usual in a digital world.

If you create a software program without realizing you’ve created a software program, does it still count as a software program? I vote yes.

There was a great article on this in TechCrunch earlier this month, arguing that “no code” will define the next generation of software. It’s not a category. It’s a user experience paradigm.

Similar to cloud, no code is not a category itself, but rather a shift in how users interface with software tools. In the same way that PCs democratized software usage, APIs democratized software connectivity and the cloud democratized the purchase and deployment of software, no code will usher in the next wave of enterprise innovation by democratizing technical skill sets. No code is empowering business users to take over functionality previously owned by technical users by abstracting complexity and centering around a visual workflow. This profound generational shift has the power to touch every software market and every user across the enterprise.

So, yes, I think a drag-and-drop HTML editor is a great example of a “no code” tool too.

What does this trigger for you?