Reading the Naver Results Page From Behind a Proxy

Trying to measure a portal engine as if it were a classic search engine produces a wrong answer on the first round. On a classic engine the question "what position am I in" has a clear answer; in a portal model the same query returns a page in which blocks from independent sources are stacked on top of each other. Moving up one step in the organic list means nothing if that block has slid far down the page.

A proxy touches only one input in this picture, not the whole of it: where the network the request comes from appears to belong. That input matters above all in location-sensitive blocks; language, session and interface preferences stay the same regardless of your exit and continue to contaminate the measurement.

Below you will find first what parts the page is built from, then the order of the location signals, then how to separate out the session, how to test advanced search, and finally exit selection and setup steps.

Why isn't the answer to a query a single list?

Naver has long grown as a portal rather than a search box. The effect on the results page is clear: depending on query type, blocks from its own content services, general web documents and location-sensitive local cards share the same page. On a conceptual query, posts and discussion content from its own ecosystem come to the fore, while on a business or venue query local cards and the map block move to the top.

This has two consequences for measurement. First, the data you need to record is not the "rank number" but the "block composition": which blocks are on the page, in what order they sit, and how many records each block shows. Second, when interpreting the difference between two rounds you must first look at whether the composition changed; if the block order has shifted, movement in the underlying records is already the expected outcome.

The variety of block sources also determines language sensitivity. On a query written in Korean, content from its own services is plentiful, while the same concept in Latin script drops the page back to general web documents and a sparser set. If you want to build a comparison across two languages, run them as separate series; a language comparison squeezed into a single table cannot be interpreted.

Finally, the interface version: narrow-screen and wide-screen output can come with different block orders. If you do not record which view your measurement round was made in, it will be impossible for someone else to reproduce that round later.

Where do map and business cards infer location from?

Location-sensitive blocks are the most useful proxy test you have, because they visibly change behaviour when the exit country changes. But location estimation does not come from the IP alone. The following inputs are in play, in order: the region the user explicitly selected inside the service, earlier preferences carried by the session, the browser's location permission and, last, the geographic inference of the network the request comes from.

This order matters because the ones above override the ones below. If you have selected a region inside the service, moving your exit to another country may not change the local cards. This is a very common cause of what gets read as "the proxy is not working": the proxy is working, but a stronger signal is overwriting it. For a clean test, no region should be selected in the profile and no browser location permission should be granted.

If you need a city-level view, selecting a country may not be enough. There are setups within exit pools that allow targeting at city or provider level; the method and its limits are covered in city and ISP-based targeting . Even so, accept this from the outset: city inference is approximate work, and the same address can fall into different cities in different data sources.

Separating the logged-in state from the measurement

The results page you see while logged in is shaped by preferences tied to your account. That is desirable in everyday use; in measurement it is the single biggest contaminant. Because the history tied to your account travels with you when you change your exit, it produces the impression that "I changed country but the result is the same".

The correct setup is simple but requires discipline: measurement rounds are always run on an empty profile that is not logged in. If you need to measure a scenario that requires logging in, run it as a separate series with a fixed exit; do not compare logged-in and logged-out rounds in the same table. The two series measure different things.

In logged-in scenarios a second rule comes into play: address stability. A session arriving at short intervals from addresses in countries far apart creates an inconsistent picture and can trigger additional verification. For work of this kind use a sticky session, choose a duration longer than your working session, and remember that you will get no warning when the duration expires (sticky session setup).

How decisive is each signal?

The indicators below show, representatively, the relative weight of the three signals that shape location-sensitive blocks. These are not measured values but scores that tell you which variable to close down first during setup: the highest-scoring signal is the one with the greatest power to override the others.

The practical rule that follows is this: if you want to see the effect of the proxy, you first have to zero out by hand the signals stronger than it. A country test run while an in-service region selection is still in place does not measure the network side at all. There is no way to reverse the order; the only thing you can do is disable the signals above.

The second practical point is the single-variable rule. In one round change only the exit country, and touch neither the language list nor the profile. In the next round change only the language and keep the exit fixed. In a table where you moved two variables together, nobody can say which difference came from which — the result is a pile of data that cannot be argued about.

The third is the number of repetitions. A single look reflects the index state and block composition at that moment; the same query may come back differently the next day. When you repeat the same query several times under the same conditions on different days and see the variation between them, you also learn how large a real difference has to be.