Content groups and catching decay

Per-page tables answer "how did this URL do." Two features that shipped recently answer the questions around that one: "how is this kind of page doing," and "which pages are quietly dying."

Content groups

A content group is a name and a path pattern — /blog/*, /docs/*, a locale prefix, whatever slices your site into meaningful chunks. For each group, the Content Groups screen shows views, unique visitors, average duration, bounce rate, that group's share of total site views, a comparison against the previous equal-length window, and a small daily trend. Click into a group and you get its distinct paths with the top ones ranked.

Two details make this less tedious than it sounds. First, a coverage summary: what percentage of the period's pageviews matched any group. If it says 40%, most of your traffic is invisible to group-level reporting and you know to add patterns. Second, suggestions: Tracely looks at the busiest first URL segments in your traffic — heavy traffic under /blog/… suggests a "Blog" group with pattern /blog/* — and offers one-click group creation. Segments that look like files, cover only a single page, or are already matched by an existing group get skipped, so the suggestions stay sensible.

Content decay alerts

Traffic to a page rarely fails loudly. It erodes — a ranking slips, an internal link disappears in a redesign, a referrer moves on — and nobody notices for a quarter because the site-wide chart still looks fine.

The content decay alert watches for exactly this. For every path, it compares the last 7 days of pageviews against the average of the three prior 7-day windows. You configure two things when creating the alert (it's a trigger type under Alerts, evaluated on the same hourly schedule as other alert webhooks):

• Drop % — how far below the trailing average the current week has to fall before it counts.
• Min. trailing views — a per-week noise floor. Paths that averaged fewer views than this across the trailing windows are ignored entirely, because a page going from 6 weekly views to 2 is not a story.

When something trips, the alert names the single worst offender, with the numbers attached: the path, roughly how far it dropped versus the trailing three-week average, last week's views, and the trailing weekly average. One concrete page with concrete numbers, not a wall of red — the point is to hand you something you can act on, and week-over-week baselines per path are only computable because Tracely keeps aggregate traffic per path over time. No individual-level data is involved.

Toward a publication desk

Both features point the same direction I flagged in the introduction post: treating the content workflow as a first-class citizen. Under the hood, pageviews can already carry a canonical content key, plus optional section and author — sent by the tracker or derived from path rules you configure per site, so /blog/2026/05/some-post and /blog/2026/05/some-post/ resolve to one piece of content. The content desk screen builds on that with editorial-style KPIs — engaged minutes, recirculation, breakdowns by story, section, and author.

Where this is heading is a proper publication desk: the screen an editor opens on Monday morning to see what's working, what's decaying, and what deserves a refresh — without anyone on the team needing to think in terms of paths and regexes. Content groups are the coarse version of that story; content keys and decay alerts are the fine-grained one. More on this as it ships.