👋 We’re Knock. We provide a set of simple APIs and a dashboard that developers use to introduce transactional notifications into their products, without having to build and maintain a notification system in-house.

—

Companies send you two types of notifications: promotional notifications to try and get you to do something, and transactional notifications to keep you updated about what’s happening in the product.

Teams would normally use a marketing automation platform such as Braze, Iterable, or Customer.io to power their promotional notifications. When it came to building transactional notifications, many teams built in-house, others tried to leverage their existing marketing automation platform (with varying degrees of success.)

Now a new category of developer-first transactional notification platforms have emerged to help product and engineering teams build great notification experiences without having to build and maintain the entire system in-house or fit it into a marketing automation API that was built for a different use case.

In this post we’ll cover when it makes sense to continue using marketing automation platforms for your transactional messaging, and when your use case is worth its own dedicated system for transactional notifications.

An overview of marketing automation platforms

Today’s modern marketing automation platforms grew out of the shift from traditional marketing to growth marketing.

Ten plus years ago, marketing teams used broad email blasts, Google Adwords campaigns, and promotions to try and attract customers. As customer and product usage data became more accessible to marketing teams, they shifted to the more iterative and experimental approach of growth marketing.

Platforms like Braze, Iterable, and Customer.io emerged to give marketers a way to build personalized messaging that engaged with leads across multiple channels to attract and engage customers.

There are a few key features in common across today’s marketing automation platforms.

  • Dynamic segmentation. Use user properties and event data to build dynamic segments of users to target in promotional messaging.
  • Cross-channel campaign management. Use a visual journey builder to determine which channels a user should receive notifications across when they enter a dynamic segment (e.g. new signups inactive for at least 7 days.)
  • Preference centers. Most marketing automation platforms will offer some type of preference center, but these tend to be geared towards promotional emails.
  • Measurement framework. A way to A/B test different promotional messaging campaigns and understand which ones yield the highest open and conversion rates.

Pros

  • Build dynamic segments based on user properties. Most marketing automation platforms include an ability to build dynamic user segments for targeting the campaign messages mentioned above. (e.g. customers that haven’t purchased anything in last 7 days.)
  • Great for one-time, campaign-based messaging. Marketing automation platforms make it easy to send a quick campaign message (such as a new promotion or feature release) to a segment of users that match a set of properties.
  • Good for promotional lifecycle emails and re-engagement use cases. If you’re looking to nurture leads towards a conversion with lifecycle marketing, these tools are a great way to do that. You can use dynamic segments to specify which users should receive messages, and use their visual workflow builders to determine when users should be messaged.
  • Easy for non-technical users to make campaign updates. These tools are oriented towards marketers. Once you connect a data source (such as Segment), marketers can do a lot of the work of promotional messaging themselves.
  • Useful for simple transactional use cases. If your transactional use cases are relatively simple, such as welcome emails and password resets, you can probably solve for them within your existing marketing automation platform. Keep in mind any forward-looking requirements you may need in the future as more advanced transactional capabilities (such as multi-channel preferences, batching, and Slack notification support) won’t be supported by MAPs.

Cons

  • No isolated environment support. Because marketing automation platforms were built for marketers, they don’t have the multiple environment support you’d look for from a tool you’re going to use in your production application. This means that any transactional notifications you power with a marketing automation platform will always be updated live in production—this is error prone and can cause customer-facing notification issues at scale.
  • No support for integration with developer workflows. Marketing automation platforms don’t have CLIs or support for managing the system via your CI/CD pipeline.
  • Tend to be mobile-centric and consumer-app focused. If you’re a B2B app that needs to deliver persistent in-app notifications (such as an in-app feed) or send customer-facing Slack/Teams notifications, you’ll need to build that in-house as marketing automation platforms don’t support those channels.
  • No support for advanced preferences modeling. The preference center capabilities of marketing automation platforms are focused on the promotional email use case. If you’re looking to support cross-channel preferences, you’ll find more flexibility in the preference models of notification infrastructure providers.
  • No support for batching/digesting. When you start sending transactional notifications at scale, batching and digesting messaging becomes an important part of the user experience. Marketing automation platforms don’t support either.

