How did we bring the Product Update Processes Down from Hours to Seconds at Trendyol?

Bilal Aksal
Trendyol Tech
Published in
9 min readDec 9, 2021

In our first article as the Quokka team, we covered the release process of products added on the site for the first time. In this article, we will handle the content update of the products already on sale and discuss how we lowered the update process from hours to seconds.

As the Quokka team, we are responsible for product quality control and therefore need to preserve the product content by having the updates reviewed, the inapplicable update requests caught and prevented from making it on the product page.

As the quality control team, we listen to the updates made to the images, category features, and title and description of the products on sale and start the process. Quokka team doesn’t follow up on price and stock updates.

The Shortcomings of the Process

We would carry out unnecessary checks, (to be discussed later on) in every update and leave the product up to the product agent’s (employees who do the manual checks) review.
ℹ️ Although it varied depending on the number of products an agent had to review, it would take 24hrs on average per product for an update to go through all the processes, get approved, and reflected on the site.
ℹ️ Image, title, and category features update requests were all left to the agent’s judgment leading to 4M+ products waiting to be reviewed on a monthly basis.
Let’s go into detail on the flow of the update process for a product on sale pre optimization.

The Old Update Processes

The process starts when the requested seller updates under Quokka’s domain are received.
As we do with each update, we check to see if the seller has any authorization to make updates. If it is a single seller, meaning it is not Buybox(multiple sellers of the same product) the update process is started. If it is Buybox, it is rejected.
Let’s work off of a scenario where the seller wants to update the title;

  1. Seller would want to update a product with a minor change in the product title.
  2. Once the process started in Quokka, we would get all the seller information and try to reload the images. Next, we would have to manipulate the image dimensions to comply with Trendyol standards. These processes could draw out depending on the response time from the image repository endpoint.
  3. Product title and description would include the following checks; Are there any banned words? Does it contain a brand name the seller isn’t licensed to sell? Is the seller pushing illegal products?
  4. The updates would be reflected on the product page after they went through these checks and an agent manually approved them.

Why did we decide to Optimize?

The update requests would be added to the end of the line and wait for the review of the requests ahead. The number of products sitting in Backlog had reached 4million.
Agents would review 200k–250k products on average per day. However, the continuous flow of requests piling up had rendered the agents unable to get on top of it.
Because we handled it as one process, we would reject the update if there were no issues with the image update yet the product name update was inappropriate. We had to transition to a model where we would remove the burden of reviewing the update requests manually and do them automatically. Only the products that the system couldn’t decide on would have to be left to the agents’ review. We had to turn
it into a system where the update requests that met the determined requirements were automatically approved and those that didn’t were rejected.

The New Product Update Processes

When sellers make a product update over the system, a message as the following drops in Quokka with the updated fields.

Products with multiple sellers undergo extra checks. In order to preserve the product content, not any seller can update the products. The seller’s authorization to update the product is checked via the predefined mapping (approved for product update seller and product category-brand matching) in the Quokka system.

Only distributors have the authorization to update products. If this condition is met, the update process starts. If not, the update request is rejected.

Update requests proceed in three main processes based on the updated field.

1️⃣ Image Update

The process where update requests from sellers regarding adding, deleting, or rearranging images for products on sale are carried out.

If image is one of the updated fields in the update event above, it means that the seller has made an update in the images field.

Once this request has been made, the images the seller has requested to update are downloaded to be localized and stored in an AWS S3 bucket under the Quokka domain. Naturally, the image links provided by the sellers may speed the process up or down. Seller can make update requests for multiple products over Excel as well as making them one by one. There are no problems with uploading the images onto AWS from the seller panel or the image gallery however, if the seller has provided their own images, download process varies depending on the rate limit or the latency (late return) of the domain where the images reside.

In the products links the sellers provide;

  • The absence of images (Youtube, Google links with no images)
  • The inability to access an image at the time (the temporary removal of the image)
  • The denial of access by the link site (instances when we send excessive GET requests to the domain under consideration)
  • The inability to access a site at the time (5xx message when we visit the site)
  • Oversize images (images of maximum 5mb are accepted)
  • Inapplicable image file format (images must be in jpg, jpeg, and png).

These types of issues prevent the download processes. We try a few times when we get an error; however, we reject the update requests when we reach the maximum number of error repeats.
After the upload process is completed, the images are resized to meet Trendyol standard sizes.

