Today we’re super excited to announce the launch of Knock Sources.
Knock Sources enables you to use customer data platforms (CDPs), such as Segment or RudderStack, or reverse ETL platforms, such as Hightouch, Census, or Polytomic, to power your product notifications.
If you’re an engineer, this means you can use the data that’s already flowing through your event instrumentation tools to power your Knock integration. If you’re a product manager or a marketer, you can now easily create new notification workflows in Knock without having to take valuable roadmap time from engineering.
Knock Sources is a huge step forward for our platform and our mission to equip product and engineering teams with the tools they need to power delightful notifications.
tl;dr: You can use Knock Sources to power your product notifications with Segment, Hightouch, and other CDP and reverse ETL platforms in minutes.
You can learn more in our sources documentation.
About Knock Sources
Before today, the only way to trigger notifications in Knock (and to update user and object data) was through direct calls to our API. While our direct API is the preferred integration path for many of our customers, we had other teams asking us to power Knock with the event and identify data they already track with platforms such as Segment. Now they can.
With Knock Sources, you integrate your CDP or reverse ETL into Knock once. From that point forward, any member of your team can create and update new notification workflows. Whether you’re a developer looking to gain leverage on your time by auto-identifying users into Knock or a product manager looking to save time for engineering by introducing notifications powered by Segment events, Knock Sources will help you move faster the next time you need to ship a product notification.
Built for flexibility to fit your data model
The data you send through CDPs and reverse ETL platforms go to a lot of different destinations. With that in mind, one of our guiding principles was to keep it flexible enough to fit with the schema you already use in your data model. You shouldn’t have to reconfigure your CDP or introduce brand new events just to work with your downstream notification system.
When you map an event from a source to a Knock workflow trigger, you have the ability to map properties from your event into Knock’s workflow parameters, including recipients, cancellation keys, and tenants. Here’s an example of what makes this so powerful.
Let’s say we want to trigger a product notification when a user leaves a comment in-product. We already fire the comment-created
track call below using Segment when a comment is created, and we’d like to use that event to trigger the notification.
{
"messageId": "comment-created-message-vt3sd",
"timestamp": "2022-10-03T21:10:54.600Z",
"type": "track",
"email": "[email protected]",
"projectId": "cQHZyhy8rou9aPQigvSxq",
"properties": {
"followers": ["user1", "user2", "user3"],
"page.id": "85bb8ce8-59dd-4344-9257-a76715d56ec3",
"comment.body": "This looks great. Let's ship."
},
"userId": "user0",
"event": "comment-created"
}
In the event schema above, the user_id
represents the user that triggered the event (i.e. created the comment) and the followers
property represents the array of users that should be notified. We’ve structured our event schema in this way because we only want a single event created when a single comment is created, that way we can trust the aggregates in any downstream tools we use for analytics (such as Amplitude or Mixpanel.)
Most marketing automation tools and notification system vendors provide an inflexible one-to-one mapping between an event and the recipient of your messaging workflows. This means that given our schema above, only user0
would be notified. If we wanted to notify our list of followers
, we’d need to fire a separate Segment event for each of the users in our followers’ array. That means introducing an entirely new event or sacrificing the quality of our comment-created event. Neither are good options.
With Knock Sources, this is as simple as mapping the properties.followers
property into the recipients
parameter of the workflow we want to trigger. Knock will automatically fan out any items in the array into recipients, and start a workflow run for each. This way you can easily bring the event schema you already use in your CDP to power your notification system, without having to introduce new events or make changes to existing ones.
Map an event to multiple actions in Knock
With Knock Sources, we want you to be able to power any action in Knock using an inbound event from a CDP or reverse ETL platform.
As of today, you can use a source to auto-identify users into the Knock platform and trigger as many workflows for a single event as you’d like. This means that if you have a single comment-created
event that’s used for comment, reply, and mention notifications, you could trigger all three using that single event type.
In the future, you’ll be able to use source events to cancel workflows, create objects, and more.
Debug from source event to message sent
One of our product principles at Knock is to give our customers better visibility into their notification system than if they’d built it in-house. We’ve brought that same focus to Knock Sources.
Once you connect a source to Knock, you’ll immediately start to see event logs flow into your environment. For each event, you can see which workflows it triggered and then dive down into each of those workflow runs to see what messages were generated as a result of your incoming event.
What’s next
Knock exists to help software communicate with users. We do that by giving engineering and product teams the best possible tools we can to help them craft delightful notification experiences.
With Knock Sources it just got a lot easier for more members of the team to introduce product notifications, saving time for engineers and helping product teams ship better notification experiences to their users.
This is just the start of the sources and inputs you’ll be able to use to power Knock. We have a lot more on the way, including additional source integrations as well as the ability to use your data warehouse as a source for powering non-real-time notification use cases such as cron jobs and digests. If you have ideas or feedback or want us to support a source that we don’t provide yet, please let us know!