How do you verify that an ecommerce PDP supports every ad promise?

01

What counts as a promise in an ecommerce ad?

A promise is any explicit or reasonably implied message that could influence what a customer expects to receive, pay, experience, or qualify for after clicking.

Audit written copy, voiceover, captions, product demonstrations, before-and-after sequences, imagery, badges, reviews, testimonials, guarantees, shipping statements, calls to action, and the destination URL. Include implied product details such as color, material, quantity, packaging, accessories, or bundle contents. A case pictured beside a product, for example, may imply that the case is included even if the copy never says so.

Also capture messages created by elements in combination. “Save 50%,” a product image, and “Shop now” can collectively imply that the pictured variant is currently available at half price. The creative team’s intended reading is not the only relevant interpretation. The FTC’s advertising-substantiation policy addresses objective claims conveyed expressly or by implication and says advertisers should have a reasonable basis before disseminating them.

Testimonials belong in the ledger too. According to the FTC’s endorsement guidance, an endorsement cannot communicate a deceptive or unsubstantiated claim that the advertiser could not make directly.

02

What should you freeze before starting the audit?

Record the exact creative, destination, selling context, and launch window being reviewed so the approval cannot drift away from the live campaign.

Capture the campaign and ad identifiers, creative version, final URL, redirects, query parameters, target country, language, currency, principal devices, audience restrictions, schedule, SKU, intended default variant, promotion code, and eligibility rules. Note whether the ad uses feed-driven, automated, or responsive components. This is also the right point to run the broader ecommerce creative launch QA checklist.

Do not approve only one attractive preview when responsive delivery is enabled. Google explains that responsive ads can adjust their size, appearance, and format and are assembled from supplied assets. Its responsive-search-ad combinations report shows combinations that received impressions. Audit individual assets and plausible combinations because an image and headline can create an implied promise when served together.

Give this frozen set a version and timestamp. If copy, imagery, URL, targeting, offer dates, variant selection, or inventory changes later, create a new version or reopen the existing audit.

03

How do you extract promises line by line?

Review the ad frame by frame and asset by asset, translating each customer-facing message into a plain, testable sentence.

Use separate rows for product identity, variant, performance, customer outcome, price, offer, availability, fulfillment, returns, proof, and disclosures. Never place “50% off, free shipping, arrives Friday” in one row: the discount may be correct while the shipping threshold or delivery expectation is wrong.

Add an “interpretation” field for nonverbal or indirect messages. Useful formulations include “The pictured travel case is included in the advertised price,” “This result is typical when the product is used as shown,” and “The displayed discount applies to the default selected variant without a subscription.” These sentences make implied assumptions reviewable.

For responsive formats, create rows for messages that emerge from combinations as well as rows for standalone assets. Preserve the frame, timestamp, headline, description, image name, caption, or voiceover excerpt that generated each promise.

1. Watch the ad once as a customer without pausing.
2. Review it again frame by frame and transcribe every factual statement.
3. List visual implications, demonstrated outcomes, and depicted bundle contents.
4. Split every compound promise into independently verifiable rows.
5. Review possible responsive combinations for new or conflicting meanings.

04

How should each promise map to the product page?

Each ledger row should point to the exact PDP element and commercial state that supports the promise—not merely to the page URL.

Record the relevant heading, paragraph, image, table, selector, accordion, badge, FAQ, or policy link. Verify the default variant, displayed price and currency, inventory status, bundle contents, required code, subscription setting, order threshold, shipping estimate, and return conditions. Repeat the check on mobile and desktop, because support that is technically present but inaccessible or difficult to find may not resolve the customer’s expectation.

Deep-link to the correct variant when possible. Google’s Merchant Center landing-page requirements recommend preselecting the variant that corresponds to the advertised product data. Google’s product-data specification also requires submitted price and availability information to match the landing page and product data. Check checkout when taxes, discounts, gifts, subscriptions, or shipping thresholds affect the advertised total.

Separate page support from claim substantiation. Repeating “lasts 24 hours” on the PDP confirms message consistency but does not prove the performance claim. Link the ledger row to the applicable test, certification, supplier documentation, approved claims file, or other substantiation. If the reviewer cannot inspect that material, use “unable to verify,” not “pass.”

