Responsive display ads let you provide creative assets and a destination URL while Google Ads combines eligible assets and adapts their size, appearance, and format to available inventory. A retailer might provide approved product images, headlines, descriptions, a logo, and a landing page instead of producing a separate finished image ad for every format.
The trade-off is control. Google determines many final combinations and renderings, so the advertiser approves an asset pool rather than a single guaranteed composition. This guide covers current asset specifications, the distinction between UI and API requirements, a practical preflight, and the records to retain after submission.
Use the current ratio and dimension requirements for responsive assets rather than relying on traditional fixed banner-size lists. Google describes broader placement flexibility and may use video instead of images when its systems determine that video could perform better, but neither capability guarantees more reach, clicks, conversions, or lower costs. See Google’s explanation of responsive display ad behavior.
What responsive display ads do
A responsive display ad is an asset-based format. Advertisers supply items such as images, headlines, descriptions, a business name, a final URL, and optionally logos or YouTube videos. Google combines eligible assets and adapts the ad to available inventory across supported surfaces. One rendering may use a different layout, crop, or asset combination from another rendering of the same ad.
This differs from uploading a finished fixed-format image ad, where the advertiser has much more control over the final composition. Responsive display ads can reduce the manual work of producing multiple variations, but Google, not the advertiser, controls many delivery decisions. The official guidance also says that video may be used instead of images when Google’s systems determine that video could perform better. Treat that as a delivery capability, not a performance promise.
Decide whether the format fits your creative needs
Choose responsive display ads when valid assets and placement flexibility matter more than exact layout control. They can be useful when a team has several approved creative elements but does not want to build every possible format manually. They are a poorer fit when a legal statement, price condition, product disclosure, or strict brand composition must remain in a precise position.
Approve every asset as though it could be paired with any other eligible asset. If a headline, image, logo, or description becomes misleading when shown independently, use a fixed-format creative or revise the asset set before submission.
Google’s responsive display best practices can inform creative review, but they do not replace campaign testing. Evaluate the format using the advertiser’s own conversion and cost objectives rather than assuming that more assets or more combinations will improve performance.
Prepare assets to current specifications
The current Help Center specifications set the following limits. Counts and recommendations should be checked again before production because Google Ads interfaces and API versions change.
- Short headlines: 1 to 5, with a maximum of 30 characters each.
- Long headline: 1, with a maximum of 90 characters.
- Descriptions: 1 to 5, with a maximum of 90 characters each.
- Business name: a maximum of 25 characters.
- Marketing images: 1 to 15 combined across supported image fields, with a maximum file size of 5 MB per image.
- Logos: 1 to 5 combined across square and landscape logo fields. Logos are optional.
- YouTube videos: up to 5 optional videos.
For marketing images, use a 1.91:1 landscape ratio. Google recommends 1200 x 628 pixels and lists 600 x 314 pixels as the minimum. Use a 1:1 square ratio, with 600 x 600 pixels recommended and 300 x 300 pixels as the minimum. Google recommends five images for each supported ratio where possible. That is a recommendation, not a required count or evidence of a conversion lift.
Google supports square and landscape logos and recommends providing both where possible. Its guidance also advises avoiding excessive padding and small logo text. Google recommends keeping overlaid text and logos below 20% of an image. This is best-practice guidance, not a universal automatic-rejection rule. Review the current responsive display asset specifications, logo and asset guidance, and image overlay guidance.
If no video is supplied, eligible ads may use an auto-generated video. Generation is not guaranteed. Google lists at least one landscape image, one headline, and one description as prerequisites and notes that low-quality, duplicate, overly similar, or border-heavy assets can prevent generation. Check the auto-generated video requirements if this option matters to the campaign.
- Count characters, verify required fields, check image ratios and minimum dimensions, and enforce the 5 MB image limit with deterministic rules.
- Record each asset’s type, dimensions, file size, rights or approval status, expiration date where relevant, and Google asset resource name after upload.
- Confirm that the final URL uses an approved HTTPS host, follows an authorized redirect path, and reaches the intended landing page.
- Ask a named human reviewer to verify claims, trademark permissions, promotion dates, offer terms, and cross-asset accuracy.
- Keep essential disclaimers and conditions understandable without relying on one particular image, headline, or rendering.
Create an ad in the Google Ads interface
The durable workflow is to open Google Ads, navigate to the relevant campaign’s Ads area, choose the option for a responsive display ad, select an ad group, add the available text and creative assets, enter the business name and final URL, review the preview, and save. Depending on the account and setup, the interface may also expose video, call-to-action, promotion, price-prefix, color, and tracking fields. Google’s current creation guide describes the available fields.
Do not treat older instructions using labels such as “All Campaigns,” “Display Campaigns,” or “Ads & Extensions” as universally current. Google has described a transition from Display toward Demand Gen, so campaign availability and navigation can vary by account. Verify the interface before publishing screenshots or exact click paths.
Before saving, inspect the available previews, test the landing page, confirm tracking parameters, and check whether an essential offer condition depends on a combination that may not appear in every rendering. A saved ad is not necessarily approved or serving.
Use an operational preflight before submission
Separate what a system can prove from what requires judgment. Character counts, image dimensions, file size, required fields, approved hosts, duplicate detection, and status transitions are deterministic checks. Claim substantiation, trademark permission, promotion terms, destination relevance, and cross-asset meaning require an accountable human decision.
AI can flag ambiguous claims, identify likely brand inconsistency, group similar assets, or prioritize a review queue. It should not make final legal, policy, rights, authorization, or destination decisions. ConsultEvo’s AI agent design and implementation service is relevant when defining that bounded review role.
The following workflow is a proposed internal control pattern, not a Google feature. Its outputs should be stored with the original payload so a later reviewer can reconstruct what was checked and approved.
A useful internal record can include field-level pass or fail results, review notes, the review owner, the workflow run ID, and the exact payload submitted. Use ordinary parsing and allowed-value checks for numeric limits and statuses. Use AI only to help prioritize uncertain content for the named owner.
Create responsive display ads through the Google Ads API
Google documents an API route that uploads creative assets through AssetService, constructs a ResponsiveDisplayAdInfo object, sets the final URL on the parent Ad, and creates the ad through AdGroupAdService.MutateAdGroupAds. The workflow requires an authorized customer, compatible campaign and ad-group resource names, uploaded asset resource names, a valid destination, and fields supported by the API version in use.
The API documentation requires at least one landscape and one square marketing image for API-created ads. Keep that requirement separate from the way UI guidance summarizes image requirements. Use Google’s API creation example as a version-specific implementation reference, not as a complete production integration. Recheck the current ResponsiveDisplayAdInfo reference before implementation.
Before mutation, validate authorization, campaign and ad-group compatibility, current field names, asset requirements, approvals, destination, and text limits. Store the mutation response and returned Google resource name. A successful mutation means that Google accepted the creation request; it does not establish policy approval or serving.
Prevent duplicate creation under concurrency
For each intended ad, normalize the customer, ad-group resource name, final URL, relevant controls, text assets, and Google asset resource names. Compute an internal content hash from those normalized values. Enforce uniqueness with a database unique constraint or transactional upsert before calling the mutation. A read-then-create check alone can race when concurrent workers submit the same payload.
Keep the internal content hash, workflow run ID, and Google ad resource name as separate identifiers. The hash identifies the intended ad payload. The run ID identifies one execution, including retries. The Google resource name identifies the vendor record. On a transient API error, check the stored operation and creation record before retrying rather than blindly repeating a non-idempotent write.
Retrieve ads and keep reporting at the right grain
Google documents retrieval through GoogleAdsService.SearchStream, querying ad_group_ad and filtering for RESPONSIVE_DISPLAY_AD. The retrieval guide shows the ad-level route. Pin implementation to a supported API version and validate its fields before deployment.
Do not use ad_group_ad_asset_view as a complete responsive-display asset-performance source. The reviewed v22 field reference says that this view does not support Responsive Display Ads. Verify an alternative reporting resource and its metric coverage before promising an asset-level export.
Separate records by row grain so a retrieval run, attached asset, ad, raw observation, and reported summary cannot be mistaken for one another:
- Ad record: one Google Ads ad resource, with its status and available creative fields.
- Asset reference: one asset attached to one ad, identified by the ad and asset resource names.
- Run record: one create, update, or retrieval execution, identified by a unique workflow run ID and timestamp.
- Raw observation: one returned metric or record at the dimensions supplied by the report, such as ad, date, device, placement, or geography.
- Reported summary: one explicitly defined aggregation, such as one ad, campaign, date range, metric, and reporting dimension set.
- CRM event: one separate contact, lead, or deal event with its own CRM identifier. Do not merge it with an ad run or performance aggregate.
If storing citations or provenance, give each source claim its own record key rather than attaching all citations to a daily run. If multiple runs occur on the same date, include the run ID or execution timestamp. If metrics are grouped by device, placement, geography, or report period, include those dimensions in the aggregate key.
What to verify after submission
Check the ad’s creation result, policy status, and serving status separately. A saved UI draft or successful API mutation confirms only that the ad was saved or the request was accepted. It does not confirm that the ad passed review, is eligible, or has delivered impressions.
Evaluate performance using the advertiser’s own conversion, cost, and business measures. Do not infer a universal lift from the asset count, responsive format, or Google’s recommendation to provide five images per ratio. Preserve the approved payload, asset references, final URL, reviewer, submission response, Google resource name, policy state, and reporting query scope for auditability.
The practical success condition is therefore operational as well as numerical: the right assets were validated, the right person approved the claims and rights, the intended payload was submitted once, the resulting Google state was checked, and any performance summary can be traced to its reporting grain.