Magento Akeneo: Maintain Product Data Once and Deliver It Reliably in the Shop

Akeneo is a product information system that exists in a free edition, the Community Edition, and in a paid Enterprise Edition. It bundles product data from various sources, arranges it in families with attributes, enables translations and channel-specific values and provides the finished data through a programming interface. The shop is then a channel that picks up this data.

For Magento Akeneo this means: the product data has a leading system, and Magento becomes an output channel. Texts, attributes, categories, variants and images are maintained in Akeneo and shown in the shop. Prices, stock and orders, on the other hand, usually lie in the ERP or in merchandise management, the PIM does not take care of them. Drawing the line is part of the planning.

Depending on the edition the possibilities differ, for example in media management and reference data, which are additionally offered in the Enterprise Edition. Magento Akeneo therefore begins with the question which edition and version you use, what your data structure looks like and which channels exist.

A PIM also changes the division of labor: the maintenance of product data moves from the shop administration to those who know the products best, for example product management or marketing. For the shop this means that changes to PIM-led fields in the shop itself are not permanent. Your team must know that, and we record it in the documentation and, where sensible, in notes in the admin.

Which data flows in Magento Akeneo you define with us in the inventory. Typically there are five areas.

Not every Magento Akeneo project needs all five areas. Often it begins with attributes, products and images and later grows by categories and multilingual content. This way you see results quickly and can use the budget in stages.

The table shows a typical pattern. In your business it may differ, and that is exactly what we clarify in the inventory.

With Magento Akeneo a clear rule on data ownership prevents most disputes. Whatever can be changed in the shop and in the PIM leads to contradictions sooner or later. That is why we define exactly one leading system per type of data. The table also shows that prices and stock usually do not come from the PIM: whoever wants to maintain them there needs a separate data flow.

For Magento Akeneo, Akeneo provides a REST interface through which families, attributes, selection values, categories, products and product models are read. The connectors build on this interface. Which functions are available in your edition depends on version and license.

The vendor offers its own connector for Adobe Commerce, that is Magento. It is available in versions for the Community Edition and the Enterprise Edition, transfers categories, families, attributes, options, products and product models and uses the programming interface of Akeneo. The Enterprise version additionally supports the media management and reference data of the Enterprise Edition. These statements come from the product pages of the vendor and can change with new versions.

Before every project we check whether this standard connector fits your constellation. That is an honest part of our offer: if it covers your requirements, it is usually the more economical solution, and we support you with setup, assignment and operation.

A standard connector covers the usual processes: create structures, transfer products and media, update regularly. An individual development for Magento Akeneo pays off if your data or processes go beyond that, for example with special assignments of attributes, customer-specific rules when creating products, additional data flows such as prices or reviews, or special requirements for speed with large catalogs.

A mix is also common: the standard connector takes over the bulk, and we add extensions for the deviations. We make sure that updates of the connector and of Magento are not made harder by interventions. With every solution include the care as well, because an individual development needs someone who looks after it.

If more than two systems are connected, for example PIM, ERP, shop and shipping provider, a middleware can additionally make sense. The decision aid is in the guide to ERP integration.

On the Magento side we build the integration as its own module according to the standards of the system, without interventions in the core. The module uses the interfaces and queues of Magento so that transfers run in the background and the shop does not become slower for visitors. Orders are placed in a queue on arrival and processed there until the ERP has confirmed them.

Prices by customer group, tier prices and several warehouses are mapped by Magento with its own functions that the integration fills. Where possible we use these standard functions instead of inventing our own tables. That keeps the shop update-capable and lets other developers join in later.

In the admin you see what was transferred: a log shows date, record and result, with a filter for errors. For the peculiarities of Akeneo we add settings in the admin, for example assignments of payment methods, shipping methods and tax classes, so that changes need no development.

With Akeneo the volume deserves a look: large catalogs must not be transferred completely with every change. Magento Akeneo therefore transfers only what has changed, in packages and in the background, and the shop stays fast for visitors.

We see these points again and again in projects. They can be planned if they are known early.

• Data model

  The families and attributes in Akeneo do not fit the attribute sets in the shop and must be assigned before the start.

