Campaign reporting
Campaign renewal follow-up tracker
A renewal archive is useful only if its conditions return before the next flight launches. A follow-up tracker turns archived issue IDs, due dates, next-test requirements, and claim limits into a practical readiness check.
Use this tracker after the renewal memo and evidence archive are complete. It is built for contextual display, sponsorship, and private marketplace campaigns where a useful prior result may still require creative repair, destination QA, outcome-status completion, or a cleaner comparison before the next buy is approved.
What the tracker prevents
The tracker keeps a prior campaign's limits visible at the moment they matter most: before the next launch. It is not a project-management system. It is a measurement-control record for the next campaign brief.
| Common failure | How it appears | Tracker control |
|---|---|---|
| Archived issue disappears | A mobile page, lead-status field, or pooled placement note is remembered only after launch. | Carry the issue ID into the next brief with owner, due date, and launch gate. |
| Fix has no evidence | A team says the issue is fixed, but the repaired field, URL, creative, or routing state is not visible. | Require a proof field: screenshot, field export, QA row, trafficking note, or status report. |
| Retest becomes renewal | A fragile cell or directional result is reused as proof that the next flight should scale. | Keep retest rows separate from renewal rows and require minimum cells before action. |
| Lift language returns | A descriptive prior result is repeated as incremental impact in the next brief. | Carry the comparison rule and unavailable claim into the new measurement plan. |
| Follow-up date drifts | Outcome status, sales follow-up, or matchback windows close with no decision meeting. | Assign review dates for pre-launch, mid-flight, status-window close, and readout. |
| Owner ambiguity | Ad operations, creative, web, analytics, and buyer teams each assume another team owns the fix. | Name one owner for each row and one reviewer who can close it. |
Tracker fields
Each row should connect the prior decision to a current readiness state. If the row cannot be closed before launch, it should become a named exception in the campaign brief.
Archive ID
The renewal archive or memo record that created the follow-up condition.
Issue ID
The weak-lane ID from the issue register, such as mobile-page-02, lead-status-05, or comparison-04.
Next-flight scope
Package, placement, creative, device, destination, outcome, or comparison rows affected by the condition.
Required evidence
The concrete proof needed before the row can move from promised to ready.
Owner and reviewer
The person or team doing the work and the person or team allowed to close the row.
Gate date
The due date tied to proposal, activation, launch, mid-flight, status-window close, or readout.
Status
Open, evidence due, fixed pending QA, ready for launch, in flight, readout due, closed, or blocking.
Claim boundary
The sentence allowed until the row is closed and the stronger sentence still unavailable.
Next action
Launch, narrow, exclude, retest, add causal test, hold, or rebrief.
Status ladder
Use status labels that change decisions. A vague in progress row does not tell a buyer whether the next flight is ready.
| Status | Use when | Decision effect |
|---|---|---|
| Open | The condition is known, but owner, proof, or due date is incomplete. | Do not approve the next brief until the row is assigned. |
| Evidence due | The owner and proof are named, but the evidence has not arrived. | Keep the row out of launch-ready language. |
| Fixed pending QA | A repair is complete, but reviewer evidence is not yet accepted. | Launch only if the row is non-blocking and named as an exception. |
| Ready for launch | The required proof is accepted before traffic starts. | The row can support the next flight's scoped launch decision. |
| In flight | The next campaign is running and the row requires monitoring during delivery. | Review at the agreed mid-flight checkpoint. |
| Readout due | The evidence depends on outcome status, matchback, sales follow-up, or readout rows. | Do not close the renewal claim before the status window ends. |
| Closed | The issue is fixed, excluded, retested, or converted into a new test plan with evidence. | The final claim can use the closed-state language only. |
| Blocking | The missing evidence would make the next decision uninterpretable. | Hold, narrow, or rebrief before launch. |
Follow-up calendar
Set calendar moments around the decision, not around convenience. Different evidence closes at different times.
| Checkpoint | Review | Rows that must be updated | Output |
|---|---|---|---|
| After renewal memo | Convert memo conditions into tracker rows. | All open issue IDs, excluded rows, next-test requirements, and unavailable claims. | Initial follow-up tracker with owners and dates. |
| Before next brief | Decide whether the prior result can be reused in the new proposal or campaign brief. | Archive ID, comparison rule, allowed claim, next-flight scope, and missing proof. | Brief-ready, narrow, hold, or rebrief decision. |
| Activation gate | Check whether creative, destination, placement, tracking, and reporting repairs are accepted. | Creative files, destination QA, UTM fields, placement IDs, deal keys, and field dictionary rows. | Launch-ready list and exception list. |
| Mid-flight | Check whether the repaired condition is holding while delivery is live. | Delivery scope, device split, destination state, field capture, status coverage, and quality flags. | Continue, narrow, pause affected row, or add diagnostic note. |
| Status-window close | Check lead status, matchback, sales follow-up, survey, or other delayed outcome fields. | Outcome status, missing rows, duplicate rules, attribution window, and comparison state. | Ready for readout or outcome evidence still incomplete. |
| Readout meeting | Close the tracker row or carry it into the next archive. | Final action, excluded rows, issue state, allowed claim, and next evidence requirement. | Closed tracker rows and new archive rows. |
Sample tracker rows
These examples show structure only. They do not describe a real advertiser, publisher, platform, or campaign.
| Archive ID | Issue ID | Next-flight scope | Required evidence | Owner | Gate | Status | Decision effect |
|---|---|---|---|---|---|---|---|
| renewal-methods-01 | mobile-page-02 | Mobile display rows for measurement guide placements. | Landing-page QA pass, mobile speed note, form-source field capture. | Web and creative | Activation gate | Fixed pending QA | Hold mobile scale until proof is accepted. |
| renewal-methods-01 | comparison-04 | Renewed contextual package and next measurement plan. | Matched baseline or protected holdout written into the brief. | Measurement | Before next brief | Evidence due | Descriptive response only until comparison is designed. |
| renewal-readiness-02 | lead-status-05 | Qualified lead readout for buyer-readiness package. | Status coverage threshold and missing-status report after follow-up window. | Buyer analytics | Status-window close | Readout due | Lead quality claim waits for status completion. |
| renewal-reporting-03 | placement-scope-01 | Two low-volume placements excluded from the prior renewal claim. | Separate placement rows and minimum delivery rule in export. | Ad operations | Launch readiness | Ready for launch | Rows can run, but remain separate in readout language. |
| renewal-context-04 | slice-02 | Small device-creative cell marked as a retest candidate. | Minimum delivery, balanced rotation, and separate creative readout. | Campaign analyst | Mid-flight | In flight | Do not call a winner before minimum cell is met. |
Pre-launch gate
Before a follow-up flight launches, sort every tracker row into one of four launch decisions.
| Gate decision | Use when | Brief language |
|---|---|---|
| Launch as planned | All blocking rows are closed or ready for launch. | The prior condition is satisfied for the scoped next flight. |
| Launch narrower scope | Some contexts, devices, placements, or creative rows are ready while others remain unresolved. | Launch only the verified scope and exclude unresolved rows from the renewal claim. |
| Launch with monitoring | The row cannot be fully closed until live delivery or delayed outcome status arrives. | Proceed with named monitoring checkpoints and no stronger claim until review. |
| Hold or rebrief | The missing condition would make the next campaign or readout uninterpretable. | Hold activation, fix the condition, or rewrite the campaign brief before launch. |
Closeout note
End every follow-up cycle with a short note that can move directly into the next archive.
Recommended structureTracker row [issue ID] from archive [archive ID] is [closed, launch-ready, monitored, excluded, retest-required, or blocking] for [next-flight scope]. The evidence reviewed was [proof field]. The allowed next-flight claim is [bounded sentence]. The unavailable claim remains [stronger sentence] until [comparison, outcome, field, or test requirement] is complete.
Pre-launch checklist
- Does every archived issue ID have an owner, reviewer, due date, required evidence, and gate decision?
- Are excluded rows still excluded, or have they been repaired and requalified for the next flight?
- Does the next brief carry the same comparison rule and unavailable claim from the archive?
- Are mid-flight and status-window review dates assigned before launch?
- Can the campaign launch without upgrading descriptive evidence into lift language?
Pair with
Use this tracker after the campaign renewal evidence archive, the campaign renewal memo template, and the campaign issue log and renewal register. Pair it with the campaign readiness dashboard before launch, the private marketplace readiness index for the full buyer sequence, the private marketplace campaign walkthrough for a package example, the private marketplace renewal scorecard when the next action needs scoring, the creative and destination troubleshooting matrix when a repair row needs diagnosis, the private marketplace reporting field dictionary when field names must stay stable, the private marketplace readout export sample when row structure needs cleanup, the campaign status-window closeout checklist when delayed outcome rows need final maturity checks, the campaign status-window closeout register when closeout rows need next-review dates, and the incrementality test plan template when the tracker carries a causal-test requirement.