Case Study — Scaling Allegro Ceny Campaign Management

Case Study — Scaling Allegro Ceny Campaign Management

How I removed a campaign scaling bottleneck without accelerating a much larger product redesign.

Context

Allegro is an e-commerce marketplace operating in the polish market and being a key e-commerce player (38% market share). Several key factors contributed to that scale: ease of use, virtually everything that can be bought is available there and significant competitiveness in comparison with other players.

Allegro Ceny was a campaign program focused on improving price competitiveness. The business logic behind it was relatively straightforward: improving whole e-commerce marketplace price competitiveness by participation from relevant offers and sellers.

The problem was that the existing operating model had not been designed for that scale. Allegro already had information that could help sellers identify relevant price opportunities. However, much of the process still depended on manual preparation, communication and seller input.

It worked at a smaller scale. It would not work for what was coming.

Dictionary

Allegro — one of the largest e-commerce marketplaces in Central Europe, connecting third-party sellers with buyers.

Offer — an individual product listing created by a seller. One seller may manage hundreds or thousands of offers.

Seller — a merchant selling products through the Allegro marketplace.

Campaign — a temporary commercial program in which selected seller offers participate under specific conditions, for example to improve their attractiveness to buyers.

Allegro Ceny — an Allegro campaign program designed to improve marketplace price competitiveness by encouraging sellers to offer selected products under attractive conditions.

Campaign parameters — conditions required for an offer to participate in a campaign, such as the expected campaign price.

Bulk operations — managing many offers at once instead of reviewing and editing each offer individually.

API-based workflow — a way for larger sellers to manage Allegro operations programmatically through their own or third-party software instead of using Allegro’s standard interface.

Goal

I was leading the product area that was building product behind Allegro campaigns (SmartWeek, BackFriday, etc) and delivering tooling for enabling price competitiveness maintenance. At one point I received urgent request:

Make Allegro Ceny operationally scalable and enable significantly broader participation without proportionally increasing manual work on Allegro’s side. With strict deadline caused by strategic business plans and the situation on the market.

Problem

The process did not scale

The more Allegro Ceny grew, the more work was generated for everyone involved.

1. For sellers, Campaigns were complicated. They had to understand campaign requirements (3-5 pages long T&C doc with attached long spreadsheets), decide which offers should participate and perform many repetitive operations.
2. For commercial teams, scaling meant more preparation, explanations, reminders and corrections.

Looking at the expected growth, it was clear that the existing model would consume an unsustainable amount of operational capacity.

It was not simply a UI problem

We already knew from seller research, usability observations and operational feedback that Campaigns were difficult to use.

However, one behavioral signal was especially important.

We observed that high-volume sellers often relied on API-based workflows rather than operating campaigns offer by offer through the standard interface.

That changed my interpretation of the problem. The issue was not only that the existing UI could be better.

The offer-by-offer interaction model itself did not scale.

The obvious solution was too big

A broader Campaign redesign was already planned. It was supposed to address many of the issues identified before, but its scope and maturity made it unsuitable for the immediate business need.

The new situation, urgent need for scaling up Allegro Ceny, looked like a tempting opportunity to move forward the whole Campaign UI redesign. Yet I decided not to do that. Urgency did not make the redesign smaller or less risky.

My role

I had two responsibilities at that time:

• Product Lead for the broader business/product area
• Product Manager for the development team implementing this particular change

My work covered:

• translating the business scaling problem into a product problem
• combining customer, behavioral and operational evidence
• deciding what should and should not be accelerated
• reprioritising the roadmap
• defining MVP scope
• aligning Design, Engineering and business stakeholders
• making the release-risk decision
• monitoring results and feeding learnings into subsequent product work

Approaching the challenge

Start with information we already had

There was no reason to restart discovery from zero.

Campaigns had already been researched multiple times. We had seller feedback, usability observations, behavioral data and direct operational evidence from people working with sellers. The important part was connecting those signals to the new scaling problem. The strongest insight was simple:

Allegro already had much of the information sellers were being asked to recreate manually.

So instead of asking how to make the existing form easier, I asked:

Why are we asking sellers and internal teams to reconstruct decisions from information the system already has?

Change the interaction model

I proposed exposing more of that information directly to sellers.

Instead of starting from an empty campaign form, the system would prepare most of the work:

1. identify relevant offers
2. prepare recommended campaign parameters
3. present the set directly to the seller
4. allow bulk review
5. let the seller remove offers or make adjustments
6. submit the confirmed set into the existing Campaign process

The seller’s job changed from:

“Find the right offers, understand the rules and configure everything manually.”

to:

“Review what Allegro prepared, adjust where necessary and confirm.”

That was the key product change.

Automate preparation, not the commercial decision

There was an important boundary:

Our tools were able to identify suitable offers and prepare recommended parameters.

Yet we did not have complete information about each seller’s individual economics.

That meant fully automatic participation would go too far.

So the system automated preparation and recommendation, while the seller kept the final commercial decision. That distinction was important both for customer trust and business risk.

Choosing a narrow MVP

Instead of accelerating the whole Campaign redesign, I proposed extracting one production slice.

The MVP focused on:

• Allegro Ceny only
• a limited seller population
• an existing seller-facing surface
• pre-selected relevant offers
• recommended campaign parameters
• bulk operations
• seller confirmation
• reuse of existing campaign capabilities

A lot stayed deliberately outside:

• other campaign types
• a complete Campaign redesign
• richer status and feedback
• final-quality UX
• broader rollout

The MVP reduced breadth and polish, but not the core job.

A seller could still go through the complete flow:

discover → review → adjust → confirm → submit

This also required a real roadmap decision. Other planned work was deprioritised to create capacity.

Delivery and risk

The difficult part was not only defining the MVP. We were knowingly releasing a constrained experience connected to an important business objective.

The standard usability-testing cycle did not fit the required window.

I decided to proceed with controlled production validation because the risk could be bounded.

We used:

• a limited rollout
• existing human support
• technical and behavioral monitoring
• rollback and fallback mechanisms
• explicit seller confirmation before submission

Engineering connected existing campaign capabilities with the seller-facing workflow rather than rebuilding the underlying logic.

The technical challenge was therefore less about inventing new campaign intelligence and more about turning existing capabilities into a usable seller product.

Results

The most important result was the change in scale.

The new workflow enabled Allegro Ceny to operate at a significantly greater offer scale.

Broader campaign coverage contributed to the wider business goal of improving marketplace price competitiveness, although I would not attribute that outcome to this product change alone.

The operational process changed too.

Before, commercial teams had to actively steer campaign participation through preparation, communication and corrections.

Afterwards, their role moved much closer to:

manual workflow execution → exception-based monitoring and intervention

They could focus on sellers who actually needed help instead of manually steering every submission.

The release also validated several assumptions:

• sellers accepted Allegro doing more of the preparation work
• bulk operations worked for high-volume campaign management
• recommendations could meaningfully reduce seller effort
• seller control still mattered where Allegro did not have enough information
• the production MVP generated useful evidence for subsequent Campaign product work

Summary

• Urgency does not mean that the biggest available solution should be accelerated. Sometimes the better decision is to isolate the immediate constraint and solve only that.
• Look at actual customer behaviour, not only declared problems. High-volume sellers using API-based workflows was a stronger signal than another request to “make Campaigns easier”.
• Automate what you know. Keep people in control where important information is missing.
• An MVP does not have to be disposable. A narrow production solution can solve an immediate business problem and at the same time generate evidence for a much larger product decision.