Sharing BigQuery Data with Analytics Hub

Analytics Hub is the BigQuery (opens in a new tab) sharing capability for sharing data and insights at scale across organizational boundaries. Analytics Hub is part of data governance and sharing in Google Cloud, which manages the end-to-end data lifecycle and makes data and AI assets easier to discover, govern, and share. Sharing operates under a security and privacy framework with unified metadata and governance and security policies, and providers manage sharing through the Analytics Hub API.

1.1Data Exchanges in Analytics Hub

A data exchange in Analytics Hub is a provider-side sharing resource created through the Analytics Hub API. The exchange defines the boundary where data is offered across projects and organizations. Published data stays queryable through BigQuery alongside internal data, so subscribers use the same BigQuery experience without moving data into a separate sharing system.

1.2Listings in Analytics Hub

A listing in Analytics Hub is the sharing resource that describes a specific shared data asset inside an exchange. The listing is created with the data exchange through the Analytics Hub API and controls how the asset is presented, discovered, and requested. Subscribers discover the listing in the exchange and then work with the shared asset in BigQuery, where discovery, querying, and governance follow BigQuery rules.

1.3Secure Collaboration and Governance in Analytics Hub

Secure collaboration in Analytics Hub depends on BigQuery unified governance with unified metadata and governance and security policies. The security and privacy framework applies across organizational boundaries, so access stays controlled while discovery and use remain at scale. Support for lakehouse data in BigQuery (opens in a new tab) depends on which catalog manages the table: Apache Iceberg tables managed by BigQuery store data in Cloud Storage with BigQuery as the catalog and can be shared, while Apache Iceberg tables managed by the Lakehouse runtime catalog cannot.

Evaluating data sharing policies is the process of deciding when sharing through Analytics Hub is appropriate and safe. Analytics Hub is Google Cloud's service for exchanging BigQuery (opens in a new tab) data between providers and subscribers without moving copies of the data. A good policy weighs data sensitivity, regulatory requirements, target audience, and business value before a dataset is published as a listing.

2.1Zero-Copy Sharing in Analytics Hub

Zero-copy sharing in Analytics Hub lets subscribers query shared data directly where it lives without creating a separate copy. Data flows from the provider's source dataset through a listing to each subscriber's project, while the provider project keeps ownership and control of the source. Because no data is duplicated, updates appear immediately for subscribers and the provider can revoke access in one place.

2.2Sensitivity and Regulatory Checks Before Sharing

Sensitivity and regulatory checks confirm that a dataset is legally and ethically safe to share. Highly sensitive data, such as personally identifiable information (PII), financial records, or health data, should not be shared in raw form. Techniques such as masking, encryption, and replacement with generated values can de-identify sensitive fields where applicable and compliant, and data subject to regional or industry rules should only be shared when location, retention, and permitted use meet those rules.

Evaluate every candidate dataset against these policy factors:

• Data sensitivity: what identifiers or confidential attributes the data contains and whether it has been de-identified
• Regulatory requirements: what privacy, residency, and retention rules apply to the data
• Target audience: who needs the data and whether they are internal teams, trusted partners, or public users
• Business value: what decision, product, or collaboration the sharing enables compared to its risk

2.3Matching Audience and Business Value

Matching audience and business value means sharing data only with people who need it and gain clear benefit from it. Internal teams may need detailed operational data for dashboards and analysis, while external partners may only need aggregated or curated results. Public or broad sharing fits non-sensitive reference data, such as indexed public datasets that users pay only to query. When the audience is narrow and the risk is high, keep the data private or share a limited, purpose-built view instead of the full table.

2.4Secure Sharing Through Listings

A listing in Analytics Hub is the controlled way to make an approved dataset available for secure collaboration. The provider manages discovery and subscription on the listing, which keeps the provider's project and storage separate from the subscriber's queries and costs. Choose to publish a listing only after sensitivity, compliance, audience, and value all support sharing, so collaboration happens without losing governance.

