When building a Native ad bidding system, the first headache usually isn't the bidding strategy or the CTR model — it's image sizes.

The bid request's imp.native.request carries width and height requirements for main images, icons, and logos. Every publisher, app, and placement is different — some give exact w / h, some give wmin / hmin, some only give ratios, some give nothing but the SSP rendering template implies size constraints. The same ad slot with different rendering templates may require completely different image specs. And that's just one exchange. Once you've integrated a dozen exchanges, hundreds of publishers, and thousands of placements, the size matrix becomes something you don't even want to look at.

The most intuitive reaction: pre-crop all possible sizes. A step further: consider real-time cropping during bidding.

Both paths seem viable, but dig in and each has its own traps. This post discusses what's wrong with both, and whether there's a different direction — reframing the problem from image processing to creative deliverability management.

Enumerating Sizes: Intuitive but Unsustainable

Cropping an advertiser's main image into all possible sizes sounds like the safest approach. The traffic side gets exactly what it asks for; you never lose an impression to size mismatch.

Let's look at the numbers.

Suppose Native images need to cover widths from 100px to 1200px, heights from 100px to 1200px, plus common aspect ratios — 1:1, 1.91:1, 16:9, 4:3, 4:5, 9:16 — just the main image alone might need dozens of variants. And that's one image from one advertiser. Advertisers typically have multiple main images in a campaign. A DSP runs hundreds to thousands of campaigns simultaneously. Each campaign has main images, icons, and logos. Variant counts grow fast.

Storage and compute costs might be tolerable. What really hurts is review.

Most exchanges require creative images to be submitted for review in advance. Different exchanges have independent review systems — passing Google's review doesn't mean passing Xandr's. If you've integrated 10 exchanges and generate 20 aspect ratio variants per main image, that's 200 images awaiting review, per advertiser, per campaign. Review turnaround times range from minutes to days depending on the exchange. The advertiser asks "why aren't my ads spending?" and the answer is "160 images are still pending review."

Then there's the update problem. An advertiser changes a main image — maybe just adjusting logo placement or swapping a background color — and all variants must be regenerated, resubmitted, re-reviewed. All previously approved variants are voided. This maintenance cost isn't one-time; it persists throughout the campaign lifecycle.

More critically: most variants go unused. Analyze the actual bid request size distribution and you'll find, empirically, that a few popular aspect ratios cover the majority of requests in typical Native traffic, while numerous long-tail sizes appear very infrequently. The review and maintenance cost of generating variants for these low-frequency sizes far exceeds the incremental revenue.

Enumerating sizes is fundamentally a decision driven by "fear of missing opportunities," but marginal returns diminish while marginal costs stay constant or increase — review, storage, update maintenance, not one image fewer.

Real-Time Cropping: Turning an Image Processing Problem into an Ops Problem

If enumerating doesn't pay, what about cropping dynamically during bidding? The logic is straightforward: receive bid request → parse size requirements → crop from the original → return a new URL.

There's enough CPU, image processing libraries, and CDN support for dynamic uploads. The chain works. Technically it's doable. But putting image processing inside the bid handler introduces three harder problems.

Review loss of control. The bid handler produces a brand-new image. What it cropped, whether it cut off a logo or text, whether it decapitated a person, whether the visual quality is acceptable — the review system has no idea. Many exchanges require creative assets to be pre-submitted and approved before bidding. The URL generated by real-time cropping isn't on the approved list; the exchange may reject it at serve time. Once rejected, the CPU time, network I/O, and bidding opportunity for that bid are all wasted. If an exchange has a cumulative penalty mechanism for review rejections, frequent rejections can drag down the bidding performance of other normal creatives.

Debugging loss of control. An advertiser complains "my ad looks distorted on this app." You trace the logs: what size did the bid request specify? What were the crop parameters? Which version of the original image? Which CDN node did the cropped image land on? These questions are extremely hard to answer in a real-time cropping pipeline because cropping is a one-shot, stateless operation. Logs might record the request dimensions but not the cropping result — you can't know what the image actually looked like. Troubleshooting requires jumping between request logs, cropping service logs, and CDN logs — a long chain with scattered information.

