---
name: retargeting_funnel
description: Design a staged retargeting sequence with recency windows, depth tiers from page view to cart, a message and offer ladder per stage, frequency caps tied to audience size, buyer exclusions, and measurement that shows which stage earns its spend. Use when building or fixing retargeting on Meta, Google, or TikTok, when one warm audience is getting one generic ad, or when retargeting spend needs a stage by stage verdict.
---

# Retargeting Funnel

## Purpose

Turn one warm audience getting one ad into a staged sequence where each group hears the message that fits how deep they went and how long ago they went there. A cart abandoner from yesterday and a blog reader from three weeks ago are not the same audience, and paying to treat them as one wastes the strongest intent in the account.

## Workflow

1. **Verify the signal before designing anything.** Confirm the goal event fires with a real test conversion, the pixel or tag and any server side events agree, and pool counts in the platform look plausible against site traffic. A funnel built on a broken event retargets the wrong people with confidence.
2. **Map depth tiers.** Sort the pool into engaged content, site visit with no product, product or pricing view, and cart, checkout, or trial start. Past buyers sit in a separate tier used only for cross sell or replenishment, never in a closing stage. Full tier definitions are in `references/stage-design.md`.
3. **Lay recency bands over the tiers.** Use hot 0 to 3 days, warm 4 to 7, cooling 8 to 14, and cold 15 to 30 as the starting grid for a normal decision cycle. Shorten for a low price, fast decision. Lengthen only for a long, considered purchase. A new action resets a person into the hotter band for that stage.
4. **Fill the stage worksheet.** Complete `assets/stage-worksheet.md`, one row per stage, with entry event, exit event, message job, offer rung, pool size, planned frequency, and exclusions. If two rows end up identical, merge them. If a pool is below the platform minimum, merge it upward instead of forcing a stage that cannot serve.
5. **Climb the offer ladder in order.** Reminder of the exact item viewed, then proof, then the top objection answered, then comparison or bundle, then an incentive only at cart or trial stage or at the final cold touch, then a clean exit. Do not lead shallow stages with a discount.
6. **Set caps from audience size, not from habit.** Run `bin/cap_math.py plan --audience <pool> --freq-per-week <target> --cpm <expected>` to get the daily budget that produces the frequency you chose. Reverse it with the `from-budget` mode when a budget is fixed and you need to know what frequency it will really produce. Starting points to test, not rules: hot cart stage near daily contact for a few days, product viewers a few times per week, shallow engagement once or twice per week. Replace every starting point with the account own frequency response within the first cycle, using `references/measurement.md`.
7. **Build exclusions before launch.** Exclude buyers and goal converters from closing stages, active trial users from trial start ads, open support or refund cases from upsell stages, and all retargeting pools from prospecting. Check current platform windows and minimums in `references/platform-limits.md` and confirm them in the live UI.
8. **Give each stage at least 3 ads that progress.** Reminder, proof, and objection ads in rotation read as a sequence. One ad at the same frequency reads as nagging and burns the pool.
9. **Measure per stage, weekly.** Score pool size, planned against actual frequency, spend, click through rate, and cost per conversion per stage. Then run the real test: a holdout or a frequency cell test that shows incremental conversions, as laid out in `references/measurement.md`. Attributed conversions alone never justify keeping a stage.
10. **Act on the scorecard.** One decision per stage per week: scale, hold, refresh creative, lower the cap, raise the cap, merge upward, or cut. Write the number that forced the decision next to it.

## Worked example: online store

Product: mid price kitchen gear, decision length about 7 days, goal event is Purchase, expected CPM $18.

- Stage A, cart and checkout, 0 to 3 days, pool 800: exact item reminder plus shipping and returns answered, free shipping at this stage only. Planned frequency 7 per week. Cap math: 800 times 7 times $18 divided by 1000 divided by 7 gives a $20.00 daily budget.
- Stage B, product viewers, 0 to 7 days, pool 5,000, excluding Stage A: product reminder, a review proof ad, and a comparison ad. No discount. Planned frequency 4 per week. Cap math gives $51.43 per day.
- Stage C, site visitors with no product view, 0 to 14 days, pool 12,000, excluding A and B: best seller proof and a route to the right category page. Planned frequency 2 per week. Cap math: 12,000 times 2 times $18 divided by 1000 divided by 7 gives $61.71 per day.
- Stage D, buyers, last 180 days for exclusion and 21 to 45 days for replenishment cross sell only: excluded from A, B, and C. Separate small campaign, timed to when the first purchase gets used.
- Rest rule: anyone finishing Stage C cold band with no new visit leaves active retargeting. A new visit re-enters them at the right tier.

## Worked example: software trial

Product: business software, free trial, decision length about 21 days, goal events are Trial Started and Paid Conversion, expected CPM $25.

- Stage A, trial started, no key feature used, 0 to 7 days, pool 600: onboarding help and the one feature that predicts retention, no second trial pitch, no discount. Planned frequency 5 per week. Cap math: 600 times 5 times $25 divided by 1000 divided by 7 gives $10.71 per day. If the platform minimum spend forces frequency well past plan, merge with Stage B and separate the message by audience label instead of by campaign.
- Stage B, pricing or feature page viewers, no trial, 0 to 14 days, pool 3,200: proof from a similar company, setup time objection answered, then a comparison page ad. Planned frequency 3 per week, $34.29 per day by the same math.
- Stage C, content and webinar engagers, 0 to 30 days, pool 9,000: problem focused proof, invite to a live demo, no pricing offer. Planned frequency 2 per week, $64.29 per day.
- Exclusions: paid customers out of every stage, active trial users out of B and C, open support cases out of upsell, all three pools out of prospecting.
- Measurement note: judge Stage A on paid conversion lift against a holdout of trial starters, not on clicks. Clicks on onboarding ads mean little if paid conversion does not move.

## Output Contract

- A completed stage worksheet at `assets/stage-worksheet.md` standard: one row per stage with depth, recency, pool size, entry and exit events, message job, offer rung, cap math, and exclusions.
- A cap calculation per stage, run through `bin/cap_math.py`, showing pool, planned frequency, CPM used, and the daily budget it implies, or the expected frequency a fixed budget implies.
- At least 3 ad concepts per stage, named by ladder rung, so a reviewer can see the progression without opening the ad account.
- A weekly scorecard format and the date and design of the first holdout or frequency test.
- Every platform limit cited from `references/platform-limits.md` and flagged for live UI confirmation. Practitioner ranges are labeled as starting points to test, never as platform facts.

## Operating Rules

1. Never launch a stage before its exclusions exist. Retargeting a buyer with the ad for the thing they just bought is the most common and most avoidable failure in this work.
2. Never split a pool below the platform minimum or below a size that can hold its planned frequency at a workable budget. Merge upward and differentiate by message.
3. Never set a budget first and let frequency fall out by accident on a small pool. Compute the frequency the budget produces, or compute the budget the frequency needs. One of the two is always a deliberate choice.
4. Never judge a stage on attributed conversions alone. Warm pools convert on their own at some rate. The stage earns its spend only when a holdout or frequency test shows lift.
5. Never extend a recency window past the real decision length to spend more. A longer window with no new action is colder traffic at warm prices.
6. Rotate and progress creative inside a stage. If frequency is within cap and results still fall for two weeks, the message is stale before the cap is wrong.
7. Verify every factual claim about a platform limit, window, or minimum in the live UI or a primary help page at build time. If a claim cannot be verified, cut it or label it as a practitioner starting point.