What should trigger the next message?
Every lifecycle campaign is a bet that a signal means what you think it means. You found out what those signals were called by asking someone once.
A campaign wired to a broken signal does not fail loudly.
Either it sends to nobody or it sends to the wrong people, and you hear about it from a human weeks later.
When the signal behind a trigger stops arriving, the campaign does not error. It stops sending, and a campaign that sends nothing looks the same in your dashboard as one nobody qualified for.
The reverse is worse. If the condition around a signal changes so it fires for a wider group than before, the campaign starts sending to people it should not. Either way you hear about it from a human, weeks later.
- SignalStopped arriving
- 0events
- ConditionNever true
- 0qualified
- SendNothing to send
No error anywhere on this path. The campaign is healthy and sending nothing.
The signal still fires. It just means something else now.
Your welcome sequence starts going to people whose workspace never finished being created, and the daily count barely moves.
Say an update moves the signal for workspace created from the end of the sign-up step to the start. It now fires when someone begins creating a workspace rather than when the workspace exists.
The signal still fires. The daily count barely moves. But the welcome sequence keyed to it now goes to people whose workspace never finished being created. Nothing in that release was broken. The message is just wrong now.
The panel beside this is the same question asked earlier, before a campaign is wired to anything. For a checkout-recovery message it names the three signals the campaign would depend on, and marks each one as not yet found.
The trigger gets checked with the change that moves it.
Moved signals and changed conditions are two of the five things Skene looks for, and they're the two a code review doesn't catch.
You do not have to notice this one. When a release changes where a signal fires, Skene catches it in the pull request that made the change and flags it before it ships.
Moved signals and changed conditions are two of the five things it looks for, and they are the two that leave the signal firing. That is why a code review does not catch them and why your campaign is the first thing that notices.
A release that moves a signal
Flagged before it ships, not after the campaign goes quiet.
- OpenedRenames where the signal fires
- CheckedThe trigger depends on the old location
- Fix proposedInline, on the line that moved
You decide
The moments that drive a message, and the signals that stand behind them. Skene turns that into something a pull request can be checked against.
Engineering does
Nothing about your campaign logic. They are told, on the line they are editing, that this signal is one your lifecycle work depends on.