Why doesn't web scraping capture the 'real price'? The secret behind Naver Smart Store pricing

“Why do the prices of the same product look all different?”

Any brand practitioner must have had this experience at least once. Searching for the same product but seeing multiple prices mixed up, such as 19,800 KRW, 22,900 KRW, and prices before and after applying coupons. Why does the exact same product look so different?

On the surface, it looks like sellers are changing prices as they please, but the actual cause is closer to the characteristics created by the platform structure and data structure rather than the seller's intention. On Naver, only representative options are exposed, coupons and discounts are applied in multiple stages, and the shipping fee display method, advertisement/natural exposure mixing, and even PC/mobile UI differences overlap, creating an environment where even normal prices inevitably look like multiple prices.

On top of this, when sellers set options, volumes, and bundle packages differently, or start inserting irrelevant keywords to target the top of search results, the problem becomes more complex and the data becomes more jumbled. In other words, the problem of prices looking different does not start from the seller's fluctuations, but from a structural environment where data that is difficult to interpret accumulates in the first place.

So, when you actually monitor prices, it naturally leads to these kinds of concerns.

• “Can't we automatically filter out samples or similar products?”

• “Is there a way to automatically convert bundled products based on unit price?”

• “Can we see only the actual selling option prices separately, instead of the representative option?”

• “Can we exclude advertised products and monitor only the 'real selling price' separately?”

• “Is there a way to compare based on the final payment amount including shipping fees?”

The core of price monitoring is not how much data you have collected, but the process of 'refining, interpreting, and sorting' that data to make it actually comparable. Therefore, low-cost crawling chosen solely based on unit price inevitably creates limitations, eventually leading to a situation where practitioners have to clean it up manually again.

Structural reasons why Naver prices look 'diverse'

Naver Smart Store does not display prices in a simple list format, but rather in a structure where options, coupons, shipping fees, advertisements, and device environments are all intertwined. Because of this, from a practitioner's perspective, confusion is bound to arise: “Why do the prices for the same product look so diverse?” Below, we will look at the specific structural causes that generate this confusion one by one.

(1) Structure where only the representative option price is exposed

Naver search results basically show only one representative option price. The problem is that most brand products have different prices depending on the option.

For example,

• 30ml / 50ml / 100ml

• Single item / 2-pack bundle / configuration including free gifts

Even with these various options, Naver often exposes only the price of the single cheapest option among them.

Then, from a practitioner's perspective, the price of the actual main sales option appears distorted, making it difficult to accurately interpret competitors' pricing strategies. It even creates an illusion for consumers that makes it look cheaper than it actually is, leading to a problem where the market price perception becomes blurred.

Therefore, the price seen on Naver does not represent 'the price of the entire product' but can be seen as merely a fragmentary price signal created by the representative option.

(2) Immediate discount, store coupons, and cart coupons are not revealed on the screen

Naver's pricing system is a structure where discount elements are applied across multiple layers.

• Immediate discount: Automatically reflected at the top of the detailed page

• Store coupon: Applied only when clicked on the product page

• Cart coupon: Reflected at the step right before payment

Only when these three are combined is the actual payment amount determined, but in search results, only the price before coupon application is shown. Ultimately, practitioners face a structure where the exposed price and the actual payment price continuously do not match. In other words, on Naver, a gap structurally exists between the 'visible price' and the 'actual payment price.' Simple crawling alone cannot accurately reflect this difference.

(3) Prices with and without shipping fees are mixed and exposed

Naver search results basically expose only the product price, and the shipping fee is attached as a separate notation. However, in actual comparison, the following two are completely different.

• 9,900 KRW + Shipping fee 3,000 KRW (Actual payment 12,900 KRW)

• 11,900 KRW + Free shipping

This is also the point where practitioners make the most mistakes; when comparing only the superficial prices, the first product looks cheaper, but in reality, the second product is cheaper. Because Naver does not sort or distinguish these two types, it is easy to distort price judgment just by looking at search results.

This structure creates the same problem in crawling. It is difficult to distinguish whether the price includes shipping fees, and because there is a possibility that shipping fees differ by option, it is not easy to compare the actual payment amount as is. In other words, the shipping fee structure absolutely requires a separate refinement process.

(4) Advertised products are mixed with organic search results

