Facebook and Instagram ads for e-commerce: a practical starting guide

Last reviewed June 2026, verified against Meta's current Conversions API deduplication and Advantage campaign budget naming.

Most "how to run Facebook ads" guides are written for a generic store on a generic platform, and they stop at the part where you click "Publish" inside Meta Ads Manager. The hard part for a PrestaShop merchant happens before that, getting your store to send Meta the right signals, getting your product catalogue into Meta in a format it trusts, and making sure a purchase that happens in your checkout actually shows up against the right ad. Get that plumbing wrong and even a perfectly targeted campaign reports garbage numbers, optimises toward the wrong people, and burns budget you can't get back.

This guide is the practical starting point for paid Facebook and Instagram ads specifically on PrestaShop: the data foundation the platform needs from your store, how to structure a first campaign so it can actually learn, and the metrics that tell you to scale or stop. It assumes you want to run ads. If you're still deciding whether paid social is even the right channel for your products, start with which social platforms actually drive sales.

The data foundation: three things your store must send Meta

Before a single euro is spent, three connections need to exist between your PrestaShop store and Meta. They're the difference between an algorithm that finds buyers and one that guesses.

The pixel deserves its own treatment, what events it fires, how to verify them in Events Manager, and why it earns its keep even on a store that never runs a paid ad. We cover that in full in Facebook Pixel for PrestaShop; here we only need the campaign-relevant part: your pixel must be firing the standard e-commerce events (ViewContent, AddToCart, InitiateCheckout, Purchase) before you spend money, because those are the exact signals a Sales campaign optimises against. If you run a yoga-mat store and your pixel only reports PageView, Meta has no idea which of your visitors are buyers, and a "purchase" campaign is really just a "traffic" campaign with a confident name.

Give the pixel time to accumulate data, ideally a couple of weeks of normal organic and direct traffic before launch, so Meta has a baseline of what a real buyer on your store looks like. So what? A warmed-up pixel means your first paid campaign starts from signal instead of from zero, which is the difference between learning in days and learning in weeks of wasted spend.

Why server-side (Conversions API) is no longer optional

Since Apple's tracking changes and the steady rise of ad blockers, a meaningful share of browser pixel events never reach Meta, purchases included. When Meta can't see a purchase, two bad things happen: it under-counts your ROAS (so a profitable campaign looks like a loser and you kill it), and it can't learn from that conversion (so it optimises worse). The fix is the Conversions API: your PrestaShop server sends the purchase event directly to Meta, server-to-server, deduplicated against the browser event by a shared event ID. The result is more complete data without double-counting. On PrestaShop this is exactly the kind of connection a dedicated pixel-and-CAPI module handles from the back office rather than a developer building a server integration by hand, and it's worth confirming your tracking setup does CAPI, not pixel alone, before you scale spend. Our Facebook Pixel for PrestaShop module fires the browser events and the server-side Conversions API together, sharing one event ID so Meta dedupes them automatically. Which is the part most hand-rolled setups get wrong.

The thing to verify in Events Manager is the deduplication itself: a browser Purchase and a server Purchase for the same order must carry the same event_id, or Meta counts the sale twice and your reported ROAS inflates. A correct browser-side event looks like this:

<!-- Browser pixel: Purchase, with a shared event_id for CAPI dedup -->
<script>
  // orderId comes from your PrestaShop order confirmation page
  var eventId = 'order_' + orderId;
  fbq('track', 'Purchase', {
    value: 49.90,
    currency: 'EUR',
    content_ids: ['SKU-123', 'SKU-456'],
    content_type: 'product'
  }, { eventID: eventId });
</script>

The server then POSTs the same Purchase with the identical event_id to Meta's Conversions API. Meta matches the two and keeps one. If you only ever see browser events in Events Manager and never a "server" badge next to your purchases, CAPI isn't actually wired, fix that before you scale.

Get your catalogue into Meta the same way you'd feed Google

Dynamic Product Ads, the format that shows each visitor the exact products they viewed or abandoned. Need a product catalogue inside Meta's Commerce Manager. The clean way to supply it on PrestaShop is a structured product feed, the same discipline you already use (or should use) for Google Shopping: a scheduled XML/CSV export of your catalogue with stable IDs, prices, availability, and image URLs that Meta re-reads automatically as your stock and prices change.

This matters because catalogue quality, not ad creative, is what quietly caps Dynamic Ad performance. If your feed ships products that are out of stock, priced wrong, or missing the right image, Meta will dutifully advertise them, and you pay for clicks on a "buy now" ad that lands on a sold-out product. The PrestaShop-specific advantage here: a feed module that already maps your catalogue, combinations, and stock to a marketplace standard can usually output a Meta-compatible catalogue feed from the same data, so your Shopping feed and your Facebook catalogue stay in sync from one source of truth. If you're already running our Smart Google Merchant Feed Manager for Google, the same disciplined product data is what feeds clean Dynamic Ads on Meta, one well-maintained feed, two paid channels.

