A Practical Guide to Web Analytics Terms

Standard reports tell you about pages, referrers, devices, countries, campaigns, and conversions. Custom dimensions add the context only your business knows: plan tier, author, content type, experiment variant.

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 creates 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.

Frequently Asked Questions

What is a custom dimension in analytics?

A custom dimension is a label your business adds to an event, such as plan tier, author, or experiment variant. It answers "what kind," while a metric answers "how many." Standard reports already cover pages, referrers, devices, countries, campaigns, and conversions. Custom dimensions add the context only your business knows.

What is the difference between a dimension and a metric?

A dimension is descriptive and answers "what kind," like source, country, page path, or plan tier. A metric is numeric and answers "how many" or "how much," like page views, conversions, or revenue. Custom dimensions matter because they let you group those metrics by business-specific labels.

Are custom dimensions the same as custom properties?

Custom dimensions and custom properties are the same idea under two names, both attach business context to an event without identifying the person. The summary of this guide uses the terms interchangeably. Which one you hear depends on the analytics platform, not on any real difference in function.

Can custom dimensions include personal data?

Custom dimensions should not carry personal data. The bad-use list rules out email addresses, names, phone numbers, full IP addresses, raw account IDs, and search queries that may contain personal data. Google's HIPAA and Analytics guidance says the same thing: do not send anything that could identify a user or reveal sensitive information.

How many custom dimensions should a site use?

Start with five to ten high-value dimensions and expand only when a repeated question cannot be answered otherwise. Letting every team invent its own fields is exactly what makes reports noisy.

What is a high-cardinality dimension?

A dimension with thousands of unique values, hard to report on and a possible privacy risk. Page path is expected to behave this way. Author or content type should not, since a jump in unique values usually means free text slipped into the field.

Why do custom dimension values need to be lowercase and enumerated?

Because a dimension is only useful if its values stay consistent. Lowercase slugs and enumerated values, such as content_type = guide, comparison, tutorial, announcement, keep filters and reports predictable. Mixing singular and plural values or free text breaks that consistency and fragments the data.

How should A/B test results be tracked with custom dimensions?

When the server assigns a variant, send experiment_name and variant on both the exposure and the conversion event. That server-side approach avoids client-side flicker and third-party testing scripts, and lets you compare conversion rates directly.

What questions should a team ask before adding a new custom dimension?

Five: does the value identify a person or household, could it become sensitive combined with the page URL, and is it needed for a real decision. The remaining two ask how long it should be retained and whether it would be fine in a vendor export or dashboard screenshot. If any answer feels uncomfortable, keep that detail in first-party systems with proper access controls instead.

What is an event dictionary and why keep one?

A short document kept beside the analytics setup that lists each custom dimension, its allowed values, an owner, an example event, and a privacy note. Reviewing it before every campaign or launch prevents duplicate fields, accidental personal data, and dashboards nobody can interpret months later.