Buyer readiness
Contextual package proof export template
Organization byline: Measurement Press editorial desk. This page does not list an individual author or reviewer. Read the editorial method and corrections policy.
About 12 min read
A contextual package becomes easier to buy, traffic, and renew when the proof can be exported as fields instead of rebuilt from a proposal deck after the campaign ends.
Use this template before a private marketplace or direct contextual campaign launches. It connects the reader job, package contract, eligible inventory, creative handoff, first-party signal readiness, and allowed conclusion language in one exportable record. The point is not to turn context into a performance promise. The point is to preserve enough evidence for a buyer, publisher, and analyst to read the final report the same way.
Picture the launch review for a buyer-readiness package. Sales has a proposal, operations has placement rules, analytics has source-trail requirements, and the buyer wants to know what the final report will be allowed to say. If those records stay in separate decks and inboxes, the campaign can still launch, but the readout will depend on memory. A useful export turns those separate promises into rows that can be checked before the first impression is served.
Where the export fits
The export sits between the package proof sheet and the campaign readout. It should be created before trafficking, then updated only with fields that were truly observed during delivery or supplied by the buyer after launch.
| Workflow moment | Export role | Fields that must be locked | Fields that can mature later |
|---|---|---|---|
| Proposal review | Show why the package fits the reader job. | Package ID, reader job, eligible page set, clean-fit category, and unsupported uses. | Forecast volume, final creative IDs, and landing-page version. |
| Trafficking handoff | Turn the package into operational instructions. | Deal key, reporting key, placement IDs, sizes, device rules, exclusions, and flight window. | Delivery totals, viewability, invalid-traffic status, and makegoods. |
| Signal setup | Preserve context through first-party and buyer-side records. | Source trail, destination ID, event IDs, eligibility rule, missing-value vocabulary, and comparison rule. | Lead status, matchback result, follow-up state, and outcome maturity. |
| Readout meeting | Convert fields into a bounded next decision. | Primary signal, quality flags, comparison status, decision rule, and allowed claim level. | Renewal recommendation after field completeness is reviewed. |
Pressure-test the export grain
The export grain is the level at which one row represents the campaign. Choosing it early keeps the report from mixing package, placement, creative, destination, and outcome status into one convenient total.
| Decision pressure | Best export grain | Why it protects the readout | What to avoid |
|---|---|---|---|
| The buyer may compare package lanes. | Package by week, with stable reader job and eligible context fields. | Shows whether each lane delivered the context that was sold before response is judged. | Pooling all lanes into one publication-level performance row. |
| Creative files or destinations may change. | Placement by creative ID and destination ID. | Separates message, format, and landing-page effects from package fit. | Calling a context weak when the page destination or asset was the real limiter. |
| Lead quality will mature after launch. | Source trail by outcome status and status date. | Keeps unknown, unmatched, qualified, disqualified, and suppressed records visible. | Replacing missing buyer-side status with a zero or a success. |
| Renewal language depends on comparison strength. | Package by comparison rule and allowed conclusion level. | Prevents a descriptive delivery export from inheriting lift language. | Writing a renewal claim before the evidence ceiling is named. |
Minimum export schema
These fields are the compact version. A larger report can add cost, pacing, geography, frequency, or order-line details, but these fields should survive into the final interpretation.
| Field | Example value | Source | Readout use |
|---|---|---|---|
| campaign_id | mp-q3-methods-flight | Proposal and trafficking record. | Connects proposal, delivery, analytics, lead, invoice, and renewal records. |
| package_id | measurement-science-desk | Media kit or inventory matrix. | Preserves the contextual package that was sold. |
| pmp_deal_key | mp-msd-pmp | Package contract. | Connects deal route with the agreed package boundary. |
| reporting_key | package.measurement_science_desk | Inventory readiness matrix. | Lets exports join package records without relying on display names. |
| reader_job | Choosing or auditing advertising measurement methods. | Audience intent map and proof sheet. | Keeps the campaign tied to a professional task, not a broad audience label. |
| eligible_context | Measurement guides, method selectors, readout QA pages, and companion templates. | Package proof checklist. | Shows which page groups qualify as on-package delivery. |
| placement_ids | article-inline-1, article-inline-2, article-rail-1, post-content | Placement contract. | Separates inventory, device, and format effects before ranking response. |
| creative_id | guide_offer_v1_728x90 | Creative acceptance record. | Connects message, size, destination, and approval state. |
| destination_id | methods-webinar-landing-v2 | Landing-page QA record. | Separates media response from page speed, form, and routing quality. |
| signal_readiness_level | Quality ready | First-party signal readiness review. | States whether source trails, eligibility, events, and quality status are interpretable. |
| eligibility_denominator | Eligible visits with non-duplicate source trail and complete destination ID. | Data-layer spec and buyer-side status fields. | Prevents match rates or lead rates from hiding excluded records. |
| comparison_rule | Matched prior contextual flight; no protected holdout. | Campaign brief and measurement plan. | Sets the strongest conclusion language the report can use. |
| bounded_conclusion | Observed qualified traffic was strongest in measurement guide contexts. | Readout owner. | Turns the export into language that matches the evidence level. |
Sample package rows
The rows below are examples for structure, not performance benchmarks. Use the real package IDs, eligible contexts, creative IDs, and signal states for the campaign being reviewed.
| package_id | reader_job | placement_ids | signal_readiness_level | comparison_rule | bounded_conclusion |
|---|---|---|---|---|---|
| measurement-science-desk | Choose or audit measurement methods. | article-inline-1, article-inline-2, article-rail-1, post-content | Quality ready | Prior contextual flight; no holdout. | Use directional renewal language and keep qualified visits separate from lift. |
| source-vendor-evaluation-desk | Evaluate vendor evidence before a decision. | archive-leaderboard, article-inline-1, article-rail-1, native-sponsored-card, post-content | Descriptive ready | No comparison available. | Report delivery and observed engagement only; do not rank vendor-evaluation contexts by outcome quality. |
| buyer-readiness | Compare package boundaries and campaign handoff fields. | archive-leaderboard, article-inline-1, native-sponsored-card | Comparison ready | Matched buyer-reference page group. | Compare package response inside the matched context and keep causal wording out of the renewal note. |
| case-study-library | Study measurement failure modes before changing process. | archive-leaderboard, case-inline-1, case-rail-1, post-content | Quality ready | Matched guide-library baseline. | Read return visits and companion-guide movement as learning signals, not business impact. |
Worked simulated export: a completeness ceiling
Simulated Worked Example. The row below is a training example, not a Measurement Press campaign result. It shows how a reviewer can calculate field completeness without turning a missing field into a zero or a performance claim.
| Field group | Required fields in this example | Observed | What the row can support |
|---|---|---|---|
| Package boundary | package_id, reader_job, eligible_context | 3 / 3 | Identify the package and the reader task it was meant to serve. |
| Placement and handoff | placement_ids, creative_id, destination_id | 3 / 3 | Separate inventory, message, and destination from package fit. |
| Signal trail | source_trail, event_id, eligibility_denominator | 2 / 3 | Review eligible records, but hold any event-level deduplication conclusion. |
| Outcome state | outcome_status, status_date | 1 / 2 | Describe the observed status while late or missing status remains visible. |
| Comparison rule | comparison_rule | 1 / 1 | Name the comparison, while keeping its design limits attached to the conclusion. |
The simulated export is complete enough to describe the package boundary and observed status, but its missing outcome status keeps the claim ceiling at descriptive delivery and data quality. It does not support the stronger statement that the package created qualified pipeline.
To change that conclusion, supply the missing fields, document the deduplication rule, and state whether the comparison is a prior flight, matched context, protected holdout, market test, or survey design. Even a complete export does not create a causal estimate by itself. It only makes the chosen design and its limitations inspectable.
Standards cross-checks
These fields also have practical interoperability precedents. The IAB Tech Lab OpenRTB 2.6 specification separates site page, referrer, search, publisher, and content fields, and warns that a technically valid request can still be commercially unsatisfactory when context is missing. It also distinguishes required, recommended, and optional attributes because recommended fields may not be available from every supply source. The Campaign Manager 360 Data Manager requirements call for a conversion timestamp, an ordinal value for deduplication, and at least one supported identifier. Those references are compatibility checks, not evidence that a package performed well. Record the actual platform, export version, and field mapping used by the campaign under review.
Source-to-decision handoff
The standards above help define a handoff, but they do not certify a package or its results. Use the source record to decide what can be exported, what must be held, and what conclusion language remains allowed. The IAB Tech Lab specification distinguishes required, recommended, and optional OpenRTB attributes; Google Campaign Manager 360 Data Manager requires a conversion timestamp, a deduplication ordinal, and at least one supported identifier for imported offline conversions. Treat those as field-design checks, then record the actual platform, version, and mapping used in the campaign.
| Source requirement | Export check | Decision effect | Claim ceiling |
|---|---|---|---|
| OpenRTB 2.6 site, content, and deal objects | Preserve the page or app boundary, content fields, publisher identity, deal identifier, and the mapping from each placement to its package row. | Pass: package delivery can be described at the recorded boundary. Hold: do not infer contextual fit when the join is missing or reconstructed from a display label. | Documented delivery and field coverage only. |
| OpenRTB required versus recommended attributes | Label each field as required, recommended, optional, or locally required; do not silently treat a recommended field as universally present. | Pass: missing optional fields remain visible. Hold: an absent field that the chosen decision needs blocks that decision rather than becoming a zero. | Only the evidence supported by the selected field set. |
| Campaign Manager 360 Data Manager fields | Check conversion timestamp, ordinal or transaction key, and at least one supported identifier; record the source system and import path. | Pass: conversion rows can be checked for time and duplicate handling. Hold: do not call the outcome deduplicated or attributed when a required identifier is absent. | Observed outcome status, not incremental lift. |
| Campaign Manager 360 duplicate-source warning | Record whether the conversion receives offline data through Data Manager, the API, a tag, or another connected source, and identify the canonical ingestion path. | Pass: source ownership and event dates can be audited. Hold: do not combine feeds or treat a second import as independent corroboration. | Deduplicated observed conversions only after the platform's import rule is checked. |
| Campaign-specific measurement plan | Store denominator, status vocabulary, late-arrival rule, comparison design, and the person or team approving the final conclusion. | Pass: the reviewer can reproduce the rate and its boundary. Hold: if plausible denominator or status choices change the decision, request the missing evidence. | Renew, revise, retest, add a lift design, or pause only at the named evidence level. |
Use a compact review record beside the export: source_url_or_doc, platform_version, field_mapping, denominator_rule, dedupe_rule, comparison_rule, reviewer_decision, and claim_ceiling. This preserves the reasoning that a later reader would otherwise have to reconstruct from a deck.
Simulated sensitivity: when the export stays descriptive
Simulated Worked Example. The following worksheet is invented for method training. It is not a Measurement Press result, benchmark, or client dataset. Assume 240 eligible visits, an illustrative renewal gate of 10.0% qualified outcomes, and 24 currently observed qualified outcomes. The base rate is 24 / 240 = 10.0%.
| Scenario | Numerator | Denominator | Rate | Review consequence |
|---|---|---|---|---|
| Base export | 24 qualified outcomes | 240 eligible visits | 24 / 240 = 10.0% | At the illustrative gate; do not write a stronger claim without comparison evidence. |
| Four late statuses resolve as qualified | 24 + 4 = 28 | 240 | 28 / 240 = 11.7% | Rate moves 1.7 percentage points; status-date completeness must be reported. |
| Twenty rows lack a complete destination ID and are excluded by rule | 24 | 240 - 20 = 220 | 24 / 220 = 10.9% | Denominator choice changes the rate; preserve excluded and unknown rows. |
| Four apparent outcomes fail the deduplication rule | 24 - 4 = 20 | 240 | 20 / 240 = 8.3% | Rate falls 1.7 percentage points; do not label the base export deduplicated until the rule is reproduced. |
Because these plausible simulated states cross the illustrative 10.0% gate, the responsible decision is hold the renewal conclusion; resolve status, denominator, and deduplication records first. The worksheet supports a reproducible quality review, not a claim that the package caused qualified outcomes. To reproduce it, replace only the four inputs—eligible rows, observed outcomes, unresolved statuses, and excluded or duplicate rows—then recalculate each numerator and denominator while keeping the rule beside the result.
Limitation. A complete export can make delivery and data quality inspectable, but it cannot remove selection, timing, destination, or comparison bias. A protected holdout, market test, survey design, or other pre-specified method is still required for a causal or incremental conclusion.
First-party signal gate
A package proof export should not mark a campaign as report-ready until the source trail can answer these questions.
1. Can page context survive the export?Package ID, reporting key, placement ID, content group, reader job, and destination ID should appear in the same row or through a stable join.
2. Can eligibility be counted?Eligible, excluded, unmatched, suppressed, filtered, unknown, and not-applicable records should remain separate values.
3. Can events be deduped?Visits, leads, survey responses, and matched outcomes need event IDs, timestamp rules, duplicate rules, and ownership of late-arriving status changes.
4. Can destination quality be separated?Landing-page version, form path, page speed status, routing rule, and follow-up status should remain visible before media quality is judged.
5. Can the comparison support the decision?The export should name no comparison, prior flight, matched context, matched market, protected holdout, or survey design before any conclusion is written.
Allowed claim language
The export should include one conclusion field, but the language should be constrained by the comparison rule and signal readiness level.
| Evidence state | Responsible wording | Language to avoid |
|---|---|---|
| Context and delivery fields only. | The campaign delivered in the planned contextual package and placement set. | The package reached the right buyers and created demand. |
| Delivery plus traffic-quality fields. | Observed traffic quality varied by package, placement, creative, device, and destination. | The best-clicking placement caused the strongest business result. |
| Lead or outcome quality fields with missing status visible. | Lead quality can be reviewed where status is complete; missing status limits the decision. | All attributed leads were qualified pipeline. |
| Matched prior flight or matched context. | The campaign performed stronger or weaker than the chosen comparison, subject to known design limits. | The comparison proves incremental lift. |
| Protected holdout, market test, or survey design. | The design estimates change for the measured population, window, outcome, and method. | The result proves the package will create the same effect in every future flight. |
Pre-launch checklist
- Export grain is chosen before results are visible: package by week, placement by creative, or outcome status by source trail.
- Package ID, deal key, reporting key, placement IDs, creative IDs, and destination IDs are stable.
- First-party signal readiness level is recorded with the field that limits the readout.
- Eligibility denominator, missing-value vocabulary, and matchback status are visible before rates are calculated.
- Comparison rule and allowed conclusion language are written before the campaign can favor one metric.
- Renewal decision rule names whether the next action is renew, revise creative, shift mix, retest, add lift test, or pause.
Pair with
Use this export template after the contextual package proof checklist, contextual package proof sheet, and private marketplace package brief template, alongside the first-party signal readiness checklist, campaign data-layer spec, campaign tagging QA checklist, creative asset acceptance checklist, and landing page launch QA worksheet. Before the readout, compare it with the private marketplace reporting field dictionary, private marketplace readout export sample, campaign reporting sample, campaign reporting worksheet, campaign readout QA checklist, and private marketplace renewal scorecard. For package IDs and placement contracts, use the media kit and inventory readiness matrix.