The Journey of the Japan Goods Decision Chain

The hardest part was not writing the interface, but agreeing what the data meant

The three tools were written three different ways, and their data formats did not recognise one another. Yet the real blockage was not format. It was definition.

The radar has a long filtering chain before it calculates a price baseline: remove accessories, remove unrelated models, remove listings whose condition is unclear. At first, to save time, I queried the raw table and inspected that distribution. The result bore no resemblance to the numbers the system actually used. I thought the data was polluted by accessories; in reality, it was not.

I made a rule after that: before drawing a conclusion from any number, first confirm that it is the number the system truly uses. That rule has saved me many times since.

An error that had been hiding for a long time

The watch category once had a ¥50,000 price ceiling. Any completed listing above it was excluded from the baseline. I had added it casually long ago, intending only to block absurd data.

When I removed it, one model’s median jumped from ¥8,650 to ¥89,000—tenfold. Its baseline had always been wrong, and spectacularly so. Most transactions for that model were naturally above ¥50,000; the cap cut off the entire upper half and left only the scraps.

Worse, the error was not obvious. The median is naturally insensitive to clipping, so everything appeared normal. The two values pulled out of shape were precisely the percentiles used to judge a purchase—the two I actually looked at.

The final method trims 5% from each end of the price range for each model. There is no fixed monetary cap, so the range rises with the market. I recalculated every model under the new definition.

Now, opening any model’s market section reveals an “historical baseline” row further down, with the old method labelled “includes ¥50,000 cap”. It is not there as a souvenir. Once a number has changed, I need to know what it looked like before.

The data did not move house

The easiest way for one panel to read three datasets would have been to copy them into its own database. I did not do that.

The cost of copying is greater than it looks. Two copies will eventually diverge, and on that day it will be impossible to know which one is correct. The panel therefore copied not one row. Every read is relayed to the original source. It is a little slower, but there is only ever one truth.

The Sales Records database had another complication: it was made for purely local personal use and never had authentication. To use it from the panel, its port had to remain entirely on localhost. Every request passes through the panel backend, and the outside world never touches it. I retested this after every later change because one missed opening would put those product photographs directly on the public internet.

Those thirty seconds in the shop

The panel is made for use in a shop. That sentence determined many details that appear unrelated.

There is no jargon in the interface: percentiles are called “low, middle, high”, with the test written beside them in plain language. All data is sent once and filtering happens locally on the phone, so a tap does not introduce a wait. The gate uses a passphrase I wrote and a six-month Cookie rather than a more orthodox enterprise login; the latter requires an email verification code whenever it expires. Standing in a shop with a camera in my hands and a member of staff watching, I cannot spare that half-minute.

Seventeen batches of changes

The panel was not finished in one pass. It was worn into shape batch by batch: connect the data first, bring the functions across one at a time, then compare the original three interfaces line by line to see what was still missing.

That final comparison found eleven omissions, seven of them in the same place: transaction records. The reason was straightforward. I used that part the most, so I built it first, before I knew what the whole thing would eventually become.