Magento 2 Facebook Product Feed

View Demo

Your site is not the only place to advertise and sell your products. Facebook offers humongous marketing opportunities. Taking advantage of them is a smart choice for any business.

Magento 2 Facebook Feed lets you easily generate product feeds for Facebook Dynamic Ads or Facebook Store.

  • Generate product feeds for Facebook Dynamic Ads or Facebook Store
  • Export as many feeds and products as you need
  • Use templates, duplicate for similar channels, or build from scratch
  • Validate feeds against your custom rules before export
  • Filter variables with conditions
  • Schedule feed generation and delivery

ℹ️ Important: This sub-module is included in the Advanced Product Feeds extension.

Buying this item gives you access to all feeds including Facebook, Instagram, Google Shopping, and others in one powerful package.

Hyvä
Magento Cloud
Mage-OS
Compatible with:
Community:
2.3.* - 2.4.9
Enterprise:
2.3.* - 2.4.9


Business Value

  • Opportunity: Facebook has over 3,59 billion active users worldwide with 33 minutes of average time a user spends on this social media platform. It is a perfect Find a new audiAds on Facebook have one of the most advanced targeting options on the market, too. You can take advantage of both Facebook’s traffic and its tools by either marketing your products with its Dynamic Ads or creating your own Facebook Store.
  • Problem: You have to regularly export your products to Facebook in order to advertise and sell products there. This means that you have to generate a product feed and automate it.
  • Solution: Magento 2 Facebook Feed is a comprehensive solution for product feed generation and automation. It lets you generate product feeds for either Facebook Dynamic Ads or Facebook Store, customize them, automate their generation and delivery, use analytics to track their performance, and so much more.

How it Works

This feature lets you generate a product feed for Facebook Dynamic Ads or Facebook Store. Get a Facebook Shop integration Magento 2 feed which you can then import to the social network. We have templates that work out-of-the-box, but you can extensively customize them or even create your own ones. Feed generation and delivery can be automated, and there is also an extensive analytics suite.

Main Advantages

Export as Many Feeds and Products as You Need

Concentrate on your business, not your quota. You can update with as many products as you need to as often as you need to.

Facebook’s unlimited product import feature ensures that businesses, whether they are recently launched startups or established endeavors, can keep their product catalogs in sync with market dynamics. The result of using the Facebook product feed Magento 2 is a digital storefront that can promptly respond to changing consumer preferences, emerging trends, or seasonal shifts.

Use Ready Templates or Create Your Own Feeds

This feature includes ready-to-go Facebook Dynamic Ads and Facebook Store feed templates. Just set up the extension, choose the corresponding marketplace, shopping engine or advertisement network, and generate the feed to start marketing.

If you need more control over the feed, you can further customize it with our advanced set of patterns and variables. For example, instead of displaying the regular price, it may be required to display the Final Price with Tax or a Special Price. You can duplicate a template to reuse its configuration for similar channels.

Our Magento 2 Facebook shop extension offers full freedom when configuring the product feed. Create an individual template tailored to any sales channel, or generate a custom feed without a template when your channel requires a unique structure.

Filter Variables with Conditions

Consider a scenario where an online store offers a vast array of products. Each its product category has specific attributes, and tailoring the shopping experience for customers becomes imperative.

Our Magento 2 Facebook shop integration extension offers robust filtering options. Businesses can effortlessly filter out specific products based on a multitude of conditions.

Whether it's about showcasing a dedicated product set to a specific demographic during a particular season, or a response to market trends - this feature enables businesses to curate their offerings with surgical precision.

Validate Feeds Before Export

Make sure your file meets Facebook’s requirements before you upload it. The validator works with any feed and helps you catch issues early, so your catalog passes review faster.

Set up checks in Content Settings > Validation Rule, generate the feed, and run validation. If a rule is present, the check can run automatically, and you can also start it manually at any time. The result is a clear report with line numbers and plain-language messages.

The validator looks for common problems such as title length, missing required fields, character encoding, price and currency formats, and dimensions, along with any custom constraints you include in the rule. Open the product or attribute, correct the data, regenerate the feed, and validate again to publish accurate information on the first try.

Program Feed Generation and Delivery

Do you update your products regularly? Manually updating product feeds can be a time-consuming task, prone to errors and inconsistencies.

Our Magento Facebook plugin simplifies the task by offering a feed generation schedule based on Cron system utility.

