Media plan handoff: what the planner gives the buyer, and what comes back
Part of Programmatic media planning
The short answer
A media plan handoff passes the approved plan from planner to buyer in one package: the list version and its site count, exclusions, deal details, geography and language, and the open questions. The buyer then confirms back which approved sites are actually buyable on the planned path, so nobody mistakes an approved list for live inventory.
Key takeaways
- Hand off one package, referenced by a list version number and a site count, never a file attached to a chat message.
- Approved means the planner chose the site; buyable means the buyer can reach it on the planned exchange and deal. Track both.
- Open questions travel with the handoff, each with an owner and a date, instead of living in someone's head.
- The handoff closes only when the buyer confirms back what was built, what could not be bought and why.
What should a planner hand to the buyer?
A handoff is the moment a plan stops being a document and becomes settings in a buying platform. Everything the buyer needs to build the campaign, and nothing the buyer has to guess, belongs in one package. If the buyer has to message the planner to find out which file is current, the handoff failed before it started. The steps that produce the approved list are in the programmatic media planning guide; this checklist starts where they end.
The handoff package
- The approved list, named with its version number, approval date and site count, plus the change summary from the previous version.
- The exclusions that apply: shared account exclusions, campaign specific exclusions and any sites the client asked to keep out by name.
- Deal details for each site that needs a deal: the seller, the requested terms and which list version the deal should carry.
- Geography and language for each line of the plan, written as the platform settings the buyer will choose, not as a market description.
- The flight dates, budget split between core and test sites, and the frequency intent from the plan.
- Every open question, with an owner and a date.
- The names of the planner, the buyer and the approver, so each later question goes to the right person.
Geography deserves precise wording because platforms read it differently. In Google Ads, for example, location options (opens in a new tab) separate Presence or interest, which reaches people in or interested in a place, from Presence, which reaches people in the place. A plan that says "Saskatchewan" leaves that choice to the buyer; a handoff that names the option does not.
How do you separate approved sites from buyable inventory?
Approval and buyability are two different facts about a site, decided by two different people. The planner approves a site because it fits the brief. Whether the buyer can reach it depends on the seller, the exchange, the seat and the deal. A site can be approved and impossible to buy on the planned path, and a site can be easy to buy and never approved.
Buyability is checked against the site's files and the platform. The ads.txt specification (opens in a new tab) lists the accounts a publisher authorizes, and says consuming systems should default to a seven day expiry when no cache directives are present, so a fix the publisher makes today may not reach the buying platform at once. The exchange's sellers.json (opens in a new tab) entry shows whether the account belongs to the publisher or an intermediary.
Which open questions should travel with the handoff?
A plan can reach handoff with something unresolved. The risk is not the open question but the unwritten one, because the buyer will answer it silently with a default. Write each one down with the person who will answer it and the date the answer is needed for the build.
| Question | Example | Usual owner |
|---|---|---|
| Sites held for review | Two approved sites had no readable ads.txt file when the list was built | Planner, with the buyer's check of the platform |
| Deal not yet confirmed | The seller has the request but has not sent a deal ID | Buyer |
| Client decision pending | Whether a regional news site's crime coverage is within tolerance | Account lead, with the client |
| Platform limit | Whether the list should be split across line items or loaded as a channel | Buyer |
| Measurement | Which conversion action the client will judge the campaign on | Account lead |
How should list versions be referenced?
Version references are what make every later conversation precise. "The list" means nothing three weeks into a flight. "Version 3, approved October 14, 61 sites" can be checked against the platform, the deal and the invoice.
Five rules for referencing list versions
- Number every approved version. Use whole numbers in order, and never reuse a number after a version is replaced.
- Carry the version in every file name. The export for Google Ads Editor, where the CSV column (opens in a new tab) for sites is Placement, should carry the same version as the list it came from.
- State the count beside the version. The count is the quickest way for the buyer to prove the right file was loaded.
- Never edit an approved file. Any change, even one domain, becomes the next version with its own approval.
- Note platform splits. Display & Video 360 line items target up to 10,000 apps and URLs combined (opens in a new tab), so a larger list loaded as a channel or across line items still references one version.
Which deal details should the planner pass on?
The planner may not set up the deal, but the planner knows which sites the deal is for and what the client agreed to. Passing those terms in the fields that sellers and buying platforms actually use saves a round of email. The field names below come from the OpenRTB 2.6 specification (opens in a new tab).
| Field | Meaning in the specification | What the handoff states |
|---|---|---|
| at | Auction type; 3 means the bidfloor value is the agreed deal price | Whether the client agreed a fixed price or an auction |
| bidfloor and bidfloorcur | The minimum bid and its currency, which defaults to USD | The agreed floor and currency, CAD or USD |
| wseat | Buyer seats allowed to bid on the deal, coordinated in advance | Which seat the buyer will use, so the seller can name it |
| wadomain | Advertiser domains allowed to bid on the deal | The advertiser's domain, if the seller restricts by advertiser |
| guar | 1 means a guaranteed deal the bidder must bid on | Whether the deal is guaranteed or not |
What should the buyer confirm back to the planner?
The return half of the handoff is the part teams skip. Without it, the planner reports to the client on a list that may not be what is running. The buyer's confirmation should arrive before the start date and again after the first days of delivery, when platform diagnostics have data.
The buyer's confirmation
- The list version and site count loaded on each line item, matching the handoff.
- Every approved site that could not be bought on the planned path, with the reason: not sold on that exchange, reseller only, or no seat access.
- Each deal ID received, with its floor, currency and seat, matched against the handoff terms.
- The geography, language and frequency settings chosen, named as the platform names them.
- Any filtered bids in the first days, using the platform's reasons; Display & Video 360's troubleshooter (opens in a new tab) lists causes such as an invalid deal ID, a request sent before the deal was created and bids below the floor.
- Answers to every open question the buyer owned.
What does a complete handoff look like?
Fictional example
A Saskatchewan chiropractic clinic group
A fictional group of chiropractic clinics in Regina and Saskatoon plans a winter display campaign in English, beside posture, desk work and running injury articles and local news. The planner hands off version 2 of the list, approved on a Tuesday with 58 sites, plus one deal request to a provincial news publisher, priced in CAD, and the Presence location option for Saskatchewan.
Three questions travel with it: two approved health blogs held because their ads.txt files could not be read, the seller's deal ID not yet sent, and the client's decision on a site with frequent crash coverage. Each has an owner and a date.
The buyer's confirmation comes back on Friday. Version 2 is loaded, but seven approved sites are sold only through exchanges the agency's seat cannot reach, so they move to the held column with that reason. The deal ID has arrived with the floor in USD, and the buyer asks the seller to correct it before launch. The planner tells the client that 51 of the 58 approved sites are live.
How does PlacementGraph package a list for the handoff?
Frequently asked questions
Should the handoff happen in a meeting or in writing?
Both, in that order of importance. The written package is the record and must stand alone. A short call helps the buyer ask questions, but anything decided on the call should be added to the package, so the next person to open it sees the same answers.
Can the buyer add sites that are buyable but not on the approved list?
Not without the planner. A buyable site that was never approved has no recorded reason to be there, and it weakens the record behind the rest of the list. The buyer can suggest it, the planner reviews it, and if it passes it joins the next version with its own approval.
What if the planner and buyer are the same person?
Write the handoff anyway, as a note to the next person who opens the account. The separation between approved and buyable still matters, and the confirmation step becomes a self check against the package. When the account changes hands, the package is what makes the transition quick.
How long should the buyer have between handoff and launch?
Long enough for deals to be set up and confirmed, creative to be approved and exclusions to take effect. Deal setup depends on the seller's response time, so a handoff that arrives the day before launch leaves no room for a single correction. Agree the lead time with the trading team at kickoff.
Sources
- Target ads to geographic locations (opens in a new tab)Google Ads Help
- ads.txt 1.1 specification (opens in a new tab)IAB Tech Lab
- sellers.json specification (opens in a new tab)IAB Tech Lab
- CSV file columns (opens in a new tab)Google Ads Editor Help
- App, channel, and website targeting (opens in a new tab)Display & Video 360 Help
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab
- Troubleshoot your deals and line items (opens in a new tab)Display & Video 360 Help
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.