HTML5 Banner QA Matrix by Ad Platform

A banner can look approved, animate correctly, and still be the wrong package for the platform that needs to run it.

That is one reason display teams keep reliving the same launch pain. Creative review signs off on the idea. Banner export happens. Then the media or ad-ops team discovers a mismatch around click handling, fallback expectations, naming, or platform-specific upload assumptions.

The banner did not fail because the concept was bad. It failed because the QA process treated every destination as if it wanted the same artifact.

Bannerify is useful here because the plugin page and tutorial library are already built around exporting HTML5, GIF, MP4, WebM, and platform-oriented banner packages from Figma. The practical gain is not only faster output. It is letting design and ad ops review the right package shape before the campaign reaches the stressful part of launch.

This article is intentionally different from nearby Bannerify content like Display Ad QA Checklist Before Launch, HTML5 Ad Click Tag Checklist, and HTML5 Banner Trafficking Handoff Checklist. Those cover broad launch QA, click-tag specifics, or delivery handoff. This one is about comparing QA expectations by destination platform so the team stops assuming one HTML5 review pass covers every upload target.

The same creative can need different QA questions

The safest workflow is to stop asking only:

• Does the banner look right?

and start asking:

• Does this exported package match the platform we are sending it to?

That second question changes the review.

For one placement, the biggest risk may be click behavior. For another, it may be file organization. For another, it may simply be whether the media team wanted HTML5 at all.

That does not mean designers need to memorize every platform rule. It means the QA pass should expose the variables that tend to change by destination.

A practical QA matrix

Use this as the conversation starter before final export and handoff:

Destination	Main QA focus	Questions to answer before handoff
Google Ads or similar self-serve HTML5 upload	Package simplicity and click behavior	Did we choose the right export preset, confirm the expected click handling, and keep the package lean enough for media review?
DV360 or other programmatic-managed workflow	Naming and trafficking consistency	Does the package naming reflect audience, size, and variant clearly enough for the buying workflow?
AdForm, Sizmek, or publisher-managed HTML5	Delivery expectations and fallback assumptions	Has the ad-ops team confirmed whether any fallback image, alternate package, or special handling is expected?
Flashtalking or more managed rich-media workflow	Ownership of advanced behavior	Are interactions, exits, and any richer behaviors approved by the trafficking team rather than assumed by design alone?
Publisher-direct or custom IAB delivery	Exact upload instructions	Has someone confirmed the target environment wants this exact HTML5 package rather than GIF, MP4, or a different delivery method?

The key is not pretending this table replaces platform docs. The key is using it to stop the most common workflow failure: exporting first and clarifying the destination second.

Review the export preset as part of creative QA

Teams often treat export settings as an admin detail. They are not.

If the destination changes from:

• standard HTML5 upload
• to Google Ads
• to DV360
• to a publisher-direct placement

the team should re-check the export path instead of assuming the earlier package still fits.

That is especially important on fast campaigns where:

• one concept becomes many placements
• formats expand late
• the media plan changes after creative review

The design may remain valid while the packaging assumptions no longer do.

Platform QA should happen before the variant explosion

This matters more than it seems.

A team may start with one approved banner concept, then quickly multiply into:

• six sizes
• three audiences
• two languages
• two offers

If the platform expectations are still fuzzy at that point, the campaign becomes expensive to correct.

That is why I like running the platform QA conversation before full batch export:

1. confirm destinations
2. confirm required output types
3. confirm click-handling ownership
4. confirm fallback expectations
5. only then scale the variant production

If your workflow is still earlier than that and you are mapping placements or variants, Banner Variant Review Workflow for Campaign Teams and Spreadsheet-Driven Banner Variant Workflow are the best adjacent reads.

File naming becomes more important as platforms multiply

Platform-specific QA is not only technical. It is operational.

Once several destinations are involved, filenames need to expose the logic clearly:

• campaign
• audience
• market
• size
• format or platform grouping

If the package naming is vague, the media team has to reconstruct intent from context. That creates unnecessary launch risk even when the exported code is fine.

This is one reason platform QA and trafficking QA overlap. If the package is going to different systems, the package needs to say what it is.

For deeper naming guidance, Display Ad Asset Naming Convention for Agencies is the closest companion article.

Keep click-tag review separate from message review

Creative teams often check the CTA message and assume click behavior is covered.

It is not.

A good platform-aware QA pass separates:

• Is the CTA message right?
• Is the click behavior implemented the way the destination expects?

That distinction becomes especially important when:

• there are multiple exits
• the ad-ops team inserts or manages click logic
• the destination page changes late
• the campaign uses several trafficking systems

The banner can be visually perfect and still be operationally wrong if the ownership of click handling was never confirmed.

Choose the simplest acceptable output when the platform allows it

Some placements truly need HTML5. Some do not.

If the goal can be met with a lighter asset type for a particular destination, the team should say so early instead of forcing HTML5 everywhere out of habit.

That is not a Bannerify limitation. It is exactly where Bannerify becomes more useful:

• HTML5 where the placement benefits from it
• GIF or MP4 where the workflow is simpler
• consistent production from the same Figma source either way

The review question is not “Can we export HTML5?” It is “Should this destination receive HTML5?”

That is the same kind of judgment behind When to Use HTML5 vs GIF vs MP4 Banner Exports, but this article focuses on QA ownership by destination rather than format choice alone.

A practical platform-aware QA flow

Before exporting the full campaign, I would standardize this sequence:

1. List the actual destinations in the media plan.
2. Confirm the expected output type for each destination.
3. Review click ownership, fallback expectations, and package naming by destination.
4. Export a representative sample package first.
5. Let ad ops or the trafficking owner validate the package shape before batch export.
6. Scale the campaign only after the destination assumptions are real.

That sample-package step saves a huge amount of cleanup. It is much better to find out one 300x250 package needs a different workflow than to discover it after exporting seventy files.

Where Bannerify helps most

Bannerify gives teams a fast way to keep the banner source, animation logic, and export workflow inside Figma. That speed is valuable. But speed creates more leverage only when the team is exporting the right package for the right destination.

That is the real point of a platform-aware QA matrix.

Campaigns do not usually fail because nobody reviewed the colors. They fail because the destination workflow was treated as an afterthought. Once the platform questions are pulled into the QA pass early, the creative review becomes much more likely to survive contact with launch reality.