HTML5 Animated Banners Built to Pass Ad Server QA

An HTML5 banner set fails at the ad server far more often than it fails in the market, and the two causes repeat every year: a ZIP over the 150KB Google Ads limit, and a backup image exported as an afterthought. A real share of your impressions render that backup, so it is drawn as a finished ad that carries the offer without any help from the animation. If the backup cannot carry it, the animation was concealing a weak line rather than delivering a strong one, and that is worth knowing before the build starts. Timing: Fifteen seconds, three loops, then stop, with the endframe holding the offer, the mark and the legal line. That is the Google and IAB position and I build to it even where a publisher permits more, because a banner still moving on a page somebody is trying to read is an argument for installing a blocker. Thirty frames per second, transforms and opacity only. Animating layout properties is why a 300x600 stutters on a mid-range Android. Build: Hand-coded with GSAP 3 where timing has to be exact, Google Web Designer where your team needs to edit the set later without me, Adobe Animate only when a legacy source file makes it the cheaper route. Whichever tool, the output is a ZIP with no external requests, clickTag wired for the network it is going to, Enabler exits where the set runs through Campaign Manager 360 or Studio, and separate builds per ad server rather than one archive relabelled and hoped for. Weight: Image budgets are set before the design is approved, not squeezed afterwards to reach the limit. Photographs at JPEG quality 60 to 70, flat elements as SVG, no webfont file where a rendered text layer will do. If a concept needs a 400KB hero photograph, the concept changes at briefing instead of the photograph turning to mush at the end. QA: Every size checked inside the ad server's own preview, not only the authoring tool's, because a Google Web Designer preview is not evidence of anything. Checks on iOS Safari, Chrome on Android and one older handset. Console clean, click-through verified against the tagged URL, backup weight under limit, and the endframe legible at the smallest size in the set. Delivery: Source files, per-network archives, backup images, a QA log per size naming the ad server it was checked against, and a handover call with your ad ops team. Where your agency traffics the set I speak to them directly rather than through you, which removes the week normally lost to relayed screenshots. Not included: Expandables, interscrollers, in-app MRAID units and anything measured through the Open Measurement SDK; that is separate work. In-banner video. Feed-driven dynamic creative. Media buying and placement. Concepting a set from nothing: without an approved static direction, that is where we start instead, and I will say so rather than invent one at build prices. Who this is not for: Anyone needing a full set live within forty-eight hours. Re-timing an approved set costs more than designing it did, so I build once the offer and the legal line are settled. If the disclaimer is still with your legal team, we are not ready, and I would rather say that at briefing than invoice you for the rebuild afterwards. Sets that already exist: I will take a set that fails QA or renders badly on mobile and repair it against the ad server's spec. That is quoted once I have opened the source, and I will tell you when a rebuild is cheaper than a repair instead of billing the repair twice.