Material qualifications should be close enough to the claim for customers to encounter them. The FTC’s digital-disclosure guidance emphasizes clear and conspicuous disclosures that work across devices and are placed close to the claims they qualify.

05

How do you grade a mismatch and choose a correction?

Use a controlled status and severity system so reviewers do not resolve the same problem differently from one launch to the next.

Recommended statuses are: Pass, Qualified pass, Page gap, Ad overreach, Contradiction, Unsubstantiated, Unable to verify, and Not applicable. A qualified pass means the promise is supported only under a condition that is clearly disclosed. “Not applicable” should require a written reason rather than serving as a shortcut.

Use Blocker for a wrong product or variant, incorrect price, unavailable offer, unsupported objective claim, missing material condition, contradictory guarantee, or fulfillment promise operations cannot support. Use Major when valid support is incomplete, difficult to find, or inconsistent on an important device or locale. Reserve Minor for nonmaterial wording or documentation issues.

Every failed row needs an explicit correction route: revise or remove the ad asset; add or clarify PDP content; change the final URL; preselect the correct variant; correct feed, price, structured data, or availability; add offer or shipping qualifications; restrict geography or dates; adjust a responsive setup; or pause for legal, product, merchandising, or operations review.

06

What should the promise ledger contain?

The ledger should identify the promise, show how it was verified, and make one person accountable for closing any gap.

Use these fields: Promise ID; ad source; exact or implied promise; category; PDP evidence; underlying substantiation; conditions or disclosures; status; severity; correction route; owner; due date; reviewer; sign-off; and snapshot timestamp. A stable Promise ID lets teams discuss a specific discrepancy without relying on ambiguous comments such as “fix the offer copy.”

Example: the source is video 00:04–00:07, where a product appears with a travel case. The interpretation is “The case is included in the advertised price.” The PDP gallery shows the case, but the “What’s included” section lists only the product. Mark the row Contradiction and Blocker. The correction is to remove the case from the ad or make it part of the bundle while updating the SKU, price, PDP contents, and checkout state.

Assign both an accountable owner and an independent reviewer. Creative may revise the asset, but merchandising must confirm bundle contents and operations may need to verify fulfillment. Define these handoffs in the broader creative workflow for ecommerce. Record offer stage, code, dates, and conditions in the brief; ATIYO users can follow the process for adding a promo funnel stage and inspiration to a brief.

07

What belongs in the dated launch snapshot?

The snapshot should preserve what the reviewer actually saw and the selling conditions under which approval was granted.

Save the served or previewed ad combinations, resolved URL, mobile and desktop PDP views, selected variant, inventory state, price, currency, promotion, shipping estimate, relevant checkout total, geography, and login or cookie state. Include the ledger version, review timestamp, approvers, and links to substantiation records.

The snapshot is not permanent approval. Repeat the audit after changes to creative, PDP content, feeds, prices, offers, inventory, shipping logic, or landing URLs. Google describes landing-page experience in terms that include relevance, usefulness, navigability, and whether the page meets the expectations created by the ad in its landing-page guidance.

Shipping deserves an operations check rather than a copy-only review. For covered US orders, the FTC Mail, Internet, or Telephone Order Merchandise Rule requires a reasonable basis for the advertised shipment timeframe and generally applies a 30-day shipment expectation when no timeframe is stated.

08

What is the final prelaunch gate?

Launch only when every blocker is closed, independently rechecked, and represented in the dated snapshot.

The final reviewer should use a clean session rather than a logged-in merchandising view. Test the primary mobile and desktop experiences, the intended geography and currency, the default variant, price, promotion, stock, shipping, returns, and relevant checkout state. Review responsive combinations again and confirm that necessary disclosures remain understandable in context.

ATIYO can preserve the approved brief, creative versions, brand context, assets, iterations, and reusable learnings around this process. It does not inspect ad accounts, buy media, calculate ROAS, or automatically know campaign performance. Media performance remains in the ad platform, while ATIYO preserves creative context and learnings.

1. Open the resolved destination in a clean session.
2. Verify product, default variant, price, offer, stock, shipping, returns, and checkout.
3. Review responsive assets and combinations for unintended promises.
4. Confirm all Blocker rows are closed and independently verified.
5. Save the dated snapshot and reopen the audit after any material change.