Naver Power Link and Shopping tab advertisements are exposed in a form that is almost indistinguishable from organic search results. Not only consumers but also practitioners find it difficult to grasp at a glance whether it is the lowest price based on advertising or the actual lowest price. Advertised products frequently cause price distortion because they set up exposure strategies such as putting the lowest price or bait price forward to induce clicks, setting the representative option abnormally low, or actively utilizing free shipping and immediate discounts.

As a result, there is a high possibility that the price exposed at the top of search results does not reflect the 'market average price.' For this reason, if you do not remove ad exposure in brand price monitoring or layer it separately at the analysis stage, a situation easily occurs where you are regularly dragged down by low prices, shaking the overall price perception.

(5) Price exposure methods differ between PC and mobile environments

On PC, the option configuration and price are immediately visible, but on mobile, the options are collapsed, creating a structure where the representative price is more strongly perceived. Because of this, even for the same product, the illusion that the price looks different depending on the device environment frequently occurs. In other words, on mobile, the illusion centered on the representative price occurs much more strongly. Considering that most consumers shop on mobile, from a brand's perspective, the distortion of the price structure is bound to be felt even more significantly.

Therefore, for accurate price monitoring, 'data refinement technology' must be applied together

Naver's price exposure method is designed so that accurate price comparison data cannot be created simply by collecting price strings. When the previously explained representative option base price issue, coupon structure, shipping fee structure, ad/organic exposure mixing, and UI differences by device overlap, the collected data becomes 'unstructured data' that cannot be used as is. A simple crawler can scrape the 'price looking like a string' on the screen, but it cannot interpret whether that price is the actual payment price, the representative option, or an advertising price.

Therefore, to compare and judge prices in the form the brand wants, a 'refinement process' that interprets and normalizes the platform structure, rather than simple crawling, is absolutely necessary.

Why brand base prices are not applied in practice even if they exist

Previously, we explained that the reason Naver prices look diverse is due to the exposure structure of the Naver platform. However, the confusion practitioners experience when actually conducting price monitoring does not end here. It is not just that the Naver structure is complex, but the problem of the collected data itself not being consistent creates another round of confusion.

In other words, even if a brand has a base price, if the data structure that serves as the starting point for applying that base price is not organized, the base price comparison cannot be established in the first place. Therefore, in practice, despite having a base price, situations frequently occur where similar products look like multiple different items or where base price non-compliance detection is caught incorrectly. No matter how clear the base price is, if the data to be compared itself is in an unrefined state, it is virtually impossible to apply.

The core of this problem lies in the fact that sellers register product information in different ways. We will explain three representative types of how this data inconsistency makes applying the base price difficult.

(1) Options, volumes, and bundle configurations differ by seller

Even for the same product, because the option configuration (single item, bundle, free gift included) is set completely differently by each seller, in practice, it is difficult to distinguish whether the base price is based on a single item or a bundle, frequently causing problems where the price comparison itself cannot be established.

In other words, in a situation where configuration information is not normalized, it is difficult to even judge which price should be compared with the base price.

(2) Model name notation methods vary, making it difficult to identify the identical model

As sellers write model names in their own ways (“Brand A Ampoule 50ml”, “50ml Ampoule / Brand A Genuine”), identical products are collected separately as if they were different products. Consequently, in practice, a single base model appears scattered across multiple products, causing confusion where the base price comparison is dispersed on a product-by-product basis.

To solve this problem, a 'model normalization' process that standardizes model names and groups even similar keywords into one model is absolutely necessary.

(3) Cases where sellers 'intentionally twist' brand names and keywords

If a seller modifies and uses brand names and keywords aiming for top exposure in search, products that deviate from the base model flow in in large quantities, and simple crawling cannot distinguish this, repeating the problem where the data itself to which practitioners can apply the base price is not secured. Low-cost crawling cannot distinguish modified keywords, sometimes resulting in a large volume of unintended products flowing into the search results.

Particularly in areas where keyword stuffing is severe, like the beauty category, even if there is a base price, creating an applicable data pool itself is not easy.

It is impossible to match unrefined data to the base price

Summarizing the above three types, it becomes clear that the reason the brand base price does not work properly in practice is not because the base price itself is unclear, but because the data structure to which the base price can be applied is not refined.

Option, bundle, and volume configurations differ by seller, model name notations are inconsistent, and brand names/keywords are modified and intrude. In the end, if