The Campaign That Never Fired
A travel company builds a Target activity: a 10% discount banner on the checkout page, targeted to visitors whose cart value exceeds $500. The offer is set as an Experience B against a no-banner control. The activity is approved and set to Active. After four days, the QA analyst reports zero traffic in the activity report. The developer confirms the at.js mbox call on checkout fires correctly and returns content. The audience was built from a profile script that reads a cart-value attribute updated by a separate API call that happens after the checkout page renders. Cart values on the site routinely range from $80 to $1,200. The activity's traffic allocation is 100%, and the audience is set as the entry audience.
1. Diagnose the most likely reason the activity shows no traffic, and explain the mechanism.
Read the worked answer
The activity is almost certainly qualifying visitors on a cart value that is not yet present when Target evaluates the audience at the checkout page. The profile script reads an attribute written by an API call that completes after the page renders, so at decision time the attribute is empty or stale. If the audience requires cartValue > 500 and the attribute is missing, no visitor matches, and the activity records no entries.
Key mechanism to state: entry audience is evaluated at the moment the mbox/decision is requested. If the qualifying data arrives later, it cannot retroactively enroll the visitor into that activity. The mbox firing "correctly" only proves the request was made - not that the audience matched.
Secondary checks worth confirming: that the profile script is actually enabled and syncing, and that the attribute name in the script matches the one in the audience rule.
2. Propose two viable fixes and state the trade-off of each.
Read the worked answer
Fix A - Move the decision later. Fire the Target request (or a second, offer-specific mbox) on the checkout page after the cart-value API resolves, and use that later request for the banner. Trade-off: adds latency and complexity to checkout, and the banner may appear after initial paint (a visible flicker). Best when the discount must reflect the true cart value.
Fix B - Move the decision earlier. Capture cart value on the cart page (before checkout) where it is already known, store it in the visitor profile, and let the checkout activity use that stored value as its entry audience. Trade-off: the value is a snapshot from the prior page, so a cart edited between pages could mis-target. Mitigate by re-checking the value in the offer logic.
A third option - passing the value as an mbox parameter and using it in the audience - only works if the parameter is available at request time, which is the same constraint as Fix A. Do not recommend it as a fix without resolving the timing.
3. What would you add to prevent this class of failure on future activities?
Read the worked answer
Add a pre-launch QA checklist that verifies data availability at decision time, not just that the mbox fires:
- Confirm every audience attribute used is populated before the Target request on the target page (trace the network waterfall).
- Test with a real qualifying and a real non-qualifying session, not just a manual preview.
- Monitor activity entries in the first 24 hours; a zero-entry alert is a cheap early warning.
- Document attribute dependencies (which script/API writes each attribute and when) in the activity brief.