Understanding Analytics Accounts, Properties, and Views

Learn the hierarchy of analytics organization. Understand when to create multiple accounts, properties, and views for your data structure.

Draft

What's the difference between an analytics account and a property? When do you create a new property instead of a new view? Why would you need multiple accounts if you own multiple websites? Most teams misunderstand this structure and end up either with one massive property mixing all their data or dozens of properties they can't manage. The right structure is invisible. Data flows to the right places. Reports show you what you need. Setup takes an hour and works for years.

This article explains the account-property-view hierarchy, when to use each level, and how to plan a structure that grows with your business.

The analytics hierarchy: accounts, properties, and views

Think of an account as your container. Everything you own lives in one account. The account holds authentication, permissions, and billing.

Properties are separate websites or apps inside your account. One website equals one property. Multiple websites equal multiple properties. A property is where data flows in.

Views are filtered versions of a property. One property can have multiple views. One view shows all traffic. Another view shows only desktop traffic. Another filters out internal employees.

The hierarchy is simple. One account can hold many properties. One property can hold many views. Most teams have one account, a few properties, and several views per property.

When to create a new account

Create a new account when you have completely separate businesses with separate owners and separate billing. If you own two e-commerce sites that are completely unrelated, separate accounts make sense. If you own a corporate website and a customer portal, they might need separate accounts.

But most cases don't need separate accounts. Keep things together if you want to see combined data later. You can't combine data across accounts. Separate accounts mean separate data silos.

The only common case for multiple accounts is separating production and testing. Your main account has real customer data. Your testing account has test data. This prevents accidental analysis of broken tracking.

When to create a new property

Create a new property for each separate website or app. If you have one website, one property. If you have a website and an app, two properties. If you have a main website and a help documentation site, two properties.

Don't create multiple properties for the same website. One website with multiple subdomains still uses one property. One website with multiple sections still uses one property. Only create a new property if you have a fundamentally different website or app.

Each property needs its own tracking code. The tracking code tells the analytics platform which property to send data to. If you install the wrong code, data goes to the wrong property.

When to create a new view

Create a new view when you want a different perspective on the same data. You want to see all traffic in one view. You want to see only paid traffic in another. You want to see only desktop traffic in another.

Views are filters on top of the same raw data. Creating a view doesn't change what data is collected. It just changes what you see. All views come from the same property.

Common views include all traffic, paid traffic only, organic traffic only, direct traffic only, desktop only, mobile only, and internal traffic excluded. Create views based on how your team analyzes data.

Internal traffic and filters

Create a view that excludes internal traffic. Your employees visiting the website, testing the site, previewing features. This traffic skews your data. You want to measure real visitor behavior, not your team testing.

Filter by IP address. Add your company's IP address to the internal traffic filter. All visits from that IP won't appear in the view.

Keep one view with all traffic including internal. Keep another view without internal traffic. The all-traffic view is your reference. The filtered view is for decision-making.

Testing and staging environments

Create a separate property for your staging or testing environment. Don't send test data to your production property. Test data breaks your real data.

When developers test the site, they test on a staging server with a different domain. That staging domain sends data to a different property. When you're ready to go live, you install the production property code.

This keeps test data completely separate. You can test without worrying about corrupting your real analytics.

User access and permissions

Set up user roles at the account and property level. Some users only need access to one property. Some users need access to all properties. Some users should only see reports, not modify tracking.

Account-level access gives someone permission to see all properties and account settings. Property-level access restricts them to one property. Editor access lets someone modify tracking. Viewer access only shows reports.

Separate production and testing access. Developers who modify tracking code should have access to the testing property, not production.

Frequently asked questions

We have one website with multiple subdomains. Do we need multiple properties or can we use one?

One property is fine. One property tracks all subdomains of the same domain. The tracking code identifies which subdomain the visit came from. You can analyze by subdomain in reports. You don't need separate properties unless the subdomains are completely separate websites with separate purposes. With WEMASY's website builder, you can set this up directly on your website.

We have production and staging sites. Should they use the same property or different properties?

Different properties. Staging data should never mix with production data. Create one property for production and one for staging. Developers test on staging with the staging property code. When you launch, you switch to the production code. This keeps test data and real data completely separate.

Should we filter internal traffic with views or by modifying the tracking code?

Filter with views, not tracking code. Don't try to prevent internal traffic from being collected. Collect everything. Filter in views. This way you have a view of all traffic for reference and a view of filtered traffic for analysis. Filtering at collection time is permanent. You can't un-exclude data later.

How many views does a typical property need?

Three to five is typical. One unfiltered view of all traffic. One view with internal traffic filtered. One view for paid traffic only. One view for organic traffic only. One view for mobile traffic. Create views that match how your team analyzes data. Don't create views you won't use.

Can we move data between properties or accounts?

No. Data stays in the property it was sent to. You can't move data once it's collected. You can export data for analysis in other tools. You can't reorganize it within analytics. Set up your property structure correctly from the beginning. Reorganizing means losing historical data or creating duplicate tracking.

We're adding a second website. Should we create a second property in the same account or a separate account?

Same account, separate property. Keep related websites in the same account. You can see combined reports and compare websites. If the websites are completely unrelated businesses with separate owners, separate accounts are fine. But most cases benefit from same-account, separate-property organization.

Put it to work
on your own website.

Start free with WEMASY and build your site in a few minutes.