How to Group Dynamic SaaS URLs into Product Pages and Features

Separate page levels before normalizing dynamic segments

A route such as /companies/128/reports/451?tab=history can produce one row per record, fragment adoption analysis, and expose unsafe values. The solution is not to discard the URL or collapse everything called Settings. Build a deterministic classification chain whose levels answer different questions.

“Raw” should never mean every character the browser exposed. Filter tokens, email addresses, customer-entered names, confidential search terms, and other prohibited values before analytics persistence, rule-preview logs, errors, exports, or replay metadata. Retain only the most detailed evidence the organization has intentionally judged safe and necessary.

Strong dynamic-segment clues include framework-declared parameters, database-style numeric IDs, UUIDs, ULIDs, hashes, timestamps, opaque tokens, and known tenant or object positions. Human-readable slugs are ambiguous: /teams/design may contain a team identifier, while /settings/design may be a stable product route. Locale, deployment prefix, API version, action suffix, and tenant subdomain can also carry deliberate meaning.

Use route position and application semantics, not shape alone. Normalize only the dynamic value, preserve stable action segments such as edit, and watch normalized-route cardinality. A sudden increase can reveal a missed identifier; a dramatic decrease can reveal an over-broad rule. The goal is a stable, useful taxonomy, not the smallest possible page count.

Prefer route contracts and track logical navigation

Modern routers already know which segments are parameters. Prefer an explicit application route name, matched router record, file-system route ID, or server endpoint template over inference from the final URL. Framework syntax differs, but all can map to one internal contract:

/companies/:companyId/reports/:reportId
/projects/[projectId]/tasks/[taskId]
/users/{user_id}/settings

{
  "navigation_id": "nav_01J8EXAMPLE",
  "safe_observed_path": "/companies/128/reports/451",
  "route_template": "/companies/:companyId/reports/:reportId",
  "route_name": "report.details",
  "safe_page_state": { "tab": "history" }
}

This payload is conceptual, not a Hymetry API contract. The stable name/template identifies the route, the safe path supports evidence and QA, and reviewed state remains separate so it does not multiply route identity.

Classify query and fragment state by meaning

For /reports/451?tab=history, the route can remain /reports/:report_id while tab=history becomes safe state. Create a separate grouped page only when History is a substantial task with its own adoption question. A token has no such option:

Observed by browser: /reports/451?token=secret-value
Privacy-safe route: /reports/451
Normalized route: /reports/:report_id
Grouped page: Report details
Product area: Reporting

In a single-page application, a document may load once while logical routes change repeatedly. Account for initial load, router commits, history.pushState(), history.replaceState(), Back/Forward popstate, redirects, and hash routing where relevant. Calling pushState() or replaceState() does not itself fire popstate, so a listener limited to that event can miss forward navigation.

Choose one primary source and deduplicate notifications for the same committed navigation. Automatic history tracking plus manual router calls is a common duplicate source. Renders, title updates, data refreshes, and minor state changes are not new pages.

function onNavigationCommitted(navigation) {
  const safe = privacyFilter(navigation.url);
  const page = classifyPage({
    safeUrl: safe.url,
    routeName: navigation.routeName,
    routeTemplate: navigation.routeTemplate
  });

  analytics.recordPageView({
    navigationId: navigation.id,
    normalizedPage: page.normalizedPage,
    groupedPageId: page.groupedPageId,
    productAreaId: page.productAreaId
  });
}

This is framework-neutral pseudocode. Use the router and analytics tool’s supported APIs. A URL-changing modal, drawer, or tab can be page-like if it is addressable, supports Back, represents a distinct task, and belongs in flow analysis. Lightweight confirmation UI is usually an event.

Design grouping rules as a versioned classification system

A grouping rule changes the analytical data model. Give it a stable rule ID, project/environment scope, match type and pattern, priority, normalized route, durable grouped-page ID, product-area ID, active status, source, owner, review state, timestamps, effective dates, and definition version. Keep stable IDs separate from editable labels.

Report all overlapping matches in preview, even when priority chooses a winner. Broad patterns can silently steal routes after a product release. Anchor regexes, avoid catastrophic expressions, and treat tie-breaking as a visible conflict. A conceptual rule can look like this:

{
  "rule_id": "page_rule_report_details",
  "match_type": "route_template",
  "match_pattern": "/companies/:company_id/reports/:report_id",
  "priority": 300,
  "normalized_route": "/companies/:company_id/reports/:report_id",
  "grouped_page_id": "report_details",
  "product_area_id": "reporting",
  "version": 3,
  "effective_from": "2026-08-04"
}

AI can suggest ID-like segments, route names, or candidate groups, but cannot infer the intended taxonomy reliably from strings alone. Present suggestions with samples, frequency, proposed pattern, confidence explanation, and conflicts. A person who understands the product should approve the mapping and its historical effect.

Worked example: collapse dynamic routes without losing evidence

Twelve record-specific observations can collapse into a much smaller set of stable routes and grouped pages while their visits remain countable and traceable. The normalized layer supports engineering QA; grouped pages support questions such as which accounts reached Report details; product areas support Reporting adoption breadth. Do not use a grouped-page visit as proof that the workflow completed.

Protect URL data and preserve historical comparability

URLs may expose authorization codes, reset tokens, emails, customer names, search text, document names, support details, file paths, or secrets. HTTPS protects transit; it does not prevent values appearing in browser history, referrers, proxy logs, analytics fields, or debugging systems. Filter at or before collection wherever possible.

A spelling correction can keep the same stable ID. Splitting generic Settings into Billing, Permissions, and API Keys changes analytical meaning. Choose deliberately among query-time classification, effective-dated rules, ingestion-time materialization, full reprocessing, or preserving both original and current classifications. No choice is universally correct; the report must disclose which view it uses.

For a migration, snapshot rule versions and affected route samples, run current and proposed classifiers side by side, compare page and area counts, inspect the largest movers, and approve the effective date. Publish a change note that says whether downstream funnels, adoption rates, and saved segments were backfilled. Keep old stable IDs as aliases when the product meaning is unchanged; create new IDs for real splits and merges.

Test route classification like production code

Maintain fixtures for exact, numeric-ID, UUID, slug, locale, query, fragment, nested, SPA, overlapping, missing, sensitive, renamed, and account-switch routes. Run them when router behavior, rules, or product taxonomy changes.

Before activation, preview the safe sample, winner, losing matches, normalized route, grouped page, area, conflicts, unmatched examples, and current-versus-proposed classification. After activation monitor unclassified rate, overlap rate, normalized-route cardinality, new routes, privacy-filter detections, page-view volume, and duplicate navigation IDs. Roll back a rule that causes unexpected taxonomy movement.

Route-change release checklist

• Confirm the router emits the expected name/template in production builds and across locales.
• Verify initial load, client navigation, redirects, Back/Forward, account switch, and authentication transitions.
• Exercise query defaults, repeated parameters, encoded values, fragments, and trailing-slash policy.
• Check that safe state remains bounded and that prohibited values disappear before all persistence paths.
• Compare page-view counts with navigation IDs to detect both loss and duplication.
• Review downstream grouped-page and product-area metrics for unexpected movement.
• Assign the release, rule, taxonomy, and privacy owners and a rollback threshold.

Keep an unclassified queue small enough to review but never expose unsafe values in it. Sample the privacy-filtered pattern, frequency, first/last seen date, application version, and candidate route metadata. Repeated unknown routes may indicate a new feature; a one-off value may indicate noise or a failed filter. Classification should fail conservatively.

Reconcile product meaning after deployment

• Product owners confirm that stable grouped-page IDs still describe customer tasks.
• Engineers verify that route metadata survives code splitting and redirects.
• Analysts check adoption and flow continuity.
• Privacy owners review newly observed fields.
• The team schedules periodic rule review because fixtures cannot reveal every new production route family or value.

When several applications share an analytics project, scope route contracts and rule precedence explicitly. The same /settings path can mean different products, environments, or embedded modules. Include application or project identity before classification instead of relying on broad prefixes that become ambiguous over time.

Connect grouped pages to account evidence

Hymetry’s Pages surface connects stable product structure with Companies, Users, and Visits. Teams can inspect the Pages demo, privacy controls, and the open-source repository. The product taxonomy still requires deliberate naming, ownership, and validation.

Frequently asked questions

Sources

Method note: Standards and framework documentation support route syntax and navigation behavior. Security guidance supports minimization. The internal taxonomy and worked routes remain implementation decisions.