In summary, marketing automation platforms do a great job at the primary use case they solve: promotional notifications to drive customer acquisition. But if you find you’re building a lot of in-house functionality to support more advanced transactional notification use cases on top of your existing marketing automation platform, it’s probably time to look at a dedicated transactional notification platform.

An overview of transactional notification platforms

If you’re new to transactional notification platforms (a category often referred to as “notification infrastructure”), don’t worry: we’re relatively new here!

We started Knock a few years ago after we build our own transactional notification system in-house at Frame.io and knew there had to be a better way. As we spoke with engineering teams we learned that lots of other teams were having a hard time managing transactional notifications in-house, many of which were trying to build transactional notifications on top of a marketing automation platform.

The big players in this space right now are Knock (that’s us!), Courier, and Novu. We’d encourage you to check out all three and learn what we have to offer. (If you decide to use one of our competitors, we’d love to hear why so we can continue to improve our product.)

Here are a few of the key features available in notification infrastructure that you won’t find in marketing automation platforms:

  • A production-ready, developer-friendly workflow. Product notifications are on the critical path within an application and should be a part of a team’s software development lifecycle. Transactional notification platforms provide isolated environments for dev, staging, and prod, as well as a git-like versioning workflow for pushing and rolling back changes.

  • Multi-channel orchestration and preference management. Transactional notification platforms support the full breadth of channels needed for modern applications, including real-time in-app feeds as well as integrations with Slack and Teams. They also include a flexible preferences model for managing notification-specific preferences across channels, as well as more advanced use cases such as muting notifications from a specific resource in your product.

  • Batching and digest support. Transactional notification platforms come with pre-built components for managing batching and digest use cases, so you don’t need to manage your own error-prone cron jobs in your own stack.

  • [Knock only] Integrate your notification system from CI/CD pipeline with Knock CLI. Run notification tests, push local changes to your Knock notification system, all as part of the CI/CD actions you already run in your engineering team’s Github workflow.

    Using the Knock CLI to fetch workflows from an account

    Using the Knock CLI to fetch workflows from an account.

Pros

  • Transactional notification platforms come with the features mentioned above. 😁
  • Developer-first API and SDK support. We hear from developers that the API documentation of notification infrastructure products is stronger than that of their marketing automation counterparts, which makes sense given developers are the primary user of transactional notification platforms.
  • [Knock only] Built-in tenancy support. Because transactional notification platforms are built for the product use case from day one, they come with a tenant model to support multi-tenant SaaS use cases such as per-account in-app feeds. These tenant models also enable you to power per-tenant branding, where a given account/customer in your product can customize your notifications with their own branding elements.
  • [Knock only] Production-grade observability, monitoring, and analytics. Notification infrastructure products should come with better observability than you’d be able to build with an in-house notification system. At Knock we provide a set of observability tools as well as Datadog and Segment extensions so you can monitor your notifications from the tools you use today.

Cons

  • Limited support for one-time, campaign-based messaging. At Knock we recommend our customers continue to use their marketing automation platform for promotional use cases.
  • Limited support for building dynamic segments based on user properties. Most of the recipient lists you build in a transactional notification system have to do with the relationship users have to resources in your product. (As an example, which users follow a page. Notify those followers.)

If you’re requirements include product-triggered notifications at scale, and you need (or will need) support for batching, in-app/Slack channels, and flexible preferences, it’s worth taking a look at notification infrastructure platforms (like Knock).

Conclusion

In this article you learned about the difference between marketing automation platforms such as Braze and Iterable, and notification infrastructure platforms such as Knock. While both categories take on cross-channel notification orchestration, if you’re an engineering team evaluating a build (or a rebuild) of a transactional notification system, you should check out what we’ve built at Knock.

We believe that production-grade notifications built by developers require developer-first tooling, such as a flexible preferences model, CLI and CI/CD integration support, and support for product-first use cases like stateful in-app feeds, Slack notifications, and batching/digests.

If you agree and want to learn more, you can sign up for the Knock free plan today.