# Warehouse Audiences: Activate Customer Data in Google Ads, Meta and HubSpot

Canonical URL: https://www.martechdevs.com/blog/warehouse-audiences

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder, martechdevs

Published: 2026-07-17

Last updated: 2026-10-13

An audience sync can succeed while the campaign fails its basic purpose. Paying customers keep seeing trial offers. People who withdrew permission remain in a list. A high-value seed contains customers who spent heavily once and then refunded everything. Useful audience activation starts with a decision about who belongs, why they belong and exactly when they should leave.

## Choose the action before building the audience

A warehouse audience is a reproducible set of people or accounts selected from business data. Activation takes that selection into a destination where someone can act on it: advertising, lifecycle messaging or a sales workflow. For a partner who needs analytical access to an approved dataset, the [Snowflake data sharing guide](https://www.martechdevs.com/blog/snowflake-data-sharing) covers reporting shares, recipient permissions and offboarding.

Those destinations have different identities and different rules. A company in your warehouse is not an email address that Google can match. A HubSpot contact ID is useful inside one HubSpot account, but it is not a universal advertising identifier. Resolve those relationships before promising that one SQL query will work everywhere. Our [startup identity resolution guide](https://www.martechdevs.com/blog/identity-resolution-startups) explains that groundwork.

Start with a small set of audiences where the intervention is clear.

### Trial users who have not reached their first useful outcome

Define the activation milestone and the time window. For a product where a useful first result normally takes several days, an initial hypothesis might be trial age seven through fourteen days, no activation, no paid subscription and no unresolved blocking support issue.

The message should help with that missing outcome. Someone stuck connecting a data source needs connection guidance or assistance. A generic discount ignores the problem and can reward people who would have paid anyway.

Exit on activation, payment, expiry of the window or loss of permission. Choose the window from your actual journey data; seven days is an example, not a SaaS standard.

### Customers whose economics you want more of

Build a seed around observed contribution and retention, with a comparable observation period. Ninety-day gross margin after refunds is a more explicit definition than a field called `high_ltv` that nobody owns.

Keep recent customers separate from customers with a full ninety-day history. Otherwise tenure does the selecting for you. Exclude fraud, employees, test accounts and unprofitable exceptional orders. Treat predicted lifetime value as a model estimate with a version and evaluation date.

A good seed describes the commercial outcome you want. It does not prove that an advertising platform can find more of those customers profitably. Test that proposition separately.

### Former customers with a credible reason to return

Segment by the reason they left and the relevant change since then. A missing integration that now exists gives you a concrete message. An unresolved service failure calls for customer recovery work before an automated win-back campaign.

Distinguish voluntary cancellation from failed payment. Do not send a discount sequence to someone whose account is already in a payment recovery workflow. Exclude reactivated customers promptly and set a cooldown after the last attempt.

For all three audiences, name the owner, intervention, success event, exit conditions and destination. If those fields are vague, building the sync is premature.

## Separate business eligibility from permission and addressability

Maintain three decisions rather than one overloaded audience flag:

1. **Business eligibility:** does this person satisfy the journey definition?
2. **Destination permission:** may this data be used for this purpose in this destination now?
3. **Addressability:** do you have a supported, usable identifier for that destination?

Permission should come from your approved policy and recorded preferences. A SQL developer should not infer advertising permission from an email address being present. Unknown permission should not silently become permission granted.

Google's [Customer Match policy](https://support.google.com/adspolicy/answer/6299717?hl=en) permits customer information collected in a first-party context and requires the applicable disclosures and consent. Buying a prospect list does not make it eligible because you loaded it into Snowflake. Meta's [Customer List Custom Audiences terms](https://www.facebook.com/legal/terms/customaudience/update) also require the necessary rights and permissions, and removal when someone exercises an applicable opt-out.

Keep the permission evidence and policy version internally. Send the destination's required signals accurately; accepting platform terms is not a substitute for a customer's permission. Avoid exporting sensitive attributes simply because they improve a model's predictive power.

![Business eligibility passes through destination permission and usable identifiers into a validated snapshot, additions and removals, destination processing and campaign outcomes.](https://www.martechdevs.com/assets/blog/warehouse-audiences.svg)

## Build a snapshot that explains its own membership

Create one reviewed audience model and separate destination outputs. That keeps the business definition consistent while preserving channel-specific permission and identifier requirements.

Here is an illustrative selection query. Its input contains one current row per person for a business with one relevant trial account per person. If people belong to multiple accounts, define eligibility at the membership or account level first; do not let an inactive secondary account override a paid primary relationship.

The boolean fields must be populated from validated source data. `trial_age_days` uses a documented UTC calendar-day definition. Identifier flags mean a usable destination key exists, not that a match has been confirmed.

```sql
WITH eligible AS (
    SELECT *
    FROM audience_person_snapshot
    WHERE snapshot_date = DATE '2026-10-13'
      AND trial_age_days BETWEEN 7 AND 14
      AND has_activated IS FALSE
      AND is_paying IS FALSE
      AND is_deleted IS FALSE
      AND has_blocking_issue IS FALSE
)
SELECT person_id, 'google_ads' AS destination
FROM eligible
WHERE google_ads_allowed IS TRUE
  AND has_google_match_key IS TRUE

UNION ALL

SELECT person_id, 'meta_ads' AS destination
FROM eligible
WHERE meta_ads_allowed IS TRUE
  AND has_meta_match_key IS TRUE

UNION ALL

SELECT person_id, 'hubspot_email' AS destination
FROM eligible
WHERE hubspot_email_allowed IS TRUE
  AND hubspot_contact_id IS NOT NULL;
```

This produces internal membership keys. It deliberately leaves contact details out of the result. A controlled destination mapping step retrieves only the identifiers needed for the approved use. The HubSpot branch represents an email journey; an internal sales task would need its own eligibility and permission definition.

Before exporting, assert uniqueness of `(person_id, destination)`, completeness of the source snapshot and freshness of billing, product and permission inputs. A missing billing load must not turn a paying customer into a trial user. Null state fields fail the explicit boolean checks, but completeness checks are still necessary: missing rows can look like legitimate audience exits.

Keep the snapshot time, rule version, member count and exclusion counts. Store a useful reason for each exclusion, such as already paid, activation completed, missing identifier or permission unavailable. That makes a shrinking audience explainable without browsing personal data in job logs.

## Send Google audiences through the appropriate current route

### Built-in BigQuery or Snowflake connection

Google Ads supports a [direct BigQuery connection](https://support.google.com/google-ads/answer/13763054?hl=en) for Customer Match. Select the prepared project, dataset and table, map the fields and create the customer list. Authorized views have additional requirements, including restrictions on external-table sources. Review the documented permission grants before connecting a broad dataset; a dedicated activation dataset makes that review easier.

The [Snowflake connector](https://support.google.com/google-ads-data-manager/answer/14186945?hl=en) currently uses an account identifier, username and programmatic access token. Use an account role restricted to the approved activation data. Follow the connector's current network requirements and manage token rotation. A generic password-based tutorial is not the current setup guide.

These native connections can be a sensible first implementation when Google is your only destination and daily updates meet the business requirement. They do not remove the need to validate audience membership or campaign settings.

### API or managed activation tool

For most new Customer Match integrations, Google requires the Data Manager API as of 1 April 2026. Existing eligible Google Ads API integrations can continue. Do not start a new build by copying an old `OfflineUserDataJobService` tutorial without checking eligibility. See Google's [current migration notice](https://developers.google.com/google-ads/api/docs/remarketing/audience-segments/customer-match/manage?hl=en).

Use a managed activation tool when shared monitoring, multiple destinations, retry handling and membership changes justify its cost. Use a custom integration when you have a specific requirement and an owner for its ongoing operation. Our [reverse ETL guide](https://www.martechdevs.com/blog/reverse-etl) covers those implementation responsibilities.

With the Data Manager API, a returned request ID is the beginning of verification. Google's [results guide](https://developers.google.com/data-manager/api/devguides/audiences/google-ads/customer-match/check-results) directs you to inspect processing diagnostics, resolve affected records and then retrieve the updated audience. Contact-based audiences expose an overall match-rate field. Keep processing failures separate from matching outcomes.

### Check account eligibility before promising targeting

Google's policy currently distinguishes access to Observation and exclusions from access to Targeting. Targeting requires ninety days of Google Ads history and more than US$50,000 in lifetime spend, alongside the account's compliance and payment requirements. Verify the actual account's available features before designing a small startup's retargeting plan around Customer Match.

There is also a separate list-size requirement. Google's [audience troubleshooting guide](https://support.google.com/google-ads/answer/7476585?hl=en) currently specifies at least one hundred active users in the last thirty days for Search, Display and YouTube, with a legacy caveat for lists last uploaded before February 2024. Uploaded rows are not the same as active users. Inspect each network's eligibility status rather than treating one hundred warehouse contacts as sufficient.

## Treat Meta audience membership as a separate delivery system

Use a customer-list Custom Audience destination, with an explicit audience ID and owning ad account. A connector called “Meta Conversions” may send conversion events without managing customer-list membership. Confirm the object it writes to before assuming it supports this use case.

Meta's [official Business SDK](https://github.com/facebook/facebook-php-business-sdk/blob/main/src/FacebookAds/Object/CustomAudience.php) includes separate user addition and removal operations and handling for already-hashed data. Establish whether your connector expects raw or normalized, hashed identifiers. Hashing something twice will not improve matching. Preserve the source identifier in its protected system and test transformations with synthetic values.

Do not copy Google-specific normalization rules into a Meta transformation without checking the actual destination contract. Likewise, a Conversions API event-matching score is not a customer-list audience match rate. Our [Event Match Quality guide](https://www.martechdevs.com/blog/event-match-quality) explains what that event diagnostic measures.

Document how the media buyer uses the resulting audience: inclusion, exclusion, seed or a suggestion in a broader campaign. Inspect the actual campaign controls and expansion settings. A warehouse segment named `trial_only` does not, by itself, enforce trial-only delivery.

Meta's terms state that it does not disclose the individual users who comprise the matched audience. Build your audit around submitted operations, processing results and available aggregate diagnostics. Do not promise a downloadable list of exactly which warehouse people matched.

## Choose who owns HubSpot segment membership

HubSpot now calls lists “segments.” Its [Lists API guide](https://developers.hubspot.com/docs/api-reference/legacy/crm/lists/guide) describes three processing types: `MANUAL`, `DYNAMIC` and `SNAPSHOT`. A warehouse-managed membership set fits `MANUAL`; a HubSpot-managed set can use `DYNAMIC` filters over synchronized properties. `SNAPSHOT` processes initial filters and then behaves as a manually maintained set.

Choose one owner. Do not try to update a dynamic segment's membership while its filters are independently deciding who belongs. The API permits direct membership changes only for `MANUAL` and `SNAPSHOT` types. Its [membership reference](https://github.hubspot.com/hubspot-api-nodejs/classes/crm_lists.MembershipsApi.html) also specifies that records must already exist; an ignored unknown contact ID is not successful contact creation.

For an email journey, reconcile membership separately from send eligibility. Check subscription state, suppression, the workflow's enrollment rules and the record's marketing-contact handling before launch. An audience sync should not silently change those settings to make its counts look better.

Use warehouse-owned property names where appropriate, such as `warehouse_trial_stage`, so sales users can see the origin of the value. Confirm what happens when it becomes empty and how an existing workflow stops or changes course. Leaving a segment and cancelling a previously scheduled action are separate acceptance checks.

## Design the exit path before scheduling the first import

Compare the new valid snapshot with the last successfully applied membership state. Members in the new set only require addition. Members in the previous set only require removal. Members in both remain, with identifier changes handled explicitly.

For example, a previous set of A, B and C and a new set of B, D and E implies two additions, two removals and one retained member. Record success per operation. If removing C fails, retry C; do not mark the entire new snapshot applied and forget that discrepancy.

Google's [Data Manager API reference](https://developers.google.com/data-manager/api/reference/rpc/google.ads.datamanager.v1) provides audience removal operations as well as ingestion. Equivalent exit behavior must be configured and verified in whichever connector you choose. An add-only integration is insufficient for a changing trial cohort.

Handle these cases explicitly:

- An empty valid audience needs its intended removals applied.
- An empty result caused by a failed source load needs investigation, not automatic replacement of the live audience.
- A known withdrawal needs a removal path even when the normal audience model is unavailable.
- An identifier change may require removal using the previously submitted key as well as addition using the new key.
- Deleting a warehouse row must not destroy the only information needed to request its downstream removal before that request is handled under your retention policy.

Keep withdrawal processing separate from promotional audience growth. A delayed upstream model should not become an excuse to keep using data after the permitted use has ended.

## Set freshness from the cost of being wrong

Google's built-in Data Manager [connection scheduling](https://support.google.com/google-ads-data-manager/answer/13944739?hl=en) currently allows a maximum scheduled import frequency of daily. Updating a source table every five minutes will not make that scheduled connection run every five minutes.

For a slowly changing high-value seed, daily refresh might be adequate. For a trial-to-paid transition, stale membership can waste spend and create a poor experience. Evaluate an API or connector with a suitable update schedule, then measure the platform's processing delay too. Faster submission is not a promise of immediate audience changes.

Measure end-to-end time from the business event to confirmed destination processing. Track the separate delays: event arrival, model completion, sync start, request processing and usable audience state. A job that ran on time using yesterday's billing data is still late for the customer.

Set a failure response as well as a freshness target. If exits cannot be trusted, the campaign owner needs a way to pause the affected use. Repeatedly restarting an apparently successful sync is not a recovery plan.

## Measure the audience funnel before judging performance

Do not borrow a universal match-rate benchmark. Your identifiers, customer population, geography, permission coverage and platform activity determine the available audience.

Consider an illustrative Google audience:

- Six thousand people meet the business definition.
- Four thousand have the required destination permission.
- Three thousand nine hundred have usable identifiers.
- Three thousand eight hundred records are accepted.
- An illustrative matching result corresponds to nineteen hundred people.
- Twelve hundred are active and eligible for the intended network.

The illustrative match step is fifty percent of accepted records. The active audience is twenty percent of the original business cohort. Those figures answer different questions. This is a teaching example, not an observed client result or a reconstruction formula for every platform's reporting.

Investigate the largest meaningful loss. Missing permission is not a formatting defect. Rejected records need error analysis. Low matching needs an identifier-quality review. A matched but ineligible list needs platform eligibility checks. Limited delivery after that involves campaign configuration, budget, auction conditions and message relevance.

Then measure commercial effect. In an illustrative randomized pilot with one thousand eligible people per group, eighty treatment customers versus sixty control customers purchasing produces a two-percentage-point difference, or twenty additional purchases at that group size. With $1,200 media cost and $200 allocated operating cost, the point estimate is $70 per incremental customer.

That estimate still needs an uncertainty assessment and a suitable outcome window. Predefine the randomization unit, avoid cross-group exposure through other campaigns and compare contribution over the same period. If the sample is too small for a decision, report that. Platform-attributed conversions alone cannot establish that the audience caused incremental sales.

## Launch checklist

- [ ] The audience has one business owner, a useful intervention and a measurable outcome.
- [ ] Entry, exit, re-entry and cooldown rules are documented.
- [ ] Destination permission is current and distinct from identifier availability.
- [ ] Snapshot completeness, identity grain and key uniqueness are checked.
- [ ] Adds, removals, identifier changes and failed-operation retries are verified.
- [ ] Actual account eligibility and campaign use match the plan.
- [ ] Workflow exits and scheduled actions have been checked separately.
- [ ] Freshness is measured from the business event through destination processing.
- [ ] A campaign owner can stop the affected use when membership becomes unreliable.
- [ ] The first pilot measures a commercial outcome, with an appropriate comparison.

If the obstacle is connecting product behavior, billing, CRM identity and destination permissions, start with the audience contract. Our [data warehouse and CDP work](https://www.martechdevs.com/data-warehouse-cdp) can turn it into an owned model and operational sync. Where the underlying activation events are unreliable, [analytics and tracking implementation](https://www.martechdevs.com/analytics-tracking) is the earlier step. An accurately delivered audience is only useful when its members actually need the message.

## Frequently asked questions

### How do I send a BigQuery audience to Google Ads?

Prepare an approved audience table or supported view, connect it through Google Ads Data Manager, map identifiers and create a Customer Match list. Check account access, source permissions, processing results and network eligibility. The built-in scheduled connection currently runs at most daily; use an appropriate API or managed integration when the requirement is faster.

### Can I create Customer Match audiences from Snowflake?

Yes. Google documents a Snowflake source connector using a programmatic access token. Restrict its role to the approved activation data and follow current network requirements. An alternative is an activation tool or custom Data Manager API integration with explicit ownership of both additions and removals.

### What audience match rate should I expect?

There is no defensible universal percentage. Measure your permission coverage, usable identifiers, acceptance, matching and network eligibility separately. Compare consistent cohorts and definitions over time. Never treat Meta's event-level Event Match Quality score as an audience matching percentage.

### How often should warehouse audiences refresh?

Often enough to meet the journey's exit and freshness requirements. A daily seed refresh and a rapid payment-triggered removal solve different problems. Measure source delay and destination processing as well as sync frequency, and provide a separate path for withdrawals.

### Does removing someone from an audience delete their CRM record?

Audience removal and record deletion are different operations. A person can leave a promotional segment while remaining a valid customer record. A broader deletion request needs its own governed process across the relevant systems; do not assume a membership update performs it or cancels every downstream action.

## Sources

1. [Google: Customer Match policy](https://support.google.com/adspolicy/answer/6299717?hl=en)

2. [Meta: Customer List Custom Audiences terms](https://www.facebook.com/legal/terms/customaudience/update)

3. [Google: BigQuery data source](https://support.google.com/google-ads/answer/13763054?hl=en)

4. [Google: Snowflake data source](https://support.google.com/google-ads-data-manager/answer/14186945?hl=en)

5. [Google: Customer Match API migration notice](https://developers.google.com/google-ads/api/docs/remarketing/audience-segments/customer-match/manage?hl=en)

6. [Google: Check Customer Match upload results](https://developers.google.com/data-manager/api/devguides/audiences/google-ads/customer-match/check-results)

7. [Google: Audience eligibility troubleshooting](https://support.google.com/google-ads/answer/7476585?hl=en)

8. [Meta: Official Business SDK CustomAudience implementation](https://github.com/facebook/facebook-php-business-sdk/blob/main/src/FacebookAds/Object/CustomAudience.php)

9. [HubSpot: Lists API guide](https://developers.hubspot.com/docs/api-reference/legacy/crm/lists/guide)

10. [HubSpot: Membership API reference](https://github.hubspot.com/hubspot-api-nodejs/classes/crm_lists.MembershipsApi.html)

11. [Google: Data Manager API reference](https://developers.google.com/data-manager/api/reference/rpc/google.ads.datamanager.v1)

12. [Google: Manage connection schedules](https://support.google.com/google-ads-data-manager/answer/13944739?hl=en)