The catalogue also powers a Facebook Shop, which is a separate (free) surface from paid ads, selling natively on the platform rather than buying placements. If that's on your roadmap, it has its own setup considerations covered in Facebook Shop and PrestaShop.

Campaign structure: objective, audience, creative

Meta Ads has three nested levels, and the most common beginner waste comes from confusing what belongs at which level.

Pick the objective your pixel can actually support

For e-commerce the honest default is Sales (Conversions), which optimises toward people likely to purchase, but it needs purchase data to work. A brand-new pixel with zero tracked purchases can't power a Sales campaign well, because the algorithm has nothing to find more of.

• Sales / Conversions, your destination. Optimises for purchases. Move here once your pixel has roughly 25–50 tracked purchases (treat that as a working threshold, not a magic number. The point is "enough signal to learn from").
• Traffic, use deliberately for low-risk audience testing, not as a default pixel-warming step. It optimises for cheap clicks rather than buyers, so prefer Sales/purchase optimisation once your budget and event volume allow, even with limited data.
• Engagement, useful to build likes, comments and shares on an ad before you run it as a conversion ad, so it arrives with social proof already attached.

Audiences: cold to find new buyers, warm to convert them

Cold (prospecting) means people who've never heard of you. Three approaches that work on a PrestaShop store:

• Interest targeting, Meta's demographics, interests and behaviours. Sell yoga mats, target yoga / fitness / wellness. Keep the audience large enough (aim well above half a million people) so the algorithm has room to optimise.
• Lookalike audiences. Once your pixel has purchases or you've uploaded a customer email list, Meta finds people who resemble your actual buyers. A 1% lookalike of past purchasers is usually the strongest cold audience you can build.
• Broad targeting, with a mature pixel and Conversions API feeding clean purchase data, minimal targeting restrictions often outperform tight ones, because you're trusting the algorithm rather than your guesses about who your customer is.

Warm (retargeting) means people who already viewed a product, abandoned a cart, or bought before. Built automatically from the pixel and catalogue you set up above. Retargeting is its own discipline with its own audience windows, frequency caps and creative logic, so rather than cram a thin version here, the full playbook is in retargeting explained. For a PrestaShop store the key starting point is simply that a correctly firing pixel makes cart-abandoner and product-viewer audiences exist at all.

Creative: the lever that overrides everything else

Targeting decides who sees the ad; creative decides whether they care. A few formats and the e-commerce-specific rules that matter:

• Image, product-in-use (lifestyle) beats product-on-white; one product, one message; minimal on-image text; square (1:1) or vertical (4:5) to claim more feed real estate.
• Video, earn the first 3 seconds with the product or hook, never a logo; design for sound-off with captions, since most feed video is watched muted; vertical (9:16) for Stories and Reels.
• Carousel, multiple products or multiple angles, each card deep-linking to its own product page; or a problem → solution → result narrative across cards.
• Dynamic Product Ads, the highest-leverage e-commerce format, powered by the catalogue feed above. Meta automatically assembles an ad showing each person the products they viewed or items like them. This is where a clean PrestaShop product feed pays for itself.

Budget, bidding and the learning phase

The single most expensive beginner habit is impatience. Judging or editing a campaign before it has the data to be judged. Every meaningful edit resets Meta's learning phase, the period where the algorithm gathers conversions before it can optimise reliably (it needs on the order of 50 conversions per ad set per week to exit it). Constant tweaking keeps a campaign permanently in its worst-performing state.

• Start small. Roughly €10–20/day for testing is enough to gather signal without risking real money while you learn what works.
• Use Advantage campaign budget (formerly Campaign Budget Optimisation/CBO). Let Meta move budget toward the ad sets that perform, rather than splitting it evenly by hand.
• Don't over-segment. Each ad set needs enough conversions to exit the learning phase; ten under-fed ad sets all learn badly. Fewer, better-fed ad sets win.
• Scale in steps, raise budget ~20–30% at a time. Doubling overnight throws the ad set back into learning and destabilises performance.
• Refresh before fatigue. Even strong creative tires after a few weeks; have the next set ready before frequency climbs.

The metrics that decide scale or stop

Most beginners watch likes and reach, vanity. The numbers that actually govern whether you make money:

The crucial caveat for PrestaShop merchants: these numbers are only as honest as the tracking under them. If your pixel under-reports purchases because browser events are being dropped, your ROAS will look worse than reality and you'll kill profitable campaigns. This is exactly why the Conversions API step earlier isn't optional housekeeping. It's what makes the numbers in this table trustworthy enough to bet budget on.

