A Practical Guide to web analytics terms

This guide explains web analytics terms in practical terms, with a focus on privacy-first analytics decisions.

This is the glossary and concepts page for custom dimensions. For implementation steps, schema governance, and launch QA, use the complete setup guide.

Default analytics reports tell you pages, referrers, devices, countries, campaigns, and conversions. Custom dimensions add the context that only your business knows.

A page-view event might say someone visited /blog/cookieless-analytics. A custom dimension can add that the page category is privacy, the author is flowsery-team, the template is longform-guide, and the intended funnel stage is awareness. A signup event can include plan_tier, experiment_variant, or workspace_type without identifying the person.

Dimension vs Metric

A dimension is descriptive. It answers "what kind?" Examples: source, country, page path, content category, plan tier, button location.

A metric is numeric. It answers "how many?" or "how much?" Examples: page views, conversions, revenue, duration, scroll depth, count of events.

Custom dimensions are useful because they let you group metrics by business-specific labels. For example:

Good Uses for Custom Dimensions

Content strategy

Add dimensions such as content_type, topic_cluster, author, funnel_stage, or update_status. You can then compare not just individual URLs, but groups of pages.

This is useful when a single page has low traffic but a topic cluster has enough data to evaluate.

Campaign analysis

UTM parameters describe the link that brought a visitor in. Custom dimensions can add internal context after the visitor arrives: landing_page_type, offer_type, audience_segment, or creative_family.

Product-led funnels

For signup or onboarding events, custom dimensions can describe non-sensitive context: selected_plan, onboarding_path, template_chosen, or feature_category. Avoid user IDs, company names, emails, or anything that directly identifies a person unless you have a clear product analytics basis and the tool is designed for it.

A/B testing

Custom dimensions are ideal for server-side A/B testing. When the server assigns a variant, send experiment_name and variant on exposure and conversion events. That lets you compare conversion rates without client-side flicker or third-party testing scripts.

Bad Uses for Custom Dimensions

Do not use custom dimensions as a dumping ground. Bad examples include:

• Email addresses.
• Names.
• Phone numbers.
• Full IP addresses.
• Raw account IDs.
• Search queries that may contain personal data.
• Form answers.
• Medical, financial, or employment details.
• Full URLs containing tokens or reset links.

Google warns Analytics customers not to send data Google could recognize as personally identifiable information and not to send data that reveals sensitive information about a user in its HIPAA and Google Analytics guidance. That rule is useful even if you do not use Google Analytics: analytics tools should not receive personal data they do not need.

Naming Rules That Prevent Mess

A custom dimension is only useful if the values are consistent. Create a naming spec before implementation.

Use:

• Lowercase values.
• Stable slugs instead of display names.
• Enumerated values where possible.
• One meaning per dimension.
• Short values that are easy to filter.

Avoid:

• Mixing singular and plural values.
• Free-text values.
• Values generated from user input.
• Changing a dimension's meaning over time.
• Encoding several fields into one value.

For example, use content_type = guide, comparison, tutorial, announcement. Do not use content_type = "Long helpful GDPR article for EU marketers".

Privacy Review Before Shipping

Before adding a custom dimension, ask five questions:

1. Does this value identify a person or household?
2. Could this value become sensitive when combined with the page URL?
3. Is it needed for a real decision?
4. How long should it be retained?
5. Would it be acceptable in a vendor export or dashboard screenshot?

If the answer feels uncomfortable, do not send it to website analytics. Keep sensitive detail in your first-party systems with proper access controls.

Implementation Pattern

A clean event design separates event name, default fields, and custom dimensions:

Event: form_submitted
Default context: page, referrer, campaign, device
Custom dimensions:
- form_type = demo
- page_template = comparison
- funnel_stage = consideration
- experiment_variant = pricing_b

That is enough to answer practical questions without collecting form contents.

Common Mistakes

Too many dimensions

If every team invents fields, reports become noisy. Start with 5-10 high-value dimensions and expand only when a repeated question cannot be answered.

High-cardinality values

A dimension with thousands of unique values is hard to report on and may create privacy risk. Page path is expected to be high-cardinality; author or content type should not be.

Unregistered fields

Some platforms require custom dimensions to be registered before they appear in reports. Document the setup and test before a campaign launch.

Sending internal identifiers

Even pseudonymous IDs can be personal data if they single out a user. Do not send account IDs to public website analytics unless the processing has been reviewed.

A Practical Starter Set

For a privacy-first marketing site, start with:

• content_type
• topic_cluster
• funnel_stage
• author
• landing_page_template
• form_type
• cta_location
• experiment_name
• experiment_variant
• customer_segment, only if broad and non-identifying

Custom dimensions make analytics more useful because they connect behavior to business context. The discipline is to add context without adding surveillance.

Governance Tip

Maintain a short event dictionary beside your analytics setup. Include each custom dimension, allowed values, owner, example event, and privacy note. Review it before every campaign or product launch. This tiny habit prevents duplicate fields, accidental personal data, and dashboards nobody can interpret six months later.

Quick Glossary Recap

Custom dimensions are labels. Metrics are numbers. Events are actions. Properties or parameters are the fields attached to those actions. A clean analytics setup keeps those concepts separate:

• Event: demo_requested
• Metric: count of demo requests
• Default dimension: source or landing page
• Custom dimension: page_template, funnel_stage, or plan_tier

Use custom dimensions to group behavior into useful business categories. Do not use them to smuggle personal data into analytics under a more technical name.