Cache loss of control. Same creative, same size — if you generate a new URL every time, CDN cache hit rate is zero. Every impression hits the origin, and image delivery latency becomes unstable. If you reuse URLs, you need deduplication logic in the bid handler — "have we cropped this size before?" "What URL did it produce?" — which is essentially coupling the cropping service's state management into the bidding pipeline. The bid handler should be stateless with predictable latency; adding a distributed state query risks blowing the latency budget.

Speaking of latency budgets: one might think, "with enough engineering resources, couldn't we build an independent cropping service, persist cropping logs, set up an automated review pipeline — engineer away the ops problems too?" It's not impossible. But do the math: the additional infrastructure you'd introduce serves precisely the long-tail sizes (mainstream sizes are handled by pre-generated variants). Whether the incremental revenue covers the incremental system complexity is not obvious. For resource-constrained teams, the math is even harder.

Real-time cropping's problem isn't technical feasibility. Its real cost is turning image processing into an ops problem, and ops problems have a characteristic: the cost of failure doesn't show up in development — it shows up in production, where it's hard to reproduce and has long troubleshooting cycles.

A Different Angle: Neither Protocol Nor Platform Requires This

After falling into both traps, look back at the OpenRTB Native protocol and you'll notice something previously overlooked.

The OpenRTB Native Ads 1.2 Image Request Object defines type (image asset type), w / h (suggested dimensions), wmin / hmin (minimum dimensions), and mimes (supported MIME types). The protocol requires the DSP's response to satisfy the type, size, and MIME constraints of required assets, but it doesn't prescribe how the DSP satisfies them, let alone require the DSP to pre-prepare images for every size.

Note the semantics of wmin/hmin — "minimum requested dimensions." This at least shows the protocol allows expressing a range, not just pixel-exact sizes. As long as the creative dimensions are no smaller than the minimum, whether the platform downscales, pads, or does limited cropping afterwards depends on the exchange, publisher rendering method, and bilateral agreements. Precise w/h requests should be handled more cautiously: on some platform practices they can be matched by aspect ratio, but you can't default to all SSPs accepting this flexibility.

The protocol gives room for flexibility. The question is whether the DSP is willing to use this room rather than backing itself into a "pixel-perfect matching" corner.

Look at platform documentation. Google Authorized Buyers' native creative specs explicitly state that publishers may resize images without changing aspect ratio, and allow limited symmetric cropping in one direction; when sizes don't exactly match, padding can avoid distortion. Xandr's Smart Image Adjustments documentation describes similar logic — when an image doesn't perfectly match a placement, the platform can pad with whitespace while limiting the scaling range, with the original image dimensions determining the final adaptable range.

These platform docs aren't IAB-enforced standards and can't be generalized to all SSP behavior. But they at least show: some leading platforms take on part of the adaptation responsibility themselves and don't require DSPs to enumerate images for all sizes. The safer approach is to treat platform adaptation capabilities as partner-dimension configuration, not as a global assumption.

A Workable Direction: Manage Creative Deliverability, Not Image Processing

Reframe the problem and things become much clearer.

Don't ask "how do I generate the right image for every size." Ask "how do I determine whether a creative can serve for this bid request." The first is an image processing problem; the second is a matching problem. Matching can be done in sub-millisecond; image processing can't. Put processing before the bid, matching during the bid, and don't mix the two.

From this angle, creative system design can be thought of in three layers.

Layer 1: Distinguish asset semantics.

Native images aren't just "images." The OpenRTB Native protocol defines multiple image asset types: main image, icon, logo, app icon, etc. Different semantic images have different purposes and constraints. Main images are typically large, information-rich, and need multi-ratio adaptation. Icons and logos are small, brand-identity images that shouldn't be cropped from the main image — shrinking a 1200x1200 main image to 128x128 for an icon may render the brand mark an unrecognizable blob. Conversely, upscaling an icon to serve as a main image guarantees pixelation.

This layer seems simple, but if the creative library starts out managed as just "images," retroactively adding semantic tags is expensive.

Layer 2: Manage a limited set of aspect ratio variants.

Don't generate variants for every pixel size. Instead, select a set of ratio buckets. Common candidates include 1:1, 1.91:1, 16:9, 4:3, 4:5, 9:16. Which and how many to choose should come from traffic data analysis — examine the distribution of img.w, img.h, img.wmin, img.hmin in bid requests to find the ratios that cover the bulk of traffic. This isn't a one-time decision; it can be periodically adjusted. Long-tail ratios can be no-bid initially, then supplemented with new variants based on revenue opportunities.

