The digest engine collects multiple trigger events and aggregates them into a single message delivered to the subscriber.
This becomes useful when a user needs to be notified on a large amount of triggers and you want to avoid sending too many notifications. Novu will automatically batch the incoming trigger events based on the
subscriberId and an optional
digestKey that can be added to control the digestion of the events.
After adding a digest node in the workflow editor, each node that will be below the digest node will be only triggered once in the specified digest interval. You can decide to send messages before adding a digest node and they will be triggered in real-time.
Will determine how long the digest engine will wait before sending the message once created. You can specify the amount and the unit that best suites your needs.
If specified, the digest engine will group the events based on the
subscriberId, otherwise the digest engine will group the events based only on the subscriberId.
The digest key might come useful when you want a particular subscriber to get events grouped on a custom field. For example when an actor likes the user's post, you might want to digest based on the
The strategy which Novu should use handle the digest step. More details on available strategies below.
Novu allows you to define different digest strategies depending on the actual use-case you are trying to achieve. At this point we allow you to select from 2 strategies:
- Regular Strategy
- Back-off Strategy
Let's explore them in detail:
In regular strategy, a digest will always be created for the specified window time. Which means that from the first event trigger, if no active digest exists for this subscriber one will be created and the user will receive the message only when the digest window time is reached.
In the back-off strategy, before creating a digest, Novu will check if a message was sent to the user in the back-off period. If a message was sent, a digest will be created. Other wise a message will be sent directly to the user and the digest creation will be skipped.
Writing digest templates
In many cases, you will need to access all the digested events payload in order to show the user all or parts of the events included in this digest. For example: "John and 5 others liked your photo".
As port of the digested template you will have access to a few properties:
|An array of all the events aggregated under this digest. This will be the "payload" object passed to each |
|The number of total events in this digest|
Let's look at a handlebars syntax example for the following triggers:
Using the following template:
Total events in digest:
Not a digested template