The problem
Content teams have two data sources that never meet. GA4 knows which URLs earned attention. The articles themselves know what they were about. Nobody joins them, so "what should we write next" gets answered from instinct and a spreadsheet of keywords that has no relationship to what actually performed.
What was built
A pipeline that joins performance to substance and produces recommendations a human can audit:
- GA4 ingestion. Metrics pulled per article via the GA4 Data API and aggregated over time, rather than eyeballed in the dashboard.
- Article scraping. The published page is fetched with Playwright, so the analysis runs on what readers actually saw, not on a CMS record that may have drifted.
- LLM topic and keyword extraction. Each article is reduced to the themes and entities it genuinely covers.
- Recommendation with evidence. Suggestions carry the data that produced them. An editor can disagree with a recommendation and see exactly why it was made.
Prototype in n8n, ship in Node.js
This is the part worth stealing.
n8n is the fastest way to discover what a pipeline should do. You can see every intermediate payload, reroute a branch in seconds, and find out that step four was never necessary. That speed is worth more than elegance while the shape of the problem is still unknown.
Once the flow stopped changing, it moved to a typed Node.js service. Not because n8n could not run it, but because at that point the requirements were tests, types, code review and CI — and those are things a repository does better than a canvas.
Knowing when to make that move is most of the skill. Porting too early throws away the iteration speed you needed. Porting too late leaves business logic in a place where it cannot be unit-tested.
What this does not do
It does not decide your editorial strategy. It tells you what performed, what each piece was actually about, and where the gap between those two things is. A person still chooses what to do about it.
Stack
- Prototype: n8n
- Production: typed Node.js
- Data: GA4 Data API
- Scraping: Playwright
- Language model: OpenAI, for topic and keyword extraction
Verifying the engineering behind this
We write custom n8n nodes, not only workflows. Our Apollo.io integration node is published on the
public npm registry as n8n-nodes-apollo (MIT,
maintainer arturl95), with source open to inspection. We also hold n8n Verified Creator status.