Most banner handoff problems do not start inside the animation. They start when the delivery folder contains unclear names, mixed revisions, missing backup images, or a ZIP that looks current but belongs to yesterday’s copy round.

A clean versioning system keeps the launch calm. It gives every deliverable a stable identity, makes revision changes visible, and helps ad ops traffic the right files without reconstructing the campaign from chat history.

Name files for the person trafficking them

The best banner ZIP name is boring and specific. It should tell a human what the file is before they open it: brand, campaign, market or language, size, platform if needed, and version.

A practical pattern might look like this:

brand_campaign_market_size_platform_v03.zip

For example, relevate_cashplus_en_300x250_dv360_v03.zip is much easier to audit than 300x250_final.zip. If the same creative goes to several platforms with different ClickTag or weight rules, include the platform in the name. If the platform rules are identical, keep the name shorter and record platform mapping in the handoff manifest.

Relevate Cash Plus

Relevate Cash Plus 300 x 250
Make the filename useful at traffic time, not only inside the production team. A compact financial unit needs clear ownership of market, size, destination, and revision. The ZIP name should answer those questions before ad ops opens the folder.

Keep version numbers tied to exported ZIPs

Version numbers should describe exported deliverables, not every internal design change. If a producer adjusts easing inside the source file but does not send a new ZIP, that does not need a new traffic version. If the headline, legal copy, ClickTag behavior, backup image, file weight, or final frame changes after delivery, it should become a new version.

This rule keeps versioning meaningful. v02 should mean “a different package was sent and can be compared with v01.” It should not mean “someone moved a layer during production.”

Add a short revision note for every delivery

The handoff does not need a long changelog, but it does need enough context to stop confusion. A simple manifest can include one row per ZIP with size, market, platform, destination URL source, version, status, and revision note.

Useful revision notes are concrete:

  • v02 - updated legal line and backup image.
  • v03 - changed CTA copy; ClickTag unchanged.
  • v04 - replaced product image; file weight rechecked.
  • v05 - publisher-specific ClickTag casing.

Avoid vague notes such as updated, new, or client changes. Those force ad ops and account teams to ask what actually changed, which is exactly what versioning should prevent.

Separate master versions from platform variants

A multi-platform rollout may have one approved creative version and several technical variants. For example, the creative might be v03, while DV360, Google Ads, and a direct publisher each need a slightly different package.

Do not hide those differences inside one generic ZIP. Either include the platform in the filename or group files by platform folder. The manifest should make the relationship clear:

  • Creative approval version.
  • Platform package version.
  • ClickTag expectation.
  • Destination source.
  • File-weight limit.
  • Backup-image requirement.
  • QA status.

CNC

CNC 300 x 600
Track creative approval and traffic package rules as related but separate facts. Image-heavy campaign units often pass creative review before final traffic rules are settled. Platform variants should stay visible instead of being folded into one ambiguous package.

Use folder structure to reduce mistakes

If a campaign has many sizes or markets, the delivery folder should make the current state obvious. One useful structure is:

campaign-delivery/
  manifest.xlsx
  v03-approved/
    en/
    de/
    fr/
  superseded/
    v01/
    v02/

The exact folder names matter less than the rule: current files are easy to find, older files are not mixed with approved files, and no one has to guess which package is safe to traffic.

For smaller campaigns, one folder plus a manifest is enough. For larger localization or publisher rollouts, separating market and platform variants prevents late-stage mistakes.

QA the package after renaming

Renaming is not the last step. After the final ZIP name is assigned, QA should confirm the package still opens, the main HTML file is in the expected place, the ClickTag still works, the backup image is present, and the file weight still matches the platform limit.

This matters because handoff changes are often made quickly: a folder is repackaged, a backup image is replaced, or a publisher-specific file name is applied right before delivery. The package that ad ops receives should be the package that passed QA.

Joerg Lienert

Joerg Lienert 300 x 250
Run final QA on the named delivery ZIP, not only on the source preview. Leaderboard units are easy to mistake for one another in a busy delivery folder. Names and manifest rows should make size, market, and version unmistakable.

What a useful handoff manifest includes

A practical banner handoff manifest should be short enough that people actually use it. Include the fields that affect launch:

  • ZIP filename.
  • Size.
  • Market or language.
  • Platform or publisher.
  • Version.
  • Destination URL source.
  • ClickTag rule.
  • ZIP weight.
  • Backup-image filename.
  • Revision note.
  • QA status.

The manifest is not there to impress anyone. It is there so the person uploading the banners can tell which file is approved, why it changed, and whether any platform-specific rule applies.

Good versioning makes banner delivery feel less fragile. Designers can keep improving the creative, producers can package cleanly, account teams can explain revisions, and ad ops can traffic files with fewer last-minute questions.