- Read the brief
- Configure and QA
- Test a request
- Monitor delivery
Use this sequence to organize the investigation. Confirm the details in the affected platform and campaign.
A campaign can look complete in the ad server and still fail its brief. The purpose of trafficking QA is to make the agreement, settings, creative behavior, and measurement describe the same campaign.
Use this checklist as a starting point and adapt it to the platform, format, and contract. Record the person responsible for each check and keep evidence of the final configuration. This makes a launch easier to review and later changes easier to investigate.
Confirm the campaign brief
- Record advertiser, campaign name, order reference, and operational contacts.
- Confirm start and end times with the applicable timezone.
- Record booked goal, pricing basis, budget, and success metrics.
- Confirm placements, formats, devices, geography, audience, and exclusions.
- Resolve frequency, brand separation, measurement, and approval requirements before setup.
Configure the campaign and line items
Translate the brief into settings, then compare those settings back to the source agreement. Similar campaign names and copied defaults are common reasons to inspect identifiers carefully.
- Select the intended inventory, line-item type, and delivery behavior.
- Set flight dates, goal, rate or budget, and any daily limits.
- Apply targeting and frequency rules at their intended scope.
- For deals, reconcile seller and buyer identifiers and transaction type.
- Check that creative sizes and associations cover the intended requests.
Test creative and tracking behavior
QA the actual asset or tag intended for launch. A preview screenshot can confirm appearance, but cannot establish that all tracking calls complete.
- Confirm assets render in the intended environment and supported dimensions.
- Test the click destination, redirect chain, and tracking parameters.
- Inspect required impression and other event calls for failures or duplication.
- For video, check media support, duration, playback, and expected events.
- For app formats, test the host SDK interaction in the relevant app environment.
Verify an actual serving request
Use platform diagnostics or an approved test placement to inspect the request, eligibility, selected creative, and recorded event. Keep test traffic clearly separated where the platform supports it.
Record the launch handoff
- Save the final settings, creative version, and evidence of testing.
- Record unresolved constraints and the owner of each follow-up.
- Confirm who monitors delivery and who can approve production changes.
- Set the first review time based on expected traffic and reporting delay.
Check delivery after launch
Review delivery against the planned curve once enough data is available. Confirm the expected placements and creatives appear in reporting and inspect any concentration of errors or discrepancies.
If delivery is low, locate the blocked stage before changing settings. If settings must change, record the old and new values and retest. A launch checklist becomes useful operational evidence when it captures what was actually verified.
Test your reasoning: Catch a copied default
Original simulated exercise. This is not a real client case.
A copied line item passes creative preview.
Evidence available
- Brief: mobile inventory.
- Line item: desktop targeting.
- Creative size matches the brief.
Is the successful preview enough to approve launch?
Read the answer and next check
No. The targeting conflicts with the brief. Correct it and test a request from the intended mobile placement.
Next check: Verify eligibility, selection, and tracking, then record the first delivery review.