The agency preview works, but ad ops sends back a rejection screenshot. Before rebuilding the banner, establish what failed: the upload, the platform review, the animation inside a placement, or the click destination. Those failures need different evidence and often different owners.
The useful outcome is not another file called final-fixed.zip. It is a replacement whose change can be explained, whose original failure has been retested, and whose approval status is explicit.
Preserve the exact rejected package
Ask for the ZIP that was actually uploaded, not the developer’s latest export. Keep it unchanged beside the rejection message. Record its filename, byte size, and SHA-256 checksum so everyone can confirm they are investigating the same bytes. On macOS, shasum -a 256 campaign-300x250-v03.zip produces the checksum without modifying the archive.
Include the platform, creative type, dimensions, locale, submission time with timezone, and relevant creative or placement ID. Copy the full error text as well as keeping the screenshot: a cropped notification can omit the filename or validation detail that makes the problem actionable.
Work on a duplicate. If production overwrites the failed package before diagnosis, the team loses the ability to compare the failure with the proposed fix. The same principle applies to versioning banner ZIPs for ad ops: filenames describe intent; the retained artifact proves what was delivered.
Identify the failing stage before editing code
Start the investigation with one of these descriptions:
- Upload validation: the platform refuses the package before creating a usable creative. Inspect the named file, package structure, detected dimensions, and the required click implementation.
- Policy review: the package uploads but receives a policy rejection. Record the cited policy and route content, destination, or documentation questions to the responsible owner. A code rebuild is not an appeal or proof of compliance.
- Runtime failure: the creative exists, but a scene is blank, an asset fails, or interaction breaks in preview or a served placement. Capture the failing environment and sequence.
- Serving configuration: the expected creative does not appear, or the wrong destination is selected. Have ad ops check the assignment and settings before assuming the ZIP is defective.
These categories guide the next check; they are not conclusions. For example, Google’s Display & Video 360 upload troubleshooting distinguishes insecure resource requests, malformed click tags, unsupported files, dimension mismatches, and Google Web Designer export settings. Match the actual message to the rules for that creative type, not to a generic ClickTag snippet found elsewhere.
Reproduce one observable failure
Extract a copy of the rejected ZIP into an empty directory and serve it through a local HTTP server for package checks. Do not run it from a workspace where shared assets can hide a missing dependency. Compare the extracted package with the same creative in the target platform preview.
Record a short sequence: open the preview, wait for the second scene, observe the missing image. Include the browser version, viewport or placement dimensions, cache state, relevant console error, and failed request path or status. For intermittent failures, report how many attempts failed out of how many tested. Do not turn one successful reload into a pass.
Capella
A screenshot of the final frame cannot explain a broken entrance earlier in the sequence. Capture a short recording when timing is part of the symptom, and mark the first point where expected and actual behavior diverge.
If the problem only appears in a served placement, keep that distinction. Campaign Manager 360’s tag-testing guidance calls out tag type, active status, scheduling, targeting, and landing-page settings as possible causes. It also recommends server-hosted tag tests for HTML5 assets instead of opening the tag file through file://. A clean local package check does not clear those serving conditions.
Send a compact, redacted issue report
Use a report that lets the next person repeat the failure without reconstructing a chat history. For example, a fictional missing-image report could contain:
- Package:
spring-en-300x250-v03.zip, exact byte size and full checksum attached. - Context: target platform, HTML5 creative type, test placement, submission timestamp.
- Expected: the product image remains visible when the second headline enters.
- Actual: the second headline appears over an empty product area.
- Steps: extract the supplied ZIP, serve it over HTTP, reload with cache disabled, observe scene two.
- Evidence: failed request for
images/product.jpg; the file is absent from the extracted archive; console capture and short recording attached. - Scope: reproduced in this package; sibling sizes and platform acceptance not yet checked.
That is a hypothesis with supporting evidence, not permission to replace every asset. Confirm which approved image the scene requires and why the export omitted it, then test that specific correction.
Keep account IDs and preview links inside the approved support channel. Before sharing a network log, remove authorization headers, cookies, personal data, and sensitive query values. Retain the request path, status, timing, and sanitized error needed for diagnosis. Keep the unmodified evidence privately; do not publish client assets or logs in a public issue tracker.
Make one repair and keep the approved creative intact
Change the smallest source input that addresses the reproduced cause. A missing packaged file needs a packaging fix. A case-sensitive path mismatch needs consistent paths. A wrong authoring environment needs the correct export. None of those automatically calls for new motion, different copy, or a library upgrade.
Create a new version, retain the rejected version, and record the changed files. If the fix touches a shared template or asset pipeline, check every affected size and locale. If it is isolated to one export, state why the remaining packages are unchanged.
Volvo XC40
Compare first paint, each message scene, final frame, CTA, legal copy, and click behavior with the approved version. Recheck package weight when files change. Follow the existing ZIP QA checklist for those checks rather than expanding a focused repair into a redesign.
Close with the status that is actually proven
Retest the original reproduction steps against the new ZIP. Then ask ad ops to upload that exact replacement to the same target environment and capture the new result. A platform-specific failure is not resolved merely because the local preview looks right.
Keep these outcomes separate in the delivery note:
- Local checks passed: the reproduced package defect is fixed and the affected visual checks pass.
- Upload accepted: the target platform accepts the replacement artifact.
- Review pending or approved: report the platform’s actual review status.
- Serving verified: the intended creative and destination have been checked in the appropriate test placement.
If you do not have platform access, write “local checks passed; platform retest required” and name the ad ops owner. Attach the replacement filename, checksum, change summary, and test evidence. That gives the team a clear next action without claiming approval that nobody has observed.
A useful rejection workflow preserves the failure, narrows the cause, protects approved creative, and makes the retest repeatable. It ends with evidence from the environment that failed, not with the last ZIP production happened to export.