Furthermore, our module continues feed automation with an automated feed delivery support. Easily configure to deliver the product feed to Facebook via FTP or SFTP, ensuring the secure and efficient transmission of product catalog data.

Magento product feed Facebook reports

Get additional view on the Facebook feed Magento 2 success. By tracking the number of clicks and orders made after customers are redirected from the marketplace, businesses gain insights into the effectiveness of the product feed.

Our extension provides comprehensive reports that break down data by Feed, SKU, Day, Week, Month, and Year.

No hidden fees
Lifetime access to source code
Access to free support and updates for 1 year
Updates and support prolongation - $108

Pay today $179 for the first year.

Then $108 for updates and support services per year.

Cancel anytime.

30 days money back guarantee
See it in action!
Pick a quick tutorial to learn about various aspects of this extension
Customer Reviews 0
Earn points for your review about this extension modules. $1 = 10 points
Write Your Own Review

check-circle You submitted your review for moderation.

Manual & Support
Need more help?

Save time by starting your support request online and we'll connect you to an expert.

Frequently asked questions
chevron-down chevron-right

Why do I need a Magento Facebook shop integration?

Facebook allows businesses to dynamically showcase their products or services to a highly targeted audience, enhancing visibility and driving sales.

The Magento Facebook product feed essentially acts as a bridge between an online store's inventory and Facebook's advertising platform. By implementing Magento 2 Facebook store integration using this feed, businesses can seamlessly display their products on Facebook, reaching potential customers with tailored advertisements.

chevron-down chevron-right

Does the Magento 2 Facebook feed require manual update?

What makes our Magento 2 Facebook product feed extension exceptionally powerful is its ability to automatically update the feed. This means that any changes made to the inventory, such as new products or updated prices, are reflected in the ads, ensuring that customers always see the latest offerings.

chevron-down chevron-right

Does the Magento Facebook extension provides a product feed efficacy report?

Our Magento Facebook store integration tool offers tracking capabilities for the Magento Facebook feed via special arguments, which are appended to the product URLs.

The feed efficacy report includes such columns as Number of Clicks, indicating how many times customers redirected from the marketplace to your site.

Number of Orders quantifies the conversions that occurred after customers were redirected. Knowing this figure not only gauges the effectiveness of your marketing but also helps in inventory planning.

Revenue signifies the total earnings from the orders placed after marketplace redirection. Understanding your revenue trends can aid in strategic decision-making.

Revenue per Click is a metric that calculates the average revenue amassed for each individual click. This metric is a testament to the quality of your incoming traffic. A high revenue per click indicates that the visitors are not just browsing but making substantial purchases. This insight is invaluable as it enables you to focus your marketing efforts on channels that bring in high-value customers.

chevron-down chevron-right

Can this Magento 2 Facebook business extension generate a feed for a different service?

You absolutely can! In addition to Magento Facebook integration, our module offers **more than 50** templates for popular shopping services, including Amazon, Google Shopping, and eBay.