Generate variants for main images by these ratios. Manage icons and logos separately; they don't participate in the main image cropping pipeline. Other exchange- or publisher-specific image asset types follow the same logic for whether independent variants are needed.

Layer 3: Match only during bidding.

The bid handler logic is a straight line: parse request → filter by asset type → check MIME allowability → check if size falls within a variant's serviceable range → check review status on that exchange → if matched, return the native response; if not, no-bid.

The serviceable-range check doesn't need complex logic: precise w/h request — check if there's a matching or near-matching variant; wmin/hmin request — check if the variant dimensions are no smaller than the minimum; ratio-only request — check if there's a variant for that aspect ratio. All checks are integer comparisons — no floating point, no image libraries.

The creative index's core fields are roughly: creative_id, asset_type, asset_id, ratio_bucket, url, width, height, mime, file_size, audit_status_by_exchange. The bid handler does an index lookup, O(1) complexity.

Boundaries: What Works, What Doesn't, When to Let Go

The above approach isn't universal. Several boundaries are worth clarifying.

When cropped variants are needed. Only main images need multi-ratio variants. Icons, logos, and other brand-identity assets are managed separately, not cropped. Video thumbnails and other special types are handled per actual requirements.

Directionality of scaling. Downscaling is generally acceptable; obvious upscaling is not. Request wmin=600, hmin=315, you have a 1200x628 variant — serve it. Conversely, request 1200x628, you only have 600x314 — don't upscale and bid. Quality loss from downscaling is typically imperceptible at render time; upscaling blur is immediately visible. Google's docs explicitly state that scaling must not change aspect ratio; Xandr similarly notes that automatic adjustments have scaling range limits. Both point to the same principle: creative dimensions should be no smaller than requested.

Platform capability boundaries. Google Authorized Buyers and Xandr explicitly support padding or limited auto-adjustment, but not all SSPs have this capability. Before relying on platform auto-processing, confirm that partner contracts or platform docs explicitly commit to it. Treat platform capabilities as bonus, not guarantee.

When to firmly no-bid. Required asset missing, MIME unsupported, minimum resolution unmet, precise size request with no matching variant, aspect ratio mismatch too large (cropping would destroy subject content), creative unreviewed/expired/rejected on that exchange, platform requires re-review and the new URL hasn't passed — don't bid in these cases.

No-bid costs one impression opportunity. Bidding incorrectly costs not only the resources for that bid but also: potential exchange filtering, low CTR impacting future bidding performance, advertiser complaints, and troubleshooting labor. More importantly, no-bid preserves future matching opportunities — when the creative library expands or ratio variants are supplemented, the same matching logic applies immediately. But incorrect bidding that leaves a review rejection record or low quality score costs far more to fix than never bidding in the first place.

On focal points and safe zones. This is the most uncertain part of the entire discussion. Even with correct-ratio cropping, you might cut off key elements — people decapitated, logos at edges, text bisected. The ideal solution is face detection, subject detection, saliency detection for automatic focal point identification, combined with manual confirmation, generating preview images for each ratio variant and marking safe zones. Images containing text need extra caution — text cropped in half is usually directly unusable. But in practice, process maturity varies widely; there's no universal solution. All we can say: downscaling is safer than cropping, cropping is safer than forced adaptation, and doing nothing is safer than blind guessing.

Closing

The core of this approach is simple: reframe the creative asset problem from "how to process images" to "how to determine deliverability." Image processing happens before the bid; during the bid, only matching happens; when there's no match, don't force it.

But several questions still don't have fully satisfying answers.

The traffic-data-driven ratio selection approach assumes sufficient bid request volume for statistical analysis. For smaller DSPs, the statistical distribution may be unstable; during cold start, is relying on industry-common ratios more practical?

Different SSPs vary widely in how they handle image size mismatches — some pad, some reject, some silently resize, some accept first and reject on review later. A systematic way to manage this difference matrix hasn't emerged as a mature solution yet.

The balance between automated focal point detection and manual confirmation — how to implement this without it becoming a bottleneck for resource-constrained teams — seems to rely more on experiential judgment than replicable methodology.

If you're working on something similar, with different approaches or ideas, talk to me.

References