What is your developer-dependent CMS actually costing you? Calculate your costs and get a full report
What is your developer-dependent CMS actually costing you? Calculate your costs and get a full report
Content Operations
Use the Google Analytics and PostHog apps, A/B/n testing and reports to see how content performs, and turn the numbers into editorial decisions.
Publishing is half the job. The other half is finding out whether the content did what it was for, and using that to decide what to write, fix or retire next. This article covers the analytics integrations documented for Agility, what each one shows you, and a simple routine for turning numbers into editorial decisions.
| Tool | What it shows | Where you see it | Who sets it up |
|---|---|---|---|
| Google Analytics app | Site-wide metrics from your GA4 property | The Agility dashboard | An administrator installs the app and connects your Google account |
| Google Analytics page sidebar | One page's active users, new users, page views, average engagement time and bounce rate, plus top traffic sources and a link into Google Analytics | Beside the page editor | Part of the Google Analytics app. See How We Built the Google Analytics Page Sidebar with Claude |
| PostHog app (Beta) | Page views, unique visitors, scroll depth, time on page, top pages, referrers and locales; per content item, impressions, scroll depth, time on page, CTA clicks and the pages using it | The Agility dashboard, the content item sidebar and the page sidebar | An administrator installs the app; your developers add tracking to your site |
| A/B/n testing | Which version of a component performs better | The PostHog panel on the component, and PostHog itself | Developers set up the component once; editors run experiments after that |
| Reports | What changed, who changed it, and what's waiting to publish | Reports | Available in Agility |
Reports tell you about your output: what you published. Analytics tell you about the outcome: what readers did with it. You need both.
The Google Analytics app brings your website metrics into the Agility dashboard. It supports GA4: when you install it, you sign in with Google and choose the property to show. If the app was installed before GA4, an administrator can reconfigure it in your instance settings to pick your GA4 property.
The page sidebar answers the question editors ask most: "is this page working?" Open a page and its numbers sit beside the editor, so you can check before you change anything.
The PostHog app (in beta) shows analytics in three places: a site-wide dashboard, a sidebar on content items, and a sidebar on pages. The content item sidebar is what makes it different: because it tracks content IDs, it can show how a piece of content performs across every page that uses it, not only how a page performs.
It depends on your site sending the right events to PostHog, so your developers set up the tracking first. The app currently works with PostHog US Cloud. See PostHog app for the details to pass to your developer.
With the PostHog app, you can test versions of a single component (a hero headline, a call to action, a pricing layout) against each other. Each version is a content item you manage in Agility. Once a developer has set up a testable component, starting a new experiment is a content task: you write the variants, then create the experiment from the PostHog panel on the component, which walks you through choosing a template (such as CTA optimization or content engagement), configuring it and reviewing it. Results appear in the same panel and in PostHog.
See A/B/n Testing in Agility CMS.
Every piece of content has a job: get sign-ups, answer a support question, rank for a topic, inform customers of a change. Write the job down when you plan the content, and pick the one or two numbers that would show it's working. For a help article, time on page and fewer support tickets; for a landing page, clicks on the call to action.
Named mistake: the vanity metric. Page views rise and everyone is pleased, but sign-ups don't move. Measure what the content is for.
A page linked from your home page will always get more traffic than one that isn't. Compare a page with its own past, or with similar pages, not with your most popular page.
Named mistake: comparing a launch week with a quiet week. Look at the same length of time, and allow for campaigns, seasons and holidays.
If you rewrite the headline, swap the image and move the button in one go, you won't know which change made the difference. An A/B/n test makes this explicit; even without one, change one element and wait.
Named mistake: stopping a test early. A variant that looks like it's winning on day two often isn't. Let the test run until it has enough data, as the A/B/n testing guide explains.
Before you change content to improve a number, write what you expect to happen and why. It keeps the review honest and builds a record of what works for your audience.
A number nobody acts on is just a number. Each review should end with decisions:
