Dynamic remarketing catalog ads: Meta + Google setup

Dynamic remarketing is the campaign that re-shows a past visitor the exact products they viewed, added to cart, or abandoned, assembled per impression from your product feed rather than from a single static creative. Someone looked at three kettles and left; the next day they see those three kettles, with the price they saw, linking back to the pages they were on. The feed supplies the image, the title, the price, and the link. The platform decides which product to show which lapsed user, driven by a behavioural signal it collected on your site. In other words, the feed is the creative and the platform is the targeting engine.

That split is the thing to hold onto, because it determines who fixes what when it breaks. There is a feed lane (the product images, the fields, the IDs, whether each item is approved) and a campaign lane (the pixel or tag, the events, the audiences, the campaign itself). The two lanes meet at exactly one point: the product ID. This article walks the Meta setup and the Google setup side by side, shows why the feed image matters more in remarketing than anywhere else, and lists the handful of feed mistakes that silently stop dynamic remarketing from serving.

Meta vs Google: what each one needs first

Before any product can re-appear in front of a lapsed visitor, both platforms demand the same two ingredients in different wrappers: a catalog or feed they can read, and a behavioural signal they can match against it. Where they diverge is in the plumbing, and the divergences are where setups go wrong. The table below is the load-bearing comparison; everything after it is detail.

Two rows carry most of the failures. The ID-match invariant is the same idea on both platforms, written differently: the ID your tracking fires has to equal the ID in your feed, exactly, or nothing matches. And the enable-the-feature step is the one people skip, because installing the pixel or tag feels like the finish line when it is only half the work. For the broader platform setup behind each column, see the Meta catalog ads and Google Shopping feed use-case pages.

Meta setup: connect the pixel to the catalog

On Meta, dynamic remarketing rides the same format as cold catalog ads, called Advantage+ catalog ads today and Dynamic Product Ads (DPA) before that. DPA was always the retargeting mode: it is built for people who already know you, who visited a product page, added to cart, or purchased. The product-selection mechanics (Meta picks which product to show which person, and the image is a cached URL, not a generated creative) are covered in depth in how Meta Advantage+ catalog ads work. The retargeting-specific pieces on top of that are these.

1. Connect the pixel to the catalog, not just to the site

This is the step that catches people. Installing the Meta Pixel on your website is necessary but not sufficient. In Commerce Manager the pixel (or app SDK) has to be connected to the catalog itselfas its event source, so Advantage+ can match a user's behaviour to specific catalog items. Without that connection the catalog has no behavioural signal to retarget against, and the campaign has nothing to assemble. (Meta's own help text on this renders behind JavaScript, so the wording here is restated from practitioner and vendor guides rather than quoted verbatim, but the requirement is consistent everywhere.)

2. Build the retargeting audience from intent tiers

Catalog and website Custom Audiences are what scope a retargeting campaign. The standard intent tiers, strongest signal first:

• AddToCart without Purchase (cart abandoners): the hottest audience, people one step from buying.
• ViewContent without AddToCart (product viewers): warm, they looked but did not commit.
• All site visitors: the broad backstop.

Each tier maps to product-set logic so Meta re-shows the specific products from those events. You can apply these as explicit retargeting audiences, or let Advantage+ auto-mix prospecting and retargeting and find the abandoners inside a broader pool.

3. Scope eligibility with product sets, optimise low in the funnel

Product sets inside the catalog decide which products are eligible to serve. A common practice is a generously sized product set so Meta has room to pick the best item among them, rather than a hand-cut set of a few SKUs. And on the campaign side (the advertiser's setting, not the feed's), optimising on a lower-funnel event such as Purchase often outperforms optimising on ViewContent or AddToCart for a retargeting audience that is already warm.

Google setup: it is not a campaign type anymore

The biggest misconception about Google dynamic remarketing in 2026 is that you create a "dynamic remarketing campaign." You do not. It is no longer a standalone campaign type. It is a capability you switch on by linking a feed and tagging the site, and it then runs through Display, Performance Max, or App campaigns. A Performance Max campaign linked to a Merchant Center feed, on a site that is tagged for dynamic remarketing, activates dynamic remarketing automatically as part of its mix. Treat Performance Max as where Google now puts retail remarketing, not as a separate thing to configure from scratch.

The setup sequence for the retail vertical:

• Submit and approve a Merchant Center feed with at least id, title, image_link, price, availability, and link.
• Enable the Dynamic Remarketing add-on in Merchant Center: Settings, Add-ons, Dynamic Remarketing, Add. This is the step people forget.
• Link Merchant Center to Google Ads, so the system can access your product data.
• Install the dynamic remarketing tag (Google tag / gtag, usually via Tag Manager) on landing, product, cart, and purchase pages, passing the dynamic remarketing parameters.
• Choose delivery: Display, Performance Max, or App. A tagged site plus a linked feed auto-activates dynamic remarketing inside the campaign.

