Shelf Space
Why the second version of a system is usually the one worth building — and what a grocery store taught us about running ads on WordPress.
By Felipe Lujan-Bear · LiquidBook
The first version worked exactly as specified. It could serve a banner ad, rotate between a few creatives, and put them on the page. It did what it was asked to do.
Nobody could use it.
The feedback from the Agile Alliance staff was direct, and it was the most useful thing anyone said during the whole project: managing all the different ads and figuring out where each one was supposed to go was confusing and time-consuming. Which ad belonged on which page. Which one had expired. Which one was already running somewhere else. The software worked. The system had quietly handed all the hard thinking back to the humans.
That’s the failure mode nobody puts in a case study, so let’s put it in this one. A tool that technically functions but requires a person to hold the whole model in their head isn’t finished. It has just relocated the work.
V1 shipped knowing it would be insufficient. What it bought was the one thing a spec can’t produce: knowing exactly how it was insufficient.
What a grocery store knows
The redesign didn’t come from a feature request. It came from stepping back and asking how physical retail had already solved this, decades ago.
You don’t buy an ad in a grocery store. You buy shelf space. The shelf has a location. It stays where it is. Products come and go, promotions rotate, brands change — the shelf doesn’t move. The product knows what it is and what its own rules are. The shelf knows where it lives. Two separate concerns, managed independently, by different people, on different schedules.
That’s the entire architecture.
A placement is a shelf: a named location, dropped anywhere on the site with a single shortcode — in an Elementor widget, a block, a template. Once it’s there, it stays. Ads are the inventory. Staff assign ads to shelves from the WordPress admin, and each ad carries its own rules with it: how often it should appear relative to others, when it expires, how many impressions it’s allowed before it stops, whether it’s a wide format or a square.
Nobody edits a page to swap an ad anymore. Nobody schedules a rotation. They stock a shelf, and the system does the rest.
“We built shelf space, not just ads. The shelf stays in place. The inventory changes.”
The measurement problem you can’t see
There’s a technical problem underneath all of this that is invisible until it ruins your data.
The Agile Alliance site uses aggressive page caching, as any high-traffic content site should. Pages are pre-rendered and served instantly. But that speed is exactly what breaks conventional ad tracking: when a page comes from cache, nothing dynamic executes. The ad renders — it’s baked into the cached HTML — but the impression is never counted. You end up with a site that appears to be serving ads and a database that has no idea it happened.
The fix was to separate delivery from the page entirely. The cached page loads fast and ships with an empty container. A small script then makes a live request to the server, which selects the eligible ad, logs the impression, and returns the creative to be dropped into place. Clicks are logged the same way.
The result is the part that matters to anyone who has to report to a sponsor: every impression is counted, on every page, including fully cached ones — with no cost to site speed. And because those events also emit into Google Tag Manager and GA4, the data flows into whatever analytics stack the organization already runs, without custom instrumentation.
What “owning your data” actually buys you
Fourteen months into production, the system has tracked over 1.57 million impressions across 17 ads and 8 placements. That number isn’t there to impress. It’s there to make a narrower point: all of it is legible, and all of it belongs to Agile Alliance.
Sponsor accountability is the concrete version of this. A sponsor can be shown precisely how their campaign performed — filtered to their ads only, for any date range, broken out by placement, exported to a spreadsheet. Not a vague assurance that the banner ran. An actual report.
And the intelligence flows the other direction too. The data makes visible things that were previously guesswork: the top banner position generates fewer impressions than the sidebars but out-clicks all of them, so prominence beats volume on that site. Evergreen reference pages — the glossary entries, the foundational explainers people arrive at from search years after publication — turn out to be where engagement concentrates. That is genuinely useful to know before deciding where next year’s sponsorships live.
None of that required an external ad network, a monthly platform fee, or handing a third party a behavioral record of everyone who visits the site. The organization runs its own advertising infrastructure inside the CMS it already owns.
The click-through rate matters far less than the fact that there is one, that it’s trustworthy, and that nobody outside the organization had to be paid to know it.
The versions that never got built
The plan mapped four progressive versions. V1 was simple delivery. V2 was the placement system. V3 and V4 layered on further targeting and reporting capability.
V3 and V4 were never built. The client was satisfied enough with V2 that there was no reason to continue.
I think that’s worth stating plainly, because the incentive in this business runs the other way. The roadmap still exists and the architecture supports every bit of it. But a well-designed V2 that staff use extensively every single day is worth more than a feature-complete V4 that adds surface area nobody asked for. Knowing when to stop is part of the deliverable.
The same discipline shaped how it got there: built and broken safely in a local container first, then proven on a staging clone of the real site — logged-in and logged-out states, cache behavior, real theme and plugin interactions — and only then to production. By the time it went live, everything that could go wrong already had, somewhere it didn’t matter. Go-live was uneventful. That’s the goal.
Built for one, deployable for any
The ad system began life inside the Agile Alliance child theme. It was deliberately extracted and packaged as a standalone plugin, because a tool welded to one client is a maintenance liability, and the same problem shows up everywhere. Any organization running WordPress with sponsors, partner promotions, or internal campaigns to place has some version of this: real estate they own, and no structured way to manage or measure what goes on it.
That’s the pattern worth taking away, whatever your platform. Most organizations don’t need a new system. They need the one they already own to be given a spine — a clear model, native to the tools their staff already know, that keeps the data and the control in the building.
The shelves are already there. The question is whether anyone can see what’s on them.
For the technically curious
The story is above. This is the machine room.
- Data model. Two purpose-built tables log impression and click events, each tagged with its placement key — which is what makes placement-level reporting possible at all. Four custom post types cover ads, placements, campaigns, and clients.
- Cache-safe delivery. Ads are requested via AJAX after page load, so impressions are logged server-side on a live request rather than lost to a pre-rendered page.
- Weighted rotation. Selection is weighted, not round-robin — an ad at weight 10 serves roughly ten times as often as one at weight 1 — with impression caps and expiry dates enforced automatically at selection time.
- Responsive by format, not by breakpoint hacking. Ads are tagged wide or square; the loader requests the right creative for the viewport. Staff never think about screen size.
- Clean measurement. Administrator traffic is excluded from tracking by default, configurable per role, so staff browsing the site doesn’t inflate sponsor numbers.
- Zero-config install. Field definitions ship with the plugin via ACF Local JSON, so there’s nothing to configure by hand on deployment. Python build scripts produce an installable ZIP; a Docker Compose environment ships with the repo for anyone who wants to stand up a clean test instance.
LiquidBook — specialized WordPress, integrated with AI, built into the platform you already own.