---
name: stage-5-amplification-boost-posts-remarketing-ads
description: "Use small ad tests to give proven content more reach."
category: Strategy & Measurement
stage: —
definitive_article: /social-amplification
status: complete
---

# Stage 5: Amplification (boost posts, remarketing ads)

Use small ad tests to give proven content more reach. This guide helps your team set the limit and check what actually went live. Start with the winning posts, the right audience and the spend already approved.

**The path:** Organic proof → Bounded test → Live readback → Measured decision

**Start when:** Engine readiness, goals, source content and targeting are checked and a specific paid test is authorized.

## Inputs

- The passed required engine gates and exact approved budget, dates, action scope and owner.
- [The checked audience map](https://local-service-spotlight.github.io/task-library/?task=stage-4-targeting-custom-audiences-lookalikes-remarketing#task-stage-4-targeting-custom-audiences-lookalikes-remarketing) and organic result evidence for usable published content.
- [Dollar a Day, small paid tests of proven content](https://blitzmetrics.com/dollar-a-day/) current method, target result and campaign/source access.

## Steps

1. Rank relevant organic content by the job and signals that matter, including watch quality, useful engagement or qualified response. Select a small supported test set; the old 3–5-post suggestion is not permission to invent winners.
2. Prepare the source’s small-test pattern: typically $1 per day for seven days, with the exact total portfolio exposure, audience, result and end/review condition stated. Check the platform’s supported budget rules and minimums; do not silently increase spend to satisfy a control.
3. Document the test variable and goal. Use the maintained Dollar-a-Day procedure for the chosen test rather than inventing a universal four-stage optimization sequence that the current operating hub does not define.
4. Include remarketing only when its source, rights, eligibility and actual campaign support are verified. Choose a justified window; 1-day abandoners on both Google and Meta are not a universal prerequisite.
5. Create or launch only the exact campaign covered by authority through the supported account workflow. Keep the correct post identity, destination, budget, audience, optimization goal and schedule. A green checklist alone does not grant publication or spending authority.
6. Read back live settings and delivery state. Record rejected, pending-review, active and non-delivering states as observed; a saved campaign is not proof that an ad was served.
7. Monitor on the agreed cadence and evaluate after the relevant window and conversion delay. Apply the current stop rules through [Pause weak tests and scale proven winners](https://local-service-spotlight.github.io/task-library/?task=kill-underperformers-scale-winners#task-kill-underperformers-scale-winners). Save spend, result, changes and next review for optimization; a nominal daily budget is not always the platform’s daily billing cap.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the result against its agreed requirements; see the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] The test set has organic proof and exact approved settings and total exposure.
- [ ] Saved and live account state match the authorized plan; delivery is separately observed.
- [ ] Review/stop conditions and actual spend are recorded without promises of return.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional team selects two proven posts for two approved $7 tests. One is active; the other is still under review. The launch receipt records those two states and the total planned $14 exposure. It does not call both delivered, and no extra money moves to the active test without authority.

## Handoff and Content Factory context

[Review the engine results](https://local-service-spotlight.github.io/task-library/?task=stage-6-optimization-metrics-budget-review-recommendations#task-stage-6-optimization-metrics-budget-review-recommendations) receives the settings, spend and outcome records.

This work supports Promote in the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). It follows the source, editing and publishing work of Produce, Process and Post; the actual campaign evidence feeds the next review.

## Start with an agent

Give the AI worker this recipe, the real Inputs, the desired result and the actions already authorized. Ask for the saved output, source evidence, passed and failed checks, and the next owner. A skill is a set of instructions. Loading it does not prove access, install a scheduled job or complete the work. Use the [current installation guide](https://localservicespotlight.com/install/) only if reusable setup is needed; a ZIP contains instructions and is not an access grant.

Use the actual supported app and verified source access. A model name is not a promise of browser control, memory or unattended work. For recurring work, inspect the real job’s trigger, owner, timezone and observed firing; this recipe creates no schedule. Before any media playback, mute the player and set volume to zero. A silent review does not prove sound was heard.

## Record the real execution

Open the run record when work begins. Keep one execution ID, the exact starting recipe revision, input sources and actual state. Write a [meta article, the record of one real execution](https://blitzmetrics.com/meta-article-prompt/) with results, checks, failures and next owner. Link it to this task in the [Task Library](https://local-service-spotlight.github.io/task-library/). Writing is required; public release follows existing authority.

Reuse the same execution ID for internal reviews, meta writing, revisions and retries. A blocked run stays open with its dependency and owner, without an invented finish time. Keep historical public examples as dated evidence; article counts alone are not verified execution frequency. Use supported findings to propose and verify a recipe improvement.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 5/5 `●●●●●` — frequency 5, revenue 5, gating 3 (runs every factory cycle or weekly; ads/revenue path)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `computer` — Logged-in UI (Meta Ads Manager, Descript, GSC, wp-admin when REST is blocked). Requires a supported browser tool and the right account access.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/social-amplification/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=stage-5-amplification-boost-posts-remarketing-ads#task-stage-5-amplification-boost-posts-remarketing-ads)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records work together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `complete`. It is preserved, not promoted by this rewrite. That label alone does not verify document readiness, account access, an actual execution or a client outcome.

A relevant real execution, source evidence, independent reviewer and accepted handoff remain to be recorded. The fictional example teaches the method and does not fill a real-run evidence gap. The opening and full method need a named semantic reviewer; the task-specific path is source guidance, with visible desktop/mobile presentation still to check.