Skip to content

General Data Points

The General section evaluates the foundational configuration and health of a HubSpot portal. These 6 blocks apply to every HubSpot portal regardless of Hub subscriptions and cover the areas that impact all other sections.

The Portal Overview block captures the core configuration of the HubSpot account. These data points establish the baseline context for the entire audit and help identify fundamental setup issues.

Data points captured:

  • Account type — The HubSpot subscription tier (Free, Starter, Professional, Enterprise) and which Hubs are active. This determines which features and API endpoints are available for other blocks.
  • Timezone setting — The portal’s configured timezone. Incorrect timezone settings affect reporting accuracy, workflow scheduling, and email send times.
  • Default currency — The currency used for deals, quotes, and revenue reporting. Portals operating across multiple currencies should have the primary currency configured correctly.
  • Connected domains — All domains connected to the portal, including primary and secondary domains, redirect domains, and email sending domains. Missing or misconfigured domains affect content delivery and email deliverability.
  • HTTPS configuration — Whether SSL is properly configured across all connected domains. Non-HTTPS domains impact SEO rankings, browser security warnings, and user trust.
  • API usage — Current API call volume relative to HubSpot’s rate limits. High API usage indicates heavy integration activity and potential rate-limiting risks.

What good looks like: A well-configured portal has the correct timezone for its primary operating region, HTTPS enabled on all domains, at least one verified email sending domain, and API usage well below rate limits.

The Data Quality block measures the overall cleanliness and completeness of CRM data. Poor data quality undermines every other area of portal performance.

Data points captured:

  • Duplicate contacts — The number and percentage of contacts flagged as potential duplicates based on email address, name, and company matching. High duplicate rates inflate metrics and create inconsistent experiences.
  • Duplicate companies — Potential duplicate company records identified through domain and name matching.
  • Missing critical properties — Contacts and companies missing values for key standard properties (email, first name, last name, company name, lifecycle stage). Expressed as a percentage of total records.
  • Data completeness score — An aggregate measure of how fully populated records are across all standard and commonly-used custom properties. Calculated as the average fill rate across a weighted set of properties.
  • Invalid email addresses — Contacts with email addresses that have bounced, are malformed, or belong to known disposable email providers.
  • Stale records — Contacts and companies with no activity or updates in the past 12 months, indicating potentially outdated data that may need cleanup or re-engagement.

What good looks like: Duplicate rates below 5%, critical property fill rates above 80%, minimal invalid emails, and an active program for managing stale records.

The Property Management block evaluates how custom properties are organized, used, and maintained. Property sprawl is one of the most common issues in mature HubSpot portals.

Data points captured:

  • Custom property count — Total number of custom properties across all object types (contacts, companies, deals, tickets). Compared against benchmarks for the portal’s size and complexity.
  • Unused properties — Properties that have been created but contain no data or have not been referenced in any form, workflow, list, or report. These add clutter and confusion.
  • Property field groups — How properties are organized into groups. Well-organized groups make the CRM easier to navigate for sales and service teams.
  • Property usage distribution — The percentage of properties actively used in forms, workflows, lists, reports, and views. Low usage rates suggest over-provisioning.
  • Property naming conventions — Analysis of property naming patterns for consistency. Inconsistent naming (mixing camelCase, snake_case, spaces) indicates lack of governance.
  • Sensitive data properties — Properties that may contain sensitive or personally identifiable information without proper access controls.

What good looks like: A clean property schema with consistent naming, properties organized into logical groups, unused properties regularly audited and archived, and fewer than 20% of custom properties going unused.

The User Management block assesses team structure, permissions, and access patterns within the portal.

Data points captured:

  • Team member count — Total users with portal access, broken down by active and inactive status.
  • Role distribution — How users are distributed across roles (Super Admin, Admin, standard users, restricted users). An excessive number of Super Admins is a common security risk.
  • Permission sets — Custom permission sets in use and how they restrict or grant access to specific features and data.
  • Login activity — Last login dates for all users. Users who have not logged in for 90+ days may represent security risks or wasted seat licenses.
  • Inactive users — Users with portal access who show no login or activity, potentially indicating offboarded employees whose access was not revoked.
  • Team structure — How users are organized into HubSpot teams, which affects record visibility, assignment routing, and reporting.

What good looks like: Minimal Super Admin accounts (2-3 maximum), all users active within the past 90 days, clear team structures aligned to business functions, and no orphaned user accounts.

The Integration Health block examines the connected applications and data sync configurations.

Data points captured:

  • Connected integrations — Total number of active integrations, categorized by type (native, marketplace app, private app, API key).
  • Integration status — Health status of each integration: connected, disconnected, error state, or requiring reauthorization.
  • API usage by integration — API call volume broken down by integration, identifying which connections are consuming the most API capacity.
  • Sync status — For data sync integrations, whether sync is active, paused, or in an error state. Includes the last successful sync timestamp.
  • Deprecated integrations — Integrations using deprecated API versions or authentication methods (e.g., API keys instead of private apps).
  • Integration overlap — Multiple integrations that sync the same data types, which can cause conflicts and data inconsistencies.

What good looks like: All integrations in a healthy connected state, no deprecated authentication methods, API usage distributed without any single integration dominating capacity, and no conflicting data syncs.

The GDPR Compliance block evaluates privacy and data protection configurations. This is relevant for any portal that processes data from EU residents.

Data points captured:

  • Consent settings — Whether GDPR consent features are enabled and configured, including lawful basis tracking and consent types.
  • Privacy policy links — Whether forms and email communications include links to the organization’s privacy policy.
  • Cookie consent — Configuration of cookie consent banners on connected domains.
  • Data retention policies — Whether data retention settings are configured for contacts, companies, and other objects. Includes scheduled deletion rules.
  • Right to erasure process — Whether the portal has configured GDPR delete capabilities and whether they have been used.
  • Email subscription types — Configuration of subscription types that allow contacts to manage their communication preferences, supporting opt-in and opt-out compliance.

What good looks like: GDPR features enabled with lawful basis tracking, privacy policy linked in all forms and emails, cookie consent configured on all domains, and data retention policies set and active.