A realistic first 30 days

• Confirm your pixel fires ViewContent, AddToCart, InitiateCheckout and Purchase, and that the Conversions API is sending purchases server-side, verify both in Meta's Events Manager.
• Connect your product catalogue feed to Commerce Manager so Dynamic Product Ads are available.
• Let the pixel collect a week or two of organic/direct traffic so it has a buyer baseline.
• Launch a campaign appropriate to your data: prefer Sales/Conversions where budget and event volume allow, and reserve Traffic for deliberate low-risk audience testing rather than as a default warm-up.
• Run three or four genuinely different creatives against one well-sized cold audience and let them run a week before judging.
• Turn on retargeting for cart-abandoners and product-viewers. The warm audiences your pixel and catalogue now make possible.
• Read the table above weekly, scale winners in 20–30% steps, cut the losers, and refresh creative before frequency climbs.

Paid social rewards patience and clean data far more than clever targeting tricks. On PrestaShop specifically, "getting started" is less about Ads Manager and more about the connections from your store, a pixel that fires the right events, a server-side feed that recovers the purchases the browser drops, and a product catalogue Meta can trust. Get those right and your first campaign starts from signal instead of guesswork. Once paid social is pulling its weight, it works best alongside the organic surfaces it amplifies, see how the paid and free sides fit together in integrating Instagram and Facebook feeds into PrestaShop.

Tag your ad links so GA4 can tell you what Meta won't

Meta's own reporting tells you how Meta did. To see how a Meta visitor behaved on your store next to every other channel, and to cross-check Meta's self-reported ROAS against your real orders, tag the destination URL on each ad with UTM parameters. Set the campaign-level URL parameters in Ads Manager once and they ride along on every click:

utm_source=facebook        # or instagram
utm_medium=paid_social
utm_campaign={{campaign.name}}
utm_content={{ad.name}}
utm_term={{adset.name}}

Those {{...}} tokens are Meta's dynamic URL parameters, Meta fills them in per click, so one setting covers your whole account and GA4 groups the traffic by real campaign and creative names instead of opaque IDs. The point isn't to replace Meta's pixel numbers; it's to have an independent, last-click record in GA4 so that when Meta claims a 5× ROAS and your order list disagrees, you can see where the gap is.

Frequently asked questions

Do I still need the browser pixel if I've set up the Conversions API?

Yes, keep both. The Conversions API doesn't replace the pixel; it backs it up. The browser pixel captures the rich on-site behaviour (which product was viewed, scroll-through to checkout) and the server feed recovers the events the browser drops. They're meant to run together and deduplicate against a shared event ID. Running CAPI alone loses signal; running the pixel alone is what Apple's tracking changes broke in the first place.

How much should I spend before I can tell if a campaign works?

Budget enough to let one ad set reach roughly 50 conversions a week. That's the threshold Meta needs to exit the learning phase and optimise reliably. At a €15 cost-per-purchase that's about €750/week into a single ad set, not split across ten. If your margins can't fund that to a Sales objective yet, test cheaper signals (AddToCart, InitiateCheckout) as the optimisation event until purchase volume grows. Judging a campaign that never left learning is judging noise.

Why does Meta report more sales than my PrestaShop order list?

Almost always one of two things: the attribution window (Meta credits a sale to an ad someone clicked up to 7 days earlier, even if they came back via a different channel to buy), or double-counted purchases because your browser and server events aren't deduplicated. Check the event_id match first, if browser and server Purchase events don't share an ID, Meta counts both. After that, treat Meta's number as "ad-influenced" and your order list as "actually collected," and reconcile with your GA4 UTM data.

My ROAS dropped right after I raised the budget. Did I break something?

You likely reset the learning phase. Any significant edit, and a budget jump over ~20–30% counts, throws the ad set back into learning, where it performs at its worst while it re-gathers conversions. Raise budget in steps of 20–30% and wait for performance to restabilise (a few days to a week) before the next step. Don't react to the dip with another edit; that just restarts the clock again.

Can I run Dynamic Product Ads without a developer?

Yes, if your catalogue feed is clean. Dynamic Product Ads need a product catalogue in Commerce Manager and a pixel firing ViewContent and AddToCart with matching content_ids, both of which a feed module and a pixel module set up from the PrestaShop back office. The developer-level work (writing a feed by hand, building the CAPI integration) is exactly what those modules remove. What you can't skip is feed hygiene: out-of-stock or mispriced items will be advertised regardless.

Keep reading

• Facebook Pixel for PrestaShop: why you need it even if you don't run ads, the events, verification, and why the pixel earns its keep before you spend a euro.
• Retargeting explained, the warm-audience half of the funnel your pixel and catalogue make possible.
• Which social platforms actually drive sales. The channel-selection decision to make before you commit ad budget.