Warehouse Audience Sync to Google, Meta and LinkedIn

A hashed-email list exported from a B2B CRM matches 40 to 70 percent of its rows against Google Customer Match, and Google will not serve the audience until roughly 1,000 members match on their side. LinkedIn's floor is 300. That arithmetic, not the pipeline tool, decides which of your segments are worth syncing at all, and it is the first calculation we run, before anyone writes a model. What we build: Audience definitions live in your warehouse as version-controlled dbt models on Snowflake, BigQuery or Postgres. Not a saved query in a BI tool. Not a filter inside the ad platform. One row per person, carrying the identifier, the consent state, the suppression flag and the date the row became true. When "active trial, no card on file" changes meaning, it changes in one file, in a pull request, and every destination inherits it on the next run. Hightouch or Census does the moving. We have no preference beyond what your team already pays for and who is on call at 2am. Destinations we ship regularly: Google Ads Customer Match, Meta Custom Audiences paired with the Conversions API for the event side, LinkedIn Matched Audiences, TikTok, and Klaviyo or Braze where lifecycle owns the same segment and should not be defining it separately. Keys are hashed email, phone normalised to E.164, and mobile advertiser IDs where the app already collects them behind a consent prompt. Where a destination accepts an external identifier we send the CRM record ID, so a later removal takes out that person rather than the closest-looking one. Exclusions first: The first three audiences on most engagements are not targets. They are existing customers, accounts with an open opportunity owned by a rep, and closed-lost with a reason code that means never. On a fintech engagement with a ninety-day approval cycle, the exclusion set was the change that moved blended acquisition cost, because prospecting had been re-buying people the sales team was already mid-conversation with. Consent: Consent state travels on the row, not in the destination's settings. Consent Mode v2 signals, ad_user_data and ad_personalization, are mapped from what your CMP actually stored, not inferred from a page view. Where the controller is Israeli, each sync gets a one-page record documented against Amendment 13 of the Privacy Protection Law, in force since 14 August 2025: purpose, lawful basis, retention, deletion path. In Hebrew and English if your DPO wants both. For EU subjects the same table carries DSAR-driven suppression, so a deletion request propagates to every destination on the next run rather than being handled by memory. Syncs fail quietly, so match rate is monitored per destination and alerts when it drops more than ten points week over week. That is almost always a hashing or normalisation change upstream rather than an audience problem, and knowing which saves a week of arguing with a platform rep. Not included: We do not build ad accounts, write creative, or touch bids. We do not buy or scrape third-party contact data, and we will not sync a list whose origin you cannot name. We do not implement a consent management platform; we consume the one you have. We will not sync a propensity score that nobody on the paid side can explain in one sentence, because the media buyer is the person who ends up defending it to a CFO. Who this is wrong for: If customer data lives only in the CRM and there is no warehouse, this is out of order and we will say so on the first call rather than sell you a pipeline with nothing to pull from. If you want match rate maximised regardless of what the consent record says, we are not the practice for that.