• Variants

  Product models with several levels of variants cannot always be mapped one to one in Magento.

• Large volumes

  A complete synchronization with every change overloads the shop instead of transferring only what has changed.

• Media

  Images and documents are large, are transferred together with products and slow everything down.

• Double maintenance

  Texts are maintained again in the shop and overwritten at the next synchronization.

• Languages

  Translations and channels from Akeneo are assigned to the wrong store views.

An integration connects two systems with business data, so clear rules apply. The exchange runs encrypted, credentials do not lie in the source code but in the protected configuration, and the integration receives only the rights it needs. Access belongs to a separate service account, never to a private account of a person.

When testing we work with test data or anonymized data as far as possible. As soon as developers get access to personal data, for example customer accounts or orders from Akeneo, an agreement on commissioned data processing is needed. We clarify that before the start so that you are legally well set up.

The log of the integration contains what is necessary for operation but no credentials and no unnecessary personal data. Retention periods are defined with you. These notes are not legal advice, the concrete arrangement depends on your company.

We keep the start deliberately short so that you quickly know whether and how the integration is feasible.

The following constellations are examples from the practice of Magento Akeneo projects, not statements about particular customers. The first is a manufacturer with a large catalog who needs product data for several channels. Akeneo is the leading system, Magento is one channel among several. Here we check whether the standard connector is enough and concentrate on speed and clean assignment.

The second constellation is a merchant who, in addition to the catalog, maintains own content in the shop, for example guide texts and marketing pages. It is important which fields come from the PIM and which stay in the shop so that the next synchronization does not overwrite texts. We record that in writing in the inventory.

The third constellation is a business in several languages and countries. The challenge lies in the assignment of languages and channels from Akeneo to the store views in Magento and in which data differs per country. For this we create an assignment table that you can understand and maintain yourself.

In all three cases a small trial pays off: before the whole catalog is transferred, the integration transfers a selection of typical products, including simple products, variants, products with many images and products in several languages. You check the result in the shop, and only then does the full synchronization run. This way assignment errors show up early and cost little.

An interface is not a one-off project but ongoing operation. After the start a log monitors every transfer: what was transferred when, what failed, what is repeated? Errors that cannot be fixed automatically are reported visibly so that nobody learns of them only through a customer complaint.

Updates change the situation. A Magento update, a new state at Akeneo or a change of the vendor interface can affect the integration. Therefore the planning includes an agreement on how updates are tested and who approves them. Ongoing care can be regulated through a maintenance contract that covers monitoring, updates and error fixing.

Documentation is part of the delivery. You receive a description of the data flows, the assignments and the rules for special cases so that your team or another provider understands the integration and can continue it. Source code and access stay with you.

A flat figure for Magento Akeneo would be unreliable because the effort depends on your constellation. It is determined by the number of data flows, the quality of the data in Akeneo, the number of special cases with prices, warehouses and customers and the required timeliness. A data flow in one direction is built much faster than a synchronization in both directions with conflict rules.

We work with an open hourly rate of 30 euros net, without emergency surcharge. After the inventory you receive a written estimate that lists the data flows individually so that you can control scope and order yourself. For clearly defined packages a fixed price is also possible. All prices are on the page pricing.

Besides the development, include the running items: hosting, maintenance and, where applicable, licenses or fees for Akeneo and for additional services. We show these items separately in the estimate so that you can compare quotes over several years.

An honest offer includes naming the limits. We do not sell a ready-made connector off the shelf but develop Magento Akeneo project by project according to your processes. That means: we implement exactly what you need, but not in a day and not for a flat price that cannot be calculated beforehand.

We are a web agency in which fixed freelancers work together, all from home offices. We are not a large agency with a hundred employees and cannot take on every project at every time. We tell you early whether and when we have capacity. We name customers only with their consent, and in the first conversation we gladly talk about comparable constellations.

We give no legal advice. Questions about commissioned data processing, data protection and the license terms of Akeneo you clarify with your legal adviser and the vendor. What is technically possible depends on version, operation and license of your system and is checked in the inventory.