How to Use mParticle to Send an Audience to Ads and BigQuery

The short answer: mParticle publishes no price, so this job starts once a contract exists and your developers have shipped the SDKs; from there one audience reaches Google Ads in 6 to 12 hours and Meta within 24, and BigQuery receives events within minutes of being connected (Google Ads audience docs, Facebook audience docs, BigQuery output, checked on 5 November 2026). The steps: issue input keys, settle identity before the first event, tag batches with a data plan, pull the warehouse in, build the audience, connect it to Google Ads and Facebook and the input to BigQuery, let mParticle Agent propose the next one while a person saves and activates it, and reconcile the sizes.

Disclosure: I may earn a commission through some links on this site. It does not change what this page says.

Searchers ask this about mParticle in several forms: can one stream of customer data reach the ad platforms, the analytics tool and the warehouse at once. It can; the useful part is how long each road takes. What mParticle is, who owns it and what its rivals charge is in the mParticle entry.

Before you build:

• Work out how often Meta will hear from you. Audience updates to Facebook leave a queue every 3 hours, or sooner once 75,000 messages are waiting (Facebook audience docs). For example, an audience gaining 1,200 members a day never trips the message rule and syncs about 24 / 3 = 8 times a day: a buyer who converts at 09:00 leaves the retargeting pool by lunchtime, not by the minute.
• Write down which identifier each source carries. Website: an email after login. App: a device ID from the first open. CRM export: a customer ID. IDSync resolves a batch to a profile in the priority order your identity strategy sets (IDSync components); this list becomes that order.
• Decide which count is the record. Google Ads shows a list as 0 below 100 members and rounds larger sizes to two significant digits (Google Ads audience docs). Report mParticle's size and treat the destinations' figures as proof the sync ran.

What you need

• An mParticle workspace. Nothing is self-serve: the docs' Sign Up link lands on a Talk to an expert form (platform page).
• A developer for the SDK work, and the Admin role for the warehouse output.
• A Google Ads account with its Client Customer ID, and a Facebook ad account with Full Access and the Custom Audience terms accepted.
• A Google Cloud project with BigQuery enabled.

Step 1: Issue keys per input

Under Data Platform, Setup, Inputs, choose the platform and click Issue Keys; copy the Key and Secret, which a client-side SDK can embed because they cannot read data back (create an input). Repeat per platform, then watch Data Platform, Live Stream while a development build runs: installs and sessions appear without extra code.

Step 2: Settle identity before data flows

The default strategy sets both the unique ID and the login ID to customer_id, and the docs state they cannot be changed; profile conversion keeps one profile when a new login ID arrives, profile link follows the events before an account or a purchase, and profile isolation keeps anonymous activity off known profiles (IDSync components). The identity page says to agree the strategy with your account team (identity page); do it in week one, because a strategy chosen after a month of data is a migration.

Step 3: Tag batches with a data plan

A data plan lists the events, attributes and identities you expect; batches tagged with its ID are validated and the rest are not (data planning). Blocking unplanned data drops it before profiles and audiences see it, and the guide warns of data loss unless a quarantine connection to an S3 bucket catches what was blocked. Validate first, block later.

Step 4: Pull the warehouse in

If purchase history sits in BigQuery, Warehouse Sync runs your SQL against BigQuery, Snowflake, Redshift or Databricks and maps columns such as customer_id to identities automatically (Warehouse Sync setup). Pick hourly, daily, weekly or monthly, and pick incremental: the docs say full mode can incur very high costs and that a pipeline's sync mode cannot be changed once created. Databricks views are not supported.

Step 5: Build the audience

Under Audiences, New Audience, add criteria of the event or user type; the default recency is greater than 0 events in the last 30 days, criteria chain with And, Or and Exclude, and Exclude is the docs' own suggestion for abandoned carts (create an audience). Activate it and expect a size of 0 while it calculates; a size still 0 after calculation means the conditions are wrong.

Step 6: Connect Google Ads

Set up Google Ads as an audience output with the Client Customer ID, sign in when prompted, and give the App Store ID or Android package name for any device ID list (Google Ads audience docs). Email and phone go across as SHA-256 hashes; membership lasts 30 days by default and can run from 0 to 540. Combine Email and Phone makes one list instead of two and cannot be switched later.

Step 7: Connect Facebook

The ad account must have accepted the Custom Audiences, Value Based Custom Audience and Web Custom Audience terms before the connection works (Facebook audience docs). Each identity you tick becomes a separate Facebook audience unless Multi-Key Audiences is on, a full sync can take 24 hours, and Facebook caps an ad account at 500 custom audiences. Delete the audience in mParticle and the Facebook copy goes with it.

Step 8: Send the events to BigQuery

Add Google BigQuery under the Data Warehouse tab, grant mParticle's service account the BigQuery Job User, Data Editor and Project Viewer roles, enter the project and dataset IDs, and connect every input you want stored (BigQuery output). Loading starts within minutes, with one table per custom and commerce event name seen in the last 30 days.

Both doors to your warehouse belong to the platform: this output writes the tables, Warehouse Sync reads them, and in both directions the profile that ties a row to a person is held in mParticle, which is what makes the audiences hard to move once they depend on it. Keep your own customer_id on every row so the join outlives any vendor.

Step 9: Let the Agent draft the next audience, and save it yourself

Open mParticle Agent and describe the goal in plain words; it returns up to three definitions with a suggested name, an estimated size and the criteria, and produces a proposal card for a real-time audience (Agent guide). The human check is built in: nothing is saved until you confirm, and the Agent cannot activate an audience or connect an output, both of which stay manual in the UI (Agent page). Copy the chat before closing to keep the rejected definitions.

Step 10: Reconcile the counts

After 48 hours, put the mParticle size beside the Google Ads and Facebook sizes. Google's rounding and 100-member floor and Facebook's queue explain most gaps; a list still at 0 after two days means identifiers did not match, so check which identity types the audience carried.

What the docs warn about

• Blocking in a data plan drops data for good without a quarantine connection.
• Warehouse Sync in full mode re-reads everything each run, and the mode is fixed at creation.
• Google Ads Customer Match matches only addresses tied to a Google account.
• Erasure forwarded to partners is sent, not verified; the DSR guide says to check each vendor yourself (data subject requests).

FAQ

Does mParticle have an MCP server?

Not in the documentation read on 5 November 2026: the developer section lists Events, Profile, Bulk Profile Deletion and Warehouse Sync APIs (developer docs), and the Agent runs inside the product.

Can I try this on a free plan?

No free plan or trial is documented; the docs' Sign Up link opens the platform page and its contact form (platform page).

Why does Google Ads show my list as empty?

Lists under 100 members display as 0, new members take 6 to 12 hours and sometimes 48, and only addresses linked to a Google account match (Google Ads audience docs).