The delivered HTML5 ZIP is only one part of a banner project. It is the package ad ops uploads, but it is not always enough for the next production request: a new size, a revised headline, a translated legal line, a publisher-specific ClickTag rule, or a seasonal image swap.

When the source archive is clean, future work starts from the approved campaign system. When it is messy, the team has to reverse-engineer the banner from an exported ZIP, old screenshots, and chat history. That costs time and increases the chance of rebuilding something that was already solved.

Save the production source, not only the trafficked ZIP

The trafficked ZIP should stay lean. It should not contain design files, working exports, unused images, or notes. The source archive is different. It should preserve the files a producer needs to make a controlled edit later.

For HTML5 banners, that archive might include:

  • The working source folder or repository snapshot.
  • Original image assets and approved crops.
  • Fonts or documented font fallbacks.
  • Copy deck and legal text source.
  • Motion notes or GSAP timeline labels.
  • Final exported ZIPs and backup images.
  • Platform specs used for the approved delivery.
  • Revision notes explaining what changed.

The archive does not need to be elaborate. It needs to be complete enough that the next producer can understand what was approved and what can safely be changed.

Atlas Ski

Atlas Ski 300 x 250
Keep the editable campaign system separate from the lightweight traffic package. Travel units often rely on a set of image crops, offer copy, and pacing choices. A future seasonal update is much easier when those source decisions are archived beside the delivered ZIP.

Record which file is the master

Multi-size campaigns often have one size that behaves like the creative master. It may be the first approved layout, the size with the full message hierarchy, or the most flexible motion build. Name it clearly in the archive.

That note matters when a future request arrives. If the team needs a 300 x 600 after launch, should production adapt from the approved 300 x 250, from a Figma frame, or from another tall unit that already solved the vertical layout? Without a master note, the next person has to guess.

Keep assets with their usage notes

Source files are most useful when they include intent. A folder full of images is better than nothing, but a producer still needs to know which crop was approved, which product shot is mandatory, and which background can be swapped for a localization or seasonal refresh.

Useful asset notes are simple:

  • Hero image crop priority.
  • Logo version and safe clear space.
  • Product or offer image that must remain visible.
  • Legal copy source and allowed line breaks.
  • CTA text rules.
  • Brand color or font substitutions.

These details prevent small future edits from changing the campaign by accident.

Tweed

Tweed 300 x 600
Archive the reason behind the crop, not only the file itself. Tall product-led banners can depend on precise device crops and stacked message order. The archive should explain which visual priorities made the approved layout work.

Store platform rules beside the source

A future update is not only a design task. It still has to pass the same traffic rules: file weight, backup image, ClickTag variable, animation duration, loop behavior, and ZIP naming. If those rules are separated from the source files, a small copy change can become a platform QA surprise.

Keep the final spec matrix or manifest in the archive. If a publisher had a special rule, write it down. If a platform variant used a different ClickTag casing, keep that visible. If the same creative was delivered to several markets, include the destination URL table that ad ops used.

The goal is continuity. The next update should inherit the right constraints instead of rediscovering them after export.

Freeze the approved version before making new edits

When a post-launch change arrives, duplicate the approved source before editing. Do not overwrite the version that was trafficked. That original archive is the rollback point, the comparison source, and the evidence for what was approved at launch.

A practical folder structure can stay modest:

campaign-source/
  v01-approved-launch/
  v02-legal-update/
  final-zips/
  backup-images/
  source-readme.md
  specs-and-urls.xlsx

The exact names are less important than the rule: approved work stays preserved, new work gets its own version, and the delivery files can be traced back to the source state that created them.

Babcock

Babcock 300 x 250
Treat source continuity as part of the production deliverable. B2B campaign units often come back later with revised proof points, refreshed imagery, or a new CTA. Keeping source context makes those updates safer than rebuilding from an old ZIP.

What to include in a banner source archive

Before closing the project, check that the archive includes:

  • Approved source files or repository snapshot.
  • Final exported ZIPs by size, market, platform, and version.
  • Backup images used for each ZIP.
  • Original assets and approved crops.
  • Copy source, legal text, and destination URL table.
  • GSAP or motion notes where timing matters.
  • Platform specs and publisher caveats.
  • Readme with master size, latest version, and owner notes.

This is not extra admin for its own sake. It is how an agency keeps a banner campaign editable after launch. The next request starts from known good work, the client sees faster turnaround, and ad ops receives packages that still match the original production rules.