The editorial team published Features content regularly but had no easy way to see how individual pieces were performing in terms of traffic. GA4 existed but required manual querying every time anyone wanted an answer. Nobody was consistently monitoring whether content was being read, shared, or had gone completely stale.
A single view that automatically matched published content from WordPress against its GA4 traffic data, surfaced pieces that had received zero views, flagged evergreen content worth re-promoting, and was fast enough to check in under five minutes.
The deeper issue was that editorial decisions were being made on instinct rather than data. Good content was being left to go stale while the team kept producing new pieces without knowing what was actually landing. The tool needed to change that default behaviour, not just answer occasional one-off questions.
An internal Google Apps Script web application deployed at go.bellanaija.co/featuretracker. The app pulls live content data from the WordPress REST API, matches each published post against its GA4 performance metrics via the GA4 Data API, and presents everything in a searchable, filterable dashboard.
Key features: summary cards giving an at-a-glance view of overall content performance, trend charts showing traffic over time, zero-view alerts flagging content that has received no traffic at all, evergreen alerts identifying older high-performing content worth pushing again, a search and pagination layer for navigating the full content archive, and CSV export for when someone needs to analyse the data offline.
One technical constraint worth noting: GA4's Data API has a row limit per call. Pulling all traffic data and filtering afterwards would either miss content or hit rate limits. The solution was a custom inListFilter approach — querying specific post URLs directly rather than pulling everything — which keeps response times fast and stays within API limits even with a large content archive.
The team went from manually querying GA4 and cross-referencing with the CMS to having a single view that answered the most common editorial questions in one load. The zero-view alert was the feature that got used most consistently — it surfaced content that had been published and forgotten, prompting re-promotion decisions that would not have happened otherwise.