The resized images undergo a checking mechanism, which monitors the existence of +18 fantasy products, pornographic content, words that could be ads for other companies, and phrases such as “no images” and “image being prepared.”

2️⃣ Category Feature Update

The process where update requests in category features (color, size, device
capacity….) are carried out.

  • For the Buybox products, we check to see if the values entered by the
    suppliers conflict with the values in Buybox. We reject the update if an
    important value such as age group, gender, and guarantee type has been
    entered differently from the values used among other suppliers selling the same product.
  • Not every supplier’s information necessarily matches the information for the product on sale in the panel where product entry/update is done. Therefore, if we receive an update request for a value that’s already available for the product, we decline the update with the explanation that “this value is already available for the product”
  • Our expert teams working on the categories may transiently change some category features. That’s why we reject the update with the explanation
    “missing compulsory/required category values” if some compulsory/required values aren’t reflected in the updates as we update the product.

3️⃣ Title and Description Update

The process where the update requests from sellers regarding the product title or description are carried out.
After Quokka receives updates made on the product title or description. The requests that include;

  • Political content
  • Swearing and defamation
  • Brand names besides its own Ads for websites
  • Undergo a mechanism that checks for words or word groups in connection to products that are banned for sale.

The three processes rapidly proceed independently, without having to wait for each other, and simultaneously. However, in some cases, update requests that require theattention of agents may come up as well.

In the model we call Buybox, multiple sellers may sell the same product. The title, description, category features, and images for the products on sale are the same.

Sellers can determine their own price and be added as a seller under the product. All the sellers will be impacted if there is an update on a product with multiple sellers.
We established a similarity check structure to avert that occurrence.

ℹ️ Similarity Check

After the update processes start in Quokka, the seller’s requested title and image update is compared with the title and the images currently on the product page and the similarity result is checked out. We audit this process via a structure we call Similarity.

A multiple seller product

As seen above, a seller may request a change for a product on sale titled “Phone 11 64GB Siyah Cep Telefonu (Apple Türkiye Garantili) Aksesuarsız Kutu AP-IPHO11–2020” as “Phone 11 128GB Siyah Cep Telefonu (Apple Türkiye Garantili) Aksesuarsız Kutu AP-IPHO11–2020” and instantly start to sell a 64GB product as 128GB. Out of nowhere, all the sellers start to receive orders for 128GB, causing serious distress.

When we receive an update request like the one on the right for a product like the one on the left, Similarity structure will run a title and image comparison and calculate similarity ratios.

{
"id": 0,
"version": 0,
"textSimilarity": 0.5757242020872213,
"imageSimilarityV1": 0.7471575100288159,
"imageSimilarityV2": 0.7471575100288159,
"status": "REJECTED"
}

If we take a look at the result above, image and title similarities were calculated as %74 and 57% respectively and the request rejected because it came under the threshold.

The Impact of New Product Update Processes

The processes do not impact each other because we carry product update requests out in 3 different processes. While an image update request may be approved a title update request for the same product may be rejected.

We reduced our manual workload by automating the product update processes and only utilizing the agents in cases where we couldn’t make a decision.

The processes accelerated due to the automated execution. In the old update processes it would take 24hrs on average to update a product, now it takes 10 minute.

If we check out the statistics for October when there are intensive campaign
preparations for the November campaign period;
In total, 3.4million product updates were done. The breakdown of these updates among the 3 processes is as below;

To explain the graphic above;

  • 22,000 image update requests were reviewed by the agents and approved.
  • 292,000 product title requests or product description requests were reviewed by the agents and approved. This number is higher than the others because of products that got detected by the check mechanism for banned brands/words including title or description update requests.
  • We have removed the agents from the product feature update process
    completely and fully automized this process, and therefore, agents don’t run any feature update checks.

We can review the pie chart below to see the results in general.

The chart above indicates that we carry out the majority of product update
requests automatically.
We approved a total of 3.4million product update requests in October.

Thanks to our automized structure, we were able to reflect 90% of these
approved requests on the front page in seconds.

We reduced the manual load by leaving just 10% to the agents. We automatically increased seller NPS by accelerating the product update processes.

It’s a wrap for this article.

Are you questioning how to do better all the time and, care about continuous development? If so, apply here to be a part of the Trendyol team.

If you want to keep abreast of technology, we are here.

--

--

Bilal Aksal
Trendyol Tech

Senior Software Test Automation Engineer @Trendyol