managing-path-cleaning-rules

Proposes, tests, orders, and applies regex-based path cleaning rules for PostHog web analytics.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill managing-path-cleaning-rules
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: managing-path-cleaning-rules
Source: https://github.com/PostHog/posthog-foss/tree/main/products/web_analytics/skills/managing-path-cleaning-rules
Command: npx skills add https://github.com/PostHog/posthog-foss --skill managing-path-cleaning-rules

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Web analytics and Paths breakdowns get fragmented across thousands of near-identical URLs like /users/123 and /users/456, making reports unreadable. This Skill collapses dynamic URL segments (numeric IDs, UUIDs, slugs, dates) into readable aliases so pages sharing a template appear as one row.

Core Features & Use Cases

  • Path inspection: Queries real $pathname values via the execute-sql MCP tool to identify numeric IDs, UUIDs, slugs, dates, locales, and pagination segments that need cleaning.
  • Rule authoring and testing: Writes re2 regex + alias rules with angle-bracket placeholders, validates them with the settings page tester or HogQL replaceRegexpAll before saving.
  • Ordered application via MCP: Applies rules with the path-cleaning-rules-update tool using granular append/insert/replace/remove/reorder operations, with preview-before-confirm and sample path rewriting.
  • Use Case: A Paths insight shows 5,000 distinct URLs like /posts/some-slug. Use this Skill to add a rule mapping /posts/[a-z0-9-]+$ to /posts/<slug>, collapsing them into one row.

Quick Start

Clean up my web analytics paths by grouping URLs like /users/123 and /users/456 into a single /users/<id> entry.

Frequently Asked Questions about managing-path-cleaning-rules

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I group similar URLs in PostHog web analytics?

Add path cleaning rules that map dynamic URL segments to aliases, such as regex /users/\d+/profile with alias /users/<id>/profile. Rules are stored per project in path_cleaning_filters and applied when the Path cleaning toggle is enabled in Web analytics or Paths insights.

How do I test path cleaning regex rules before saving them?

Use the built-in test path input at /settings/project#path_cleaning, which replays the full ordered rule chain. Alternatively, run replaceRegexpAll in a HogQL query via the execute-sql MCP tool to verify a single rule or chained rules against sample paths.

What regex syntax do PostHog path cleaning rules use?

Rules use re2 syntax, which does not require escaping forward slashes and is case-sensitive by default. Use (?i) for case-insensitive matching, anchor with ^ and $ to avoid unintended mid-path matches, and prefer fixed aliases over backreferences for better performance.

Why does rule ordering matter in path cleaning?

Rules apply sequentially in ascending order, with each rule's output feeding the next. A generic rule placed first can swallow paths meant for a specific rule, so order rules from most-specific to most-general, with catch-all patterns last.

When should I use a property filter instead of path cleaning rules?

Use a $pathname property filter when you want per-URL drill-down data for specific pages. Path cleaning is for reducing cardinality when a breakdown is fragmented across thousands of near-identical URLs and you want them grouped into template rows.

Do path cleaning rules affect historical analytics data?

Yes, rules apply globally per project, not per insight, so adding a rule changes numbers in every Web analytics and Paths chart with cleaning enabled, including historical data. Preview changes with sample paths and warn users before applying destructive rules.