Most data-heavy pages are built around what the data is. Not what the user needs to do with it.
This is the gap that separates a reference page from a tool. And in the age of Answer Engines, that distinction determines whether your page gets cited or gets skipped.
The Setup
Ren.ph's barangay zonal value pages serve thousands of users looking up BIR zonal values across Metro Manila and the provinces. The pages are comprehensive. Street-level data, type distribution, rankings, searchable tables. The full picture.
But here's what the data showed us: people searching for "zonal value San Lorenzo Makati" aren't interested in the zonal value itself. Not really. They want to know how much tax they'll pay when they sell their property.
The zonal value is an input. The tax computation is the output. And our page was organized around the input.
What Front-Running Means
Front-running user intent is simple in concept: put the answer to the user's actual question before they have to go looking for it.
In practice, it requires you to challenge your own information architecture. You built the page around your data model: tables, categories, classifications. That's how you think about the data. But the user thinks in terms of a task they need to complete.
The pattern shows up everywhere:
- A salary database where users actually want to know their take-home pay after tax
- A nutrition facts page where users actually want to know if the food fits their diet
- A zonal value page where users actually want to know their capital gains tax
The data is necessary. But it's not the destination.
The Refactor
Here's what we changed on ren.ph's barangay zonal pages.
Before
The page displayed zonal value highlights at the top, followed by distribution charts, street rankings, and a full reference table. The estimated tax section sat near the bottom: static, using only the barangay-level residential value for a fixed 100 sqm lot. A separate street search existed even further down. Two useful features, disconnected from each other and buried below the fold.
After
An interactive tax estimator sits immediately after the zonal value highlights: the second thing users see. It absorbs the street search into itself. Users pick their street, choose their property type, adjust their land area, and the tax computation updates instantly. The zonal value becomes an input to the calculation, not the headline.
The full reference table stays. The rankings stay. But they're now supporting material, not the main event.
Why This Matters for AEO
Answer Engine Optimization requires Algorithmic Integrity as its foundation. But integrity is necessary, not sufficient. Structure matters too.
When an AI is asked "How much is capital gains tax for a condo in San Lorenzo, Makati?", it's looking for a page that directly answers that question. Not one that buries the answer below six other sections.
Front-running intent isn't just better UX. It's better signal to answer engines. You're telling the algorithm: this page exists to answer this question. The structured data, the schema markup, the heading hierarchy: they all reinforce that signal when the page is organized around the user's actual task.
This is the difference between a page that ranks for "zonal value San Lorenzo" and one that also captures "capital gains tax Makati property," "CGT calculator San Lorenzo," and "how much tax when selling condo Makati." The second set of queries represents users closer to a transaction. Higher intent. Higher value.
The Framework
Front-running user intent follows a simple diagnostic:
1. What data does this page display?
Zonal values per square meter, by street and property type.
2. What does the user actually do with that data?
Multiply it by their lot size, then compute 6% CGT and 1.5% DST.
3. Is the page doing that work for them?
No. The user has to find their street, note the value, pull out a calculator, and do the math themselves.
4. What if the page did it instead?
Then the page becomes the tool. Not a stop on the way to the answer. The answer itself.
Apply this to your own data pages. If your user has to leave your page to complete their task, even if it's just to open a calculator app, you haven't front-run their intent. You've given them a data point and made them do the work.
Implementation Isn't Complex
The important thing to understand: this refactor didn't require new data infrastructure. The street-level zonal values were already loaded on the page for the reference table. The tax formulas are two multiplications. The interactive estimator is a client-side component consuming data that was already there.
The barrier was never technical. It was architectural. We had to stop thinking about the page as a data display and start thinking about it as a task completion engine.
This is a pattern we see repeatedly: the data exists, the infrastructure works, but the interface doesn't match the user's mental model. The fix is often a reorganization, not a rebuild.
What to Take Away
If you're building data-heavy tools, whether in real estate, finance, compliance, or any domain where users look up numbers to make decisions, ask yourself:
Am I showing them the data, or am I finishing their thought?
The page that finishes the thought wins the citation, the bookmark, and the return visit. The page that just shows the data gets used once and forgotten.
Front-running intent is how you turn a reference page into a tool. And tools get used.
This enhancement is live on ren.ph's barangay zonal value pages. Godmode Digital provides Fractional CTO services for firms building data infrastructure with Algorithmic Integrity.
Top comments (0)