Analyzing criteria for data sharing means checking sensitivity, audience need, compliance, and platform readiness before sharing through Analytics Hub. Analytics Hub is the sharing path that lets a provider make BigQuery (opens in a new tab) data discoverable and queryable by other teams without copying files between projects. Sharing is the right choice only when the data is classified as shareable, protected if needed, useful for analysis in BigQuery, and allowed by location and permission rules.

3.1Data Sensitivity and Protection Needs

Data sensitivity determines whether data can be shared as-is, must be protected first, or must not be shared. Sensitive Data Protection provides de-identification that masks, encrypts, and replaces sensitive data like PII using a randomly generated or pre-determined key, where applicable and compliant. Data flows from the source system to protection processing and then to the sharing layer, so the shared output depends on classification happening first. When sensitive fields are present, the team must apply masking or de-identification before creating a share, and if the audience does not need sensitive fields, those fields should be removed rather than shared.

The same rule appears in sensitive source systems such as HubSpot (opens in a new tab), where a private app needs extra scopes to transfer sensitive objects, including:

• crm.objects.contacts.sensitive.read for sensitive contact data
• crm.objects.companies.sensitive.read for sensitive company data
• crm.objects.deals.sensitive.read for sensitive deal data
• crm.objects.appointments.sensitive.read for sensitive appointment data
• crm.objects.custom.sensitive.read for sensitive custom-object data
• crm.objects.projects.sensitive.read for sensitive project data
• tickets.sensitive for sensitive ticket data

3.2Audience Fit and Analytical Need in BigQuery

Audience fit means sharing when consumers need to explore, join, or analyze the data inside BigQuery. BigQuery supports several analytical workflows that create that need, and a share makes sense when the audience will use one or more of them directly on the shared live data rather than on a one-time file export:

• Ad hoc analysis with GoogleSQL in the console or third-party tools
• Business intelligence dashboards and reports with BigQuery BI Engine
• Machine learning with BigQuery ML using SQL queries
• Geospatial analysis with geography data types and functions
• Graph analysis with BigQuery Graph for hidden relationships
• Search over unstructured text or semi-structured JSON data

A practical example is blockchain analysis, where on-chain blocks, transactions, logs, and call traces are made available in BigQuery so teams can join on-chain data with application data for a complete view of users and the business. Cross-cloud audiences add another fit check, because BigQuery Omni provides compute that runs locally to storage on AWS or Azure and lets teams query data stored in Amazon Simple Storage Service (Amazon S3) or Azure Blob Storage to break down data silos.

3.3Compliance, Location, and Platform Readiness

Compliance and platform readiness decide whether an Analytics Hub share is allowed and technically supported. Location is a hard boundary, because data stored in the US multi-region must stay in us (multiple regions in United States) and data stored in the EU multi-region must stay in eu (multiple regions in European Union). Permissions are a second boundary, because the service account or user that publishes and manages the share must hold the correct roles, such as BigQuery Job User and BigQuery Data Editor for BigQuery destinations. Organizational policy sits above both, and it defines who may approve sharing, which classifications may leave the project, and which roles are required.

Table type also controls readiness for Apache Iceberg tables:

The table shows that governance travels with the catalog that manages the table. A Lakehouse runtime catalog table depends on the Lakehouse runtime for management, while a BigQuery-managed table depends on BigQuery for column-level controls, masking, and sharing. Share through Analytics Hub only after confirming the source table type supports Analytics Hub integration and the required controls are available.

Key Facts

• Analytics Hub enables zero-copy sharing where subscribers query the provider's BigQuery source dataset through a listing without creating a separate copy.
• A data exchange in Analytics Hub is the provider-side boundary for offering data, while a listing describes the specific shared asset that subscribers discover and request.
• Highly sensitive data such as PII, financial records, or health data must be de-identified with masking, encryption, or replacement before sharing, or kept private when protection cannot meet regulatory requirements.
• Data stored in the US multi-region must stay in us (multiple regions in United States) and data stored in the EU multi-region must stay in eu (multiple regions in European Union).
• Analytics Hub integration is Supported for Apache Iceberg tables managed by BigQuery and Not supported for Apache Iceberg tables managed by the Lakehouse runtime catalog.