Trigger fires for 240 of 1,900 contacts, and two journeys double-mail 11%
Northwind runs an onboarding journey in real-time marketing with a trigger on 'Contact created' and an audience filter of Country = United States. In month one, 1,900 US contacts were created but only 240 entered the journey. The team also runs an audience-based journey on the segment 'Newsletter subscribers' plus a second journey whose trigger is 'Trial started'. Both send the same day-3 welcome email, and 11% of recipients receive two copies. A new requirement lands: when a customer abandons a cart, send a reminder within 15 minutes. Carts are stored in a custom table linked to Contact at roughly 40,000 rows per day, and abandonment is flagged by an update to a status column that typically lands two to six hours after the cart is created.
1. Explain the 240-versus-1,900 gap. List the hypotheses you would test, in the order you would test them.
Read the worked answer
Test order (cheapest and most likely first)
- Publish state and timing. A trigger only fires for records created after the journey goes live with the trigger active. There is no backfill. Ask when the journey was published relative to the 1,900 creates - if the integration was loading a backlog for the first weeks, that alone explains most of the gap.
- Condition evaluated on an incomplete record. The audience filter is Country = US. If the integration inserts the contact and writes Country in a subsequent update, the contact fails the condition at trigger time and never re-enters. Check the population rate of Country at insert time versus at end of day, and check whether the trigger is on the create event or on an attribute change.
- Wrong table. 'Contact created' does not fire for Lead records. If part of the intake is prospects, those contacts do not exist yet as contacts.
- Re-entry and journey state. A contact can go through a journey only once unless re-entry is enabled. Anyone who already completed a prior version of the journey is silently skipped.
- Send-time blocking. Consent not configured for the Commercial purpose blocks the email, not the entry. Cross-check entries against sends - if entries are close to 1,900 but sends are 240, the problem is consent, not the trigger. That distinction changes the entire fix.
What to instrument
Log entry counts separately from send counts per journey step. Without that split you cannot tell a trigger defect from a consent or suppression defect, and the two have nothing in common except the symptom.
2. Design a fix for the duplicate day-3 email that does not depend on hoping the segments stop overlapping.
Read the worked answer
Why duplicates happen
Each journey evaluates its own audience independently. There is no global 'one message per contact per day' guard. If a contact qualifies for two journeys that both send on day 3, they get two emails, and as segments are re-evaluated the overlapping population drifts unpredictably.
Options, in order of preference
- Consolidate. One journey with a decision branch: trial started in last 7 days -> trial path; else -> nurture path. Same message, one evaluation, no overlap possible. This is the durable fix and the one to push for.
- Mutual exclusion via suppression. Maintain a segment of contacts currently inside journey A and add it as an exclusion on journey B (and vice versa). Workable for two journeys, fragile at five.
- Flag field + condition. Have each journey stamp a 'last welcome sent' date or a 'nurture stage' value on the contact, and gate the send step on it. Deterministic and auditable, but adds write traffic and must be maintained on every path including exits.
What not to do
Tightening the segments so they 'probably' no longer overlap. Overlap returns the first time someone edits a filter, and the failure mode is invisible - recipients do not complain about a duplicate, they just disengage.
Verify
Before shipping, run both journeys against a test contact that qualifies for both and confirm exactly one email arrives; then check the journey insights duplicate-send counts for a week after go-live.
3. Design the cart-abandonment reminder against the 15-minute SLA and the custom-table constraints. What do you change about the trigger and about the message classification?
Read the worked answer
The trigger is on the wrong event
Abandonment is not a create event. A cart row is created when the customer is shopping; the status column flips to abandoned hours later. Triggering on cart creation would mail people mid-checkout, which is both wrong and reputationally expensive. The trigger must be an attribute-change trigger on Cart.Status = Abandoned, with conditions on cart value and on the linked contact.
Constraints to design around
- The custom table must be reachable from the contact through a relationship for the trigger to resolve to a person. Confirm the lookup exists and is populated before promising 15 minutes.
- One contact can have several carts, so re-entry must be allowed and the trigger must carry a dedupe condition (status = Abandoned AND reminder not already sent) or the same customer gets three reminders in an hour.
- At 40,000 rows per day, a burst after a campaign can queue: the 15-minute target is a target, not a guarantee. Instrument the p95 latency from status change to send, publish it, and define a fallback if it slips.
- If the reminder must include cart contents, resolve them at send time or accept staleness - do not stuff the line items into the trigger payload.
Classification
An abandoned-cart reminder that contains a discount or cross-sell is promotional, not transactional, in most jurisdictions. Bind it to the Commercial purpose and accept that unconsented carts are dropped, rather than routing it under Transactional to raise volume. If legal confirms a purely informational reminder is transactional, classify it that way and strip any promotional block from the template so the classification stays honest.