The tag parameters, and the ID rule that governs them

There are two naming conventions for the tag, and both are real and coexist in 2026. The legacy AdWords-tag names, still emitted by the Tag Manager template and widely seen in the wild, are ecomm_prodid (product ID), ecomm_pagetype (page type), and ecomm_totalvalue (value). The modern gtag form uses an items array instead, for example items: [{ id, google_business_vertical: 'retail' }] alongside a value. Use the modern gtag form as the primary; recognise the ecomm_ form as the legacy one you will still encounter.

Whichever you use, the rule that governs everything is the same as Meta's: the product ID the tag fires must match the Merchant Center feed id 1:1. If they do not match, Google Ads throws errors and the campaign serves the wrong product or no product at all. (The ecomm_pagetype enum (home, searchresults, category, product, cart, purchase, other) is widely restated convention rather than a verbatim Google list, so treat it as a practitioner standard, not a quoted spec.)

The feed is the creative, and it matters more here

On both platforms the visible ad is assembled from feed fields: the product image_link, the title, the price, and the sale price for the strikethrough. On Google the feed serves as the creative foundation that populates the ads. On Meta, image_link is fetched and cached by URL with no "dynamic image" concept whatsoever. There is no special "remarketing creative" integration on either side; it is the same feed mechanism that powers cold catalog ads. So a pre-rendered, branded image URL in the feed renders in the remarketing ad exactly as it would in a prospecting ad. Emberfeed rewrites g:image_link in the served feed to point at its on-demand render endpoint with a cache-busting query, and the platform fetches and caches that render like any CDN image.

Here is why the image matters morein remarketing than anywhere else. A returning visitor has already seen the bare product photo on your own site. Re-showing them the identical raw photo earns nothing; it is wallpaper they have already scrolled past. A branded, price-badged, "still in your cart" or "back in stock" treatment is what re-earns the click from someone who is, by definition, further down the funnel than a stranger. And because the badge is bound to feed data, it stays honest: it disappears when the sale ends or stock returns, unlike a hand-made Photoshop chip that goes stale and starts lying the day the promotion closes. The mechanics of building those templates live in AI-designed catalog images.

The feed mistakes that silently break it

Dynamic remarketing fails quietly. The audience exists, the campaign is live, the budget is set, and yet the right product never appears. Almost every silent failure traces back to one of the rows below. They are ordered by how often they actually bite.

Several of those rows are general Merchant Center disapprovals that hit remarketing as collateral damage rather than remarketing-specific faults. The promotional-overlay rule, the mismatched-price and mismatched-availability rejections, the crawlability failures, each one is dissected, with the bulk fix, in common Google Merchant Center disapprovals. The point worth repeating here is that an item disapproved for any reason is invisible to dynamic remarketing, even when the audience and the campaign are flawless.

Feed lane vs campaign lane: who fixes what

It is worth being blunt about the division of labour, because it tells you where to look when something is wrong, and it tells you honestly what a feed tool can and cannot do for you.

The two lanes meet at exactly one place: the product ID. Emberfeed preserves the source feed's id and keeps it stable and consistent, but it cannot reach into your website's pixel or tag to change what ID thatfires. So the honest line is: Emberfeed keeps your feed's IDs intact; matching the pixel or tag to them is the platform-setup step on your side. A feed tool cannot fix a missing pixel, a tag firing the variant ID, or an absent audience. It can only make the feed side correct and the IDs in the feed dependable.

Building the feed side with Emberfeed

With the lanes drawn, Emberfeed's job is narrow and clear: it supplies and enhances the catalog images and fields that the remarketing ad displays. It does not run the campaign, install the pixel or tag, set up audiences, or generate a feed from nothing. It is not self-hosted, and it needs your existing source feed to work. Inside that scope the workflow is short:

• Import your existing product feed URL. Emberfeed parses the XML (standard RSS with the g: namespace) and stores each product, preserving its id.
• Design one template for the remarketing creative: HTML and CSS with an AI-suggested starting layout, or a visual layer editor. Bind price, sale price, and badge conditions to feed fields so they stay true to stock and promotions.
• Take the served feed URL (/api/serve/<feedId>). It is the same XML structure as your source, but every image_link is rewritten to the render endpoint with a cache-buster attached, and the feed is validated against the platform you target.
• Paste it into Commerce Manager or Merchant Center as the catalog data source. The platform fetches normal-looking image URLs, caches each render, and the campaign assembles ads from them. No "dynamic image" setting exists or is needed.
• Need different graphics for Google vs Meta? Duplicate the feed, point the copy at the same source, give the Google copy a clean overlay-free template, and keep the price-badged template on Meta. Two served feeds, one source.

Pricing is roughly 25 € per feed, and the first three months are free on one feed with up to 1,000 products, because testing a remarketing creative against a baseline takes a few weeks to read honestly.