Changelog
Version 1.15.12Sep 23, 2026
JSON is now a feed type. Pick JSON in the Type selector, next to CSV, TXT and XML, to publish a feed whose deliverable is the JSON file itself, with no XML copy alongside it. You still write the template as XML markup. It is compiled once into a template that prints JSON directly, so memory stays flat however large the catalog is. Attributes on the elements control the output: xsi:type sets a value's JSON type (number, boolean, …), xsi:nil writes null, xsi:list makes an array, xsi:name sets the key, xsi:omitEmpty drops empty values, and xsi:record="true" marks the element that repeats once per product. Numbers keep exactly the digits your template produced, so a price of 34.00 is not cut to 34, and a value with broken characters is cleaned so the file still parses. If the template has no record element, has more than one, has more or fewer than one product loop, or has a key with an apostrophe, you get a plain message saying what to fix. ([#796]())
Choose how a JSON feed is framed: one document or one object per line. A new Framing option on the feed and template forms (shown for the JSON type only) switches between a single JSON document and JSON Lines, one record per line, which data pipelines read line by line. The file extension follows your choice: .json for one document, .jsonl for one object per line. Templates keep this setting when exported and imported. ([#796]())
Values that don't fit their declared type are reported, not guessed. If a value in a JSON feed doesn't match the type declared for it, such as a price that isn't a number, it is written as text instead of a made-up 0. The feed preview lists each one (key, declared type and value), and the feed validation results name them too. Validation reads the feed using the framing set on the feed, so a one-record document and a one-line JSON Lines file are both checked correctly. The preview lays out a one-document JSON feed in readable, highlighted form without changing any value. ([#796]())
The Generate JSON checkbox on XML feeds now says it is the legacy way to get JSON and points to the new JSON type. It still works and produces the same output as before.
⚠️ New column json_framing (varchar(16), default document) in the mst_feed_feed and mst_feed_template tables. Run bin/magento setup:upgrade after updating.
Only admins with the Import/Export data permission can import or export feed templates. The actions that run a template import or export did not check the Import/Export data role permission (Mirasvit_Feed::feed_import), which the Import/Export page itself already checks. So any admin user who could log in could reach them directly, whatever their role. They now check it, and admins without it are refused.
Version 1.15.11Sep 16, 2026
Feed cron no longer piles up idle PHP processes until the server runs out of memory. The feed cron group runs each due job in its own PHP process, and nothing stopped a second one from starting while the first was still working: an export that ran longer than its schedule interval was joined by a fresh process at every interval, and the one-minute queue job re-read the pending queue and started exporting the same items again alongside itself. Each of those processes costs 300–400 MB just to boot, so on a store with a long export they accumulated faster than they finished and the box eventually ran out of memory — the symptom was several feed processes sitting at 0% CPU and ~330 MB each. Both the scheduled export job and the generation-queue job now check whether a run is already in progress and simply do nothing until it finishes, and the marker is released even if a run crashes, so the next scheduled tick always gets its turn.
A feed that is already being exported now says so straight away instead of hanging, and a failed export no longer blocks the feed afterwards. When an export was already running for a feed, a second attempt waited on it indefinitely rather than reporting the feed as busy: bin/magento mirasvit:feed:export --id=N printed nothing at all instead of "already locked by another process", and a fully booted Magento process sat idle for as long as the other export took. On top of that, an export that ended in an error left the feed marked as in progress, so the next queued generation of that feed waited on a lock that would never be released and the cron run stalled. A busy feed is now reported within a second, and the marker is always cleared when an export ends, successfully or not — so the run moves on to the next feed. Stores whose media directory sits on a filesystem without file locking (NFS, AWS EFS) keep generating feeds as before.
Version 1.15.10Sep 15, 2026
Admin pages belonging to other extensions no longer fail with "The element with the '…' ID wasn't found". To keep its own admin screens from tripping a PHP deprecation notice, the extension quietly gave a name to any admin panel that had been left unnamed — including panels that belong to other extensions. When such an extension later named that panel itself, Magento could not find the name we had invented and the page died with that error instead of loading; Firebear Improved Import & Export's import job edit screen was one of them. Naming is now limited to this extension's own panels, so everyone else's pages are left alone and load normally, while our screens stay free of the deprecation notice.
Version 1.15.9Sep 14, 2026
A sale that is live on the storefront is now priced as a sale in the feed. The feed decided for itself whether a special price was still inside its from/to window, and it asked the server's UTC clock — while Magento judges that same window on the wall clock of the admin timezone, deliberately, so one special price means the same thing in every store view. The two disagree by exactly that timezone's offset, so on a store ahead of the server the storefront was already charging the sale price while the feed still published the full one, at every hour of the day. That is the "mismatched value" disapproval in Google Merchant Center and its equivalents elsewhere. The window is now Magento's to judge, so the feed and the storefront always quote the same price. An open-ended special (no end date) still applies, a window that has closed or has not opened still exports no sale price at all — not a 0, which would advertise the product as free.
A fractional stock quantity is no longer rounded down. Quantity was exported as a whole number, so a product stocked by weight or volume — 0.5 kg of something, 2.5 m of cable — shipped a quantity of 0 and read as out of stock in every channel that trusts that column. Fractional quantities, and the summed quantity of a configurable's or grouped product's children, now export as they are actually stocked. A whole-number quantity is unaffected: 5 still exports as 5.
{% if a and b and c %} now checks every condition in a feed template. A template condition joining three or more comparisons with and / or only ever evaluated the last two — everything before them was silently discarded, so a three-part rule guarding a column emitted the wrong branch with nothing in the log. Conditions are now folded left to right across the whole statement. Two-condition ifs, which is what most templates use, behaved correctly before and are unchanged.
The feed statistics chart no longer drops days with no traffic. A day with no recorded clicks was left out of the sparkline entirely rather than drawn as a zero, so three active days in a fortnight rendered as three adjacent bars and a sporadic feed read as one with steady traffic. Every day in the selected period now contributes a point, a quiet day as a genuine 0, so the shape of the chart matches the period it covers.
Feed generation and AI optimisation survive a media mount that has dropped out. The advisory lock file that keeps the admin, cron and CLI export paths from colliding was created under pub/media/feed/tmp, and the AI optimisation run kept its own lock in the same place. Where media is a remote or network mount (NFS, AWS EFS) that has lost its transport — after an OOM kill, say — opening that file failed before a single product was exported, and every feed on the store stayed broken until the mount came back. Both locks now live in var/mst_feed/tmp, next to the export's scratch and progress files, which already moved there: a transient coordination file has no business on shared storage. Nothing about how you use the extension changes; if a monitoring check watches for a stale .lock, point it at the new directory.
The AI profile template picker is no longer empty on stores that keep media on remote storage (Amazon S3 and compatible). The bundled profile templates ship inside the extension's own directory, but were being read through the remote-storage driver, which answers for a key that has never existed in the bucket with an empty file rather than an error. Every template then parsed as broken and was quietly skipped, so the picker offered 131 entries on an ordinary store and none at all on an S3 one, with no exception anywhere to explain it. They are now read from the local disk they actually live on.
Google category mapping works again on PHP 7.x. An empty search was read as "match nothing" rather than "match everything" on PHP 7, so the taxonomy came back empty with nothing logged: the category-mapping autocomplete in the admin offered no suggestions when opened with an empty box, and validation rejected every real Google category as invalid. Both work as they do on PHP 8 now.
A CSV template saved without a format no longer breaks the feed. A template is allowed to carry just a name and a type, and one saved that way reached generation with no column delimiter at all — a fatal error on PHP 8 and a run-together line on PHP 7. Such a template now renders with no separator rather than failing, and no delimiter is invented on your behalf.
The feed history grid remembers your Columns choice. The Columns dropdown rendered and worked, but the selection — along with filters and page size — was gone on the next load, with no error and nothing in the log. The grid now saves its view the way every other grid in the extension does.
An empty product selection no longer ends in a database error. Previewing a feed whose store view belongs to a website with no products assigned answered with a raw MySQL syntax error instead of an empty preview — the empty list of products was handed to the database as an empty condition. An empty selection is a legitimate answer and is now treated as one: the preview simply comes back empty. In the same vein, a feed left with no filter rule at all now explicitly clears its product set, so detaching the last rule no longer leaves the previous run's products attached to it.
The Order # column in the SKU report resolves again. The column is now backed by a direct link from the report row to the order it was attributed to, so it shows the order number rather than nothing.
Feed columns in the reports no longer go through a temporary table. The relationship between a report row and its feed was declared the wrong way round — the reporting engine believed one report row could have many feeds — so adding a Feed column pushed the data through a temporary table instead of joining it directly. Reports that group or filter by feed are now built with a plain join.
Version 1.15.8Sep 7, 2026
An empty feed now tells you it is empty. A generation that matched no products used to finish with a green Feed file was generated., a blank or negative Products in feed count and a stray Valid 0 — with an empty file and no hint as to why. Such a run now ends with a warning that names the usual causes (the product filter matched nothing, the chosen store view has no products assigned, the catalog indexes are invalid) and links the troubleshooting guide, and the count always reads as a real number, including a genuine 0. ([#757]())
Category filters now select the products they describe. With Enable fast mode filtering on — the default on every feed — four of the Category operators compared the single category id stored per product against the whole comma-separated list you picked, so Category is 5, 7, 12 produced an empty feed and Category is not 5, 7, 12 exported the entire catalog. Does not contain was wrong in a second way: it matched the ids as text, so excluding categories 3 and 4 also quietly excluded 13, 23, 30, 34 and every other id containing those digits. Is, is not, contains and does not contain now all ask the indexed category-membership question — a positive operator means "in one of these categories", a negative one "in none of them" — in both filtering modes, so saved rules match correctly and both modes agree. Is one of / is not one of are unchanged. ([#756]())
A filter that combines conditions with ANY no longer empties the feed in fast mode. Fast mode narrows the catalog with a database query before checking each product, and a condition that has no database equivalent — Quantity, Is Salable, the image fields, a PHP condition and a dozen more — was simply left out of that query. Inside an ANY group that made the query stricter than the rule: measured on a 2,046-product store, Quantity is greater than or equal to 0 OR SKU is NO-SUCH-SKU kept all 2,046 products with fast mode off and exported none with it on, with nothing in the log to explain it. An ANY group is now used to narrow the catalog only when every condition in it can be expressed as a query; otherwise the feed checks the full candidate set — slower on such a rule than before, and correct, where before it was fast and wrong. Rules that are a plain ALL list of ordinary attributes, the common case, keep exactly the speed they had, and stock filters keep selecting the same products as always.
Final Price filtering in fast mode is exact again. 1.15.7 started reading Final Price from Magento's price index to narrow the catalog, and that is not the same number the filter itself computes: on stock sample data 26 of 147 configurable products disagreed, and because the narrowing runs first, a product the rule keeps was never even looked at — Final Price is greater than or equal to 25 silently left out a product priced at 28.00. The index also holds enabled products only, and under a per-website or per-customer-group price index it can be empty altogether, which would have emptied every Final-Price feed. Final Price is now decided by the same per-product calculation the slower mode uses, in both modes, for simple, configurable, bundle and grouped products alike. ([#764]() follow-up)
Filters left with an empty value now match exactly what they match with fast mode off. 1.15.7 gave three of them a fast-mode condition, and two of those did not agree with the slower mode: is not one of with nothing selected kept every product that has a value for the attribute, where the filter in fact matches no product at all — on the sample catalog that was 47 of the 81 products the admin preview offered for a rule that selects nothing — and is one of with nothing selected built no condition, so fast mode let the whole catalog through. Both now select nothing, as they do with fast mode off. Is not with an empty value — the "is not empty" filter — keeps its meaning and no longer drops a product whose value is 0. ([#772]() follow-up)
forloop.first and forloop.last work in feed templates. Both were computed from the product's internal id rather than its position in the loop, so {% if forloop.first %} never once matched and forloop.last fired on whatever product happened to carry the matching id — the documented way to write a feed-level value into a header produced nothing. Both flags, and forloop.notlast, now follow the loop's own position. ([#746]())
A value captured out of the product loop now reaches the header and footer. The documented pattern — {% capture %} around {% for p in context.products %} — came out blank: the end of the product loop stopped the rest of the document for that pass, so the field that reads the captured value was never rendered, and on the next pass the exhausted loop overwrote the value with an empty string. The captured value is now kept and carried between the passes of a chunked export, so a footer rendered only in the final pass still sees it, while a capture inside a {% for %} still recalculates per row. A capture interrupted part-way — by the export's time limit or by Stop — no longer publishes the half-built value it had accumulated, in a header, in an {% if %}/{% else %} branch or inside another capture: the field stays empty for the rest of that export rather than shipping a plausible-looking but truncated value. Very large captured values (over 64 KB) still reach the feed file in the pass that produced them, they are just not carried across passes. An export already in progress keeps running across the update.
The exported product count no longer goes blank on a store view that is not in English. The export runs in the store view's language and the count was looked up by the export step's translated label, so on a Spanish or Romanian store view — 42 of the 45 shipped locales translate the word — the Count column in the Feeds grid, the status bar and the generation panel all showed nothing, and a spurious Valid 0 appeared beside a green success. Verified on a store view in Spanish: a 346-product feed now reports 346. The lookup also keeps working when another extension plugs into one of the export steps. ([#757]())
Reasons to choose Mirasvit
Client focusing and satisfaction

These are our primary. A major portion of our new clients come from referrals from our existing clients. Our professional team of developers, marketers and support staff have invested the best knowledge and experience in the field into our work, so you know you can come back to us again and again.

Remarkable support

One year free and high quality support. We go to great lengths to provide maximum satisfaction with every module you have purchased in our store. By helping you with installation, configuration, answering your every question, we do all our best to eliminate any possible problems.

Risk-free Investment

30-days money back guarantee. If you are not satisfied with our Magento to Facebook shop performance for any reason, we provide a full refund.

Constant improvements and upgrades

We constantly add new features to all our modules, and are always interested in hearing your opinion and implementing your suggested features in our future developments.

Comprehensive Documentation

We provide an expanded user guide for every aspect of our Facebook store Magento, so you can find answers for all your burning questions.

Unencrypted source code of our products

You can customize Facebook shop Magento 2 according to your needs and requirements.

Usability and Performance

The Module is easy to install and upgrade, just follow our step-by-step user guide. Additionally, the extension is ready to use with the Hyvä theme.

Ready for Magento Cloud

No core modifications. The Facebook Magento has been tested in a Magento Cloud environment and is fully compatible with it.

Loading...