Triggering ads from email activity, and emails from ad activity

Your email list and your ad accounts are talking about the same people

Most shops run email and paid ads as two separate lanes. One is owned, the other rented. The customer does not care which budget line a message came from. They notice when the advert for the thing they bought on Tuesday follows them around all week, and they notice when the welcome email ignores the advert that brought them in.

Joining the two lanes up is less glamorous than the old version of this article made it sound. There is no magic real time bridge between an email opened at 9am and an advert shown at 9.05am. There are customer lists, uploaded to the ad platforms and matched against their users, with real minimum sizes, real delays and real legal duties. And there is the other direction, where what someone clicked in an advert decides which emails they get. This article walks through both, with the numbers each platform publishes today.

Throughout I use one invented business. Coal Quay Coffee Roasters is an online coffee shop in Cork, run by Aoife, at coalquaycoffee.example. It sells beans and a monthly subscription, has 12,000 email subscribers, and takes about 3,000 orders a month. Nobody real, and every number below is made up so that every step can be shown.

An email open is no longer a signal you can trust

The old version of this article started with a neat idea: someone opens an email but does not click, so they hesitated, so show them an advert. That idea has not aged well, for two reasons.

The first is Apple. Mail Privacy Protection in Apple's Mail app downloads remote content in the background by default, including the invisible image an email tool uses to record an open, and it does so whether or not the person ever reads the message.¹ For every reader using Apple Mail with that protection switched on, an "open" means "Apple fetched the pixel", not "a person looked at the email". Your email tool cannot tell the two apart.

The second is the law. In Ireland, regulation 5(3) of the ePrivacy Regulations 2011 says nobody may store information on a user's device, or read information already stored there, without the user's consent and clear, comprehensive information about the purpose.² The Data Protection Commission (DPC) names pixel trackers among the technologies the rule covers, and says it applies to any storage on or access to the device, whether or not the information is personal data.³ A tracking pixel in a marketing email that reads information on the reader's device falls under that rule, on top of the email marketing rules in regulation 13.² So an open is a weak signal and a regulated one.

A click is different. It is something a person did, and it lands them on your website, where your own consented tags can see what they do next.

An example: Aoife sends 12,000 subscribers an email about a new decaf. The email tool reports 6,000 opens and 240 clicks. If she builds a segment of "opened, did not click", she gets 5,760 people, and she has no way of telling how many of them are Apple's servers rather than hesitant coffee drinkers. If she builds "clicked, did not buy within seven days" instead, she gets the people who actually went to look. Of the 240, 60 bought, so the segment is 180 people. Smaller, and every one of them made a choice. That is the segment the rest of this article works with.

Customer lists are how email data reaches the ad platforms

The ad platforms cannot read your email tool. What they can do is take a list of your customers' contact details, compare it with their own users, and build an audience from the people they recognise. Google calls this Customer Match. Meta calls it a customer list Custom Audience.

Google's lists work across Search, the Shopping tab, YouTube, Gmail and Display, and they match only the people on your file who are Google users signed in to their account.⁴ Before you upload, every email address, name and phone number is normalised and hashed with SHA256: trim the spaces, lower case the text, write phone numbers in the international E.164 format (+353 and the number, for an Irish mobile), then hash.⁵ Meta asks for the same: SHA256 only, email addresses trimmed and lower cased, and the result as lower case hexadecimal.⁶ Hashing turns the address into a long fingerprint. The platform hashes its own users' addresses the same way and compares fingerprints, so the plain address never has to travel.

Here the old version of this article had a bug worth fixing in public. Its code created a brand new Meta audience for every single email address, named after the address, and put the unhashed address in the creation request. Meta's actual flow is two steps: create one audience once, then add hashed members to it through its users endpoint, up to 10,000 at a time.⁶ One audience, many members, and no plain addresses anywhere.

Worked example: hashing one subscriber

Sam is one of Aoife's subscribers. He signed up as Sam.Okafor@Example.com, with a stray space at each end and capital letters, because people type how they type.

Step one, trim the spaces: Sam.Okafor@Example.com.

Step two, lower case: sam.okafor@example.com.

Step three, hash with SHA256. The result is:

cadf509141f2575272ebb2a8dd6ebe0181887974cf671a90d8923dc83c7baf11

Had Aoife skipped steps one and two and hashed the address exactly as typed, she would have sent a7ab17b5e18769a4377ac6b3549869903c9b57608a36ee623ef3c13f3d3d7dc3. That fingerprint matches nobody, because the platform hashed the clean version. A single space costs a match, and Google lists "not correctly formatted before it was hashed" among the main causes of a low match rate.⁷

Here is the corrected Meta upload, in Python. It assumes the audience was created once, by hand or by a separate call, and only adds members.

import hashlib
import json
import os

import requests

GRAPH = "https://graph.facebook.com/v27.0"
AUDIENCE_ID = os.environ["META_AUDIENCE_ID"]
TOKEN = os.environ["META_ACCESS_TOKEN"]


def normalise_and_hash(email: str) -> str:
    clean = email.strip().lower()
    return hashlib.sha256(clean.encode("utf-8")).hexdigest()


def add_members(emails: list[str]) -> None:
    hashed = [[normalise_and_hash(e)] for e in emails]
    for start in range(0, len(hashed), 10_000):
        batch = hashed[start:start + 10_000]
        payload = {"schema": ["EMAIL"], "data": batch}
        response = requests.post(
            f"{GRAPH}/{AUDIENCE_ID}/users",
            data={"payload": json.dumps(payload), "access_token": TOKEN},
            timeout=30,
        )
        response.raise_for_status()


add_members(["sam.okafor@example.com", "priya.shah@example.com"])

For more than 10,000 members, Meta wants the batches tied together in one session, with a sequence number and a flag on the last batch.⁶ The loop above is the shape. A production job adds the session fields and logs every response.

Match rate and minimum sizes decide whether a segment exists at all

Not everyone on your list will be found. The share the platform recognises is the match rate. Google says most advertisers see match rates between 29% and 62%.⁸ Meta does not publish a figure, and Klaviyo, which syncs lists to Meta, simply warns that the audience will often be smaller than the list because only addresses tied to a Meta login match.⁹

Then comes the floor. Google's Display, Search and YouTube networks each need at least 100 active users in the last 30 days before a list is used, for customer lists uploaded or refreshed after 1 February 2024.¹⁰ Google's own counting adds a twist: the match rate counts everyone with a Google account, while the list size counts only active users who can actually be reached by personalised ads, so the usable number is smaller again.⁷ Meta needs at least 100 people to build a customer list audience, as Klaviyo's documentation of the Meta sync puts it.⁹

The expected number of matched people is a plain rate times a count:

$$n_{\text{matched}} = n_{\text{uploaded}} \times m$$

Here $n_{\text{matched}}$ is the expected number of people the platform recognises, $n_{\text{uploaded}}$ is the number of people on the list you upload, and $m$ is the match rate, written as a share between $0$ and $1$. A rate is events over opportunities, explained from scratch in Foundations: ratios and rates.

Worked example: two of Aoife's segments

Aoife has no match rate of her own yet, so she assumes $m = 0.45$, the middle of Google's published range.

Her whole list of 12,000 subscribers:

$$12{,}000 \times 0.45 = 5{,}400$$

Here $12{,}000$ is the list and $0.45$ the assumed match rate, so about 5,400 matched people. Grand, and comfortably over the floor, even after Google trims the inactive ones.

Her clever little segment from earlier, the 180 who clicked the decaf email and did not buy:

$$180 \times 0.45 = 81$$

Here $180$ is the segment and $0.45$ the same assumed match rate, so about 81 matched people. That is under 100, so neither Google nor Meta will show an advert to it. The precise, satisfying, behaviour based trigger from the old article does not exist as an audience. To use it, Aoife would need a segment roughly 223 people strong before matching ($100 / 0.45$), and more in practice because Google only counts the active ones. Small segments are better served by email itself.

Suppressing recent buyers is the sync that pays first

Showing a promotion to someone who bought yesterday is the most common way a shop wastes money with customer lists, and the easiest to stop. You upload a second list, your recent buyers, and set it as an exclusion on the campaign. Google's Customer Match policy is helpful here in an unexpected way: any advertiser in good standing with policies and payments can use lists for exclusions and observation, while using them for targeting needs 90 days of account history and more than $50,000 of lifetime spend.¹¹ Google sets that threshold in US dollars, and for a shop of Aoife's size it is a long way off. So suppression is not just the useful case. On Google it is the available one.

What does not suppressing cost? Assume the spend is spread evenly across the audience. Then the money spent on recent buyers is the budget times their share of the audience. With exclusion, two leaks remain: buyers the exclusion list does not recognise, and buyers who have not reached the exclusion list yet.

$$W = B \times s \times \left[(1 - c) + c \times \frac{L}{T}\right]$$

Here $W$ is the monthly spend wasted on recent buyers, in euro, $B$ is the monthly budget, $s$ is the share of the audience who bought in the window, $c$ is the coverage, the share of those buyers the exclusion list actually catches, $L$ is the average lag in days between a purchase and the exclusion taking effect, and $T$ is the length of the window in days. Without any exclusion, $c = 0$ and the bracket is $1$. The first term in the bracket is the share that slips through, the second is the share that is caught but late. Shares and their changes are covered in Foundations: percentages.

Worked example: Aoife's subscription promotion

Aoife spends €900 a month on a Meta campaign promoting the subscription to her own subscriber list. Of her 12,000 subscribers, 3,000 bought in the last 30 days, so $s = 3{,}000 / 12{,}000 = 0.25$. The match rate does not change this share, because buyers and non buyers are matched at the same assumed rate: of 5,400 matched subscribers, 1,350 are recent buyers, still a quarter. The even spread is the example's assumption. Meta's delivery system decides who sees what, and the real share could be higher or lower.

No exclusion:

$$W = 900 \times 0.25 \times 1 = 225$$

Here $900$ is the budget and $0.25$ the buyers' share, so €225 a month goes on adverts to people who already bought.

Now the exclusion. The exclusion list matches on the same email address as the targeting list, so a buyer matched in one is matched in the other. The leak is buyers who ordered with a different address from the one they subscribed with. Aoife's shop links orders to subscriber profiles through the customer account, and she counts 450 of her 3,000 buyers whose order address differs. So uploading order addresses alone gives coverage $c = 2{,}550 / 3{,}000 = 0.85$.

She uploads once a week. A purchase waits on average half the interval for the next upload, 3.5 days, which is the mean of a delay spread evenly between zero and seven days, explained in Foundations: the mean. Meta says changes usually take up to 24 hours to apply,⁶ so she adds one day: $L = 4.5$.

$$W = 900 \times 0.25 \times \left[(1 - 0.85) + 0.85 \times \frac{4.5}{30}\right] = 225 \times (0.15 + 0.1275) = 62.44$$

Here $0.15$ is the share that slips through, and $0.85 \times 4.5 / 30 = 0.1275$ is the share caught late. About €62 a month still leaks.

Uploading daily makes the lag $0.5 + 1 = 1.5$ days:

$$W = 225 \times \left[0.15 + 0.85 \times \frac{1.5}{30}\right] = 225 \times (0.15 + 0.0425) = 43.31$$

Here $0.0425$ is the share caught late with a daily upload. About €43.

Finally she uploads every address on the buyer's account plus the phone number, which Google explicitly recommends, several identifiers on the same row.⁸ Her assumption, which she can check against next month's match report, is that this lifts coverage to $c = 0.97$:

$$W = 225 \times \left[0.03 + 0.97 \times \frac{1.5}{30}\right] = 225 \times (0.03 + 0.0485) = 17.66$$

Here $0.03$ is the share that still slips through and $0.0485$ the share caught late. About €18 a month.

Each bar is one way of running the exclusion. The vertical axis is the monthly spend on adverts shown to people who bought in the last 30 days. The takeaway has two parts. Switching the exclusion on at all saves the most, about €163. After that, matching more of your buyers (more identifiers on each row) beats uploading more often: the move from weekly to daily saves about €19, the extra identifiers another €26. Over a year the gap between no exclusion and the last bar is about €2,500 on a €900 budget.

One shortcut is worth knowing. If the campaign targets website visitors rather than your list, Meta can build an audience straight from your pixel's Purchase events with a retention window,¹² and the same identifier that put someone in the visitor audience takes them out again. That only covers visitors who accepted the advertising cookie, which is the subject of the legal section below.

Refresh timing is a decision, not a default

Every list has a shelf life. On Google, Customer Match memberships expire after 540 days, and a list needs at least 100 members added or updated in that window to stay eligible.⁴ The Google Ads API caps a list's membership life span at 540 days, which is also the default, and stopped allowing unlimited duration on 7 April 2025.⁵ Google's best practice is blunt: lists that are not updated go stale, and API uploads should append to lists at least once a day.⁸ On Meta, customer file audiences not used in an active ad set for more than two years are flagged for deletion.⁶

Processing takes time on both sides. A Google upload job can take as little as 10 minutes or as long as 24 hours to complete, then up to 24 hours more for the list to populate, and uploading more than once every 12 hours can leave it showing "In Progress".⁵ Meta says changes usually take up to 24 hours, and removals can take longer as the account grows.⁶

An example: Aoife's buyer list should drop people 30 days after their last order, because after a month they are due a refill and a reminder becomes welcome again. With a daily upload, each day's file adds yesterday's buyers and removes those whose last order is now 31 days old. Her subscriber list for targeting changes slowly, so a weekly refresh is enough, and the 540 day expiry never bites because the weekly job touches a good few more than 100 members. The fast list gets the fast schedule. The slow list gets the slow one.

Native integration or your own code

There are two ways to do the uploads. Your email service provider (ESP) may sync segments for you, or you write the job against the platforms' APIs.

Klaviyo, as one documented example, does both directions of the plumbing for you. A Klaviyo list or segment can be connected one to one with a Meta custom audience, the sync runs one way from Klaviyo to Meta, changes are sent on an ongoing basis, and Meta can take 24 to 48 hours to show them.⁹ On the Google side the same one to one sync sends email addresses and phone numbers, updates go in real time, Google may take up to 48 hours to process them, and it works only if the Google Ads account is eligible for Customer Match. Klaviyo also documents syncing a segment and then excluding it from a campaign, which is exactly the suppression case.¹³

There is a catch in the small print. For EEA audiences, which includes everyone on an Irish list, Klaviyo offers a box that says you will only send audiences that have granted consent for ad targeting. Ticking it makes Klaviyo send ad_user_data and ad_personalization as granted for every profile in the sync, and Klaviyo does not check each profile's consent itself.¹³ The box is a promise you make, not a filter it applies. The segment has to do the filtering.

Your own code makes sense when the data lives in your shop's database or a warehouse rather than the ESP, or when you need several identifiers per row. On Google, plan for the Data Manager API: since 1 April 2026 the older Customer Match services in the Google Ads API fail for projects that had no Customer Match activity between 1 October 2025 and 31 March 2026, and Google's documentation says to use the Data Manager API instead.⁵ The sending side of such a job, with signed webhooks, queues and retries, is in my article on webhooks and serverless campaign logic.

An example: Aoife's subscriber list lives in Klaviyo, so the targeting list is a native sync of a Klaviyo segment. Her buyer list needs every address on the account and the phone number, which live in the shop, so it is a nightly job of 40 lines that reads the shop's orders, hashes the identifiers and replaces the audience. Two lists, two routes, each where its data already is.

The other direction: the advert decides the email

So far the email side has shaped the advertising. The return path is simpler and often more useful: what someone clicked in an advert decides which emails they get.

The old article had the right idea here. An advert carries UTM parameters, the tags such as utm_campaign and utm_content in the landing page address that say which campaign and which advert brought the visitor.¹⁴ If the signup form passes them into the subscriber's profile, the welcome sequence can continue the advert's story instead of starting a generic one. The naming discipline behind useful UTMs is in mastering UTM tracking.

How you carry the tag from the landing page to the form matters. The DPC's guidance says the rule in regulation 5(3) is not only about cookies: it applies to any storage of information on the user's device, whatever the technology.³ The old article's snippet saved utm_term in local storage. That is storage on the device, and if its purpose is advertising measurement, the strictly necessary exemption does not cover it, because the DPC says cookies related to advertising are not strictly necessary and must be consented to.³ The lighter route is to read the parameters from the address on the page where the form sits and put them in hidden fields, so nothing is stored on the device. If the visitor moves around the site before signing up, keep the tag only after they have consented, or accept that you lose it.

An example: Aoife runs a Google search advert for decaf beans, with utm_campaign=decaf on the landing page address. Priya, at priya.shah@example.com, lands on the decaf page and subscribes from the form on that same page. A few lines of JavaScript copy decaf from the address into a hidden field, and Klaviyo stores it as a profile property. Her welcome series opens with the decaf range and a brewing guide, not the espresso blend everyone else gets first. Nothing touched her device's storage, and the advert's promise carried straight into her inbox.

The law: a lawful basis for the list, consent for the pixel

Two different sets of rules apply, and it pays to keep them apart.

Uploading a customer list is processing personal data under the GDPR, so you need a lawful basis. Most shops reach for legitimate interests in Article 6(1)(f), and Recital 47 says processing for direct marketing purposes may be regarded as carried out for a legitimate interest.¹⁵ "May" is doing work there: the same recital asks whether people could reasonably expect the processing when their data was collected, and you still run the balancing test. The European Data Protection Board (EDPB) works through this exact case in its guidelines on targeting social media users. A bank that told a customer at signup his email address could be used for advertising, gave him the chance to object, and advertises services like the ones he already uses might rely on legitimate interest. A bank that uploads someone who only booked an appointment and then decided against becoming a customer cannot. The guidelines add that meeting the duty to inform does not by itself count towards the balancing test.¹⁶ They also say that when you upload a list for the platform to match, you and the platform are joint controllers for the upload, the matching and the display of the advert,¹⁶ and Article 26 then requires an arrangement setting out who answers for what towards the people on the list.¹⁵ That is why a sentence in the privacy notice nobody reads is a weak footing, and why Google's policy insists your privacy policy discloses the sharing.¹¹

People have an absolute right to object to direct marketing, and once they object, their data must no longer be used for it.¹⁵ Meta's Custom Audience terms make the advertiser warrant a lawful basis for the data and that it does not cover people who have opted out of such use.¹⁷ In practice: anyone who unsubscribed or objected stays out of every upload, and the suppression list is checked before each one. Google's own plumbing enforces part of this: a Customer Match upload with either consent field set to denied is rejected, and for EEA users, which includes all of Aoife's, a missing consent value counts as no consent.⁵

The pixel side is the ePrivacy Regulations. Regulation 5(3) needs consent for storing or reading information on the device, and the only way round it is regulation 5(5): storage purely to carry a communication, or what is strictly necessary for a service the user explicitly asked for.² Advertising is neither. The DPC says cookies related to advertising are not strictly necessary and must be consented to, and the same goes for pixels and similar technologies.³ Every website audience, including the Purchase event shortcut above, rests on that yes. How the consent signal travels to Google's tags is in event tracking and consent mode, and what changes when events go through your own server is in server side tracking. Server side never removes the need for the yes.

An example: Aoife writes one line into her signup form and privacy notice: "I may share your email address, securely scrambled, with Google and Meta, so that you see fewer adverts for things you have already bought and more for things you might like. You can object at any time." Her nightly job builds every list from a query that leaves out anyone on the suppression list. When Sam unsubscribes on a Thursday evening, Friday's upload no longer contains him, and Friday's job also sends a removal for his fingerprint. She keeps a short written legitimate interests assessment next to the code. None of this is legal advice, and for a larger list a solicitor's hour is money well spent.

The whole sync on one page

Read it top to bottom. Data starts in the shop and the email tool, never in the ad platform. The decision step sits before the hashing, so nothing that should not travel ever gets fingerprinted. The processing delay is a fixed cost you plan around, which is why recent buyer lists run daily and everything else weekly. And the review closes the loop: if the match rate drops or a list falls under 100, the audience quietly stops working, and only someone looking will notice.

An example: Sam orders a bag of the house blend on a Monday at 2pm. The shop updates his profile, and that night's job puts him in the recent buyer segment. He has not objected, so his address and phone number are hashed and uploaded. By Wednesday at the latest, Meta and Google have processed the file and he stops seeing the subscription promotion. On day 31 the job drops him from the buyer list, he becomes eligible for the promotion again, and his refill reminder email goes out that week. One customer, two channels, one story.

Continuity beats cleverness

The old article's instinct still holds: an advert and an email that ignore each other waste money and goodwill. The mechanism is what changed. Exclude recent buyers with every identifier you have, refresh fast lists daily and slow ones weekly, carry the advert's promise into the welcome email, and keep the people who said no out of every file, every time.

Sources

Footnotes

1. Apple, Mail Privacy Protection and privacy, Apple Legal, https://www.apple.com/legal/privacy/data/en/mail-privacy-protection/

2. European Communities (Electronic Communications Networks and Services) (Privacy and Electronic Communications) Regulations 2011, S.I. No. 336 of 2011, regulations 5(3), 5(5) and 13, Irish Statute Book, 2011, https://www.irishstatutebook.ie/eli/2011/si/336/made/en/print

3. Data Protection Commission, Guidance note: Cookies and other tracking technologies, DPC, 2020, https://www.dataprotection.ie/sites/default/files/uploads/2020-04/Guidance%20note%20on%20cookies%20and%20other%20tracking%20technologies.pdf

4. Google, About Customer Match, Google Ads Help, 2026, https://support.google.com/google-ads/answer/6379332

5. Google, Get started with Customer Match, Google Ads API documentation, Google for Developers, 2026, https://developers.google.com/google-ads/api/docs/remarketing/audience-segments/customer-match/get-started

6. Meta, Customer file Custom Audiences, Marketing API documentation, Meta for Developers, 2026, https://developers.facebook.com/docs/marketing-api/audiences/guides/custom-audiences

7. Google, Troubleshoot customer list issues, Google Ads API documentation, Google for Developers, 2026, https://developers.google.com/google-ads/api/docs/remarketing/audience-segments/customer-match/troubleshoot

8. Google, Customer Match best practices, Google Ads Help, https://support.google.com/google-ads/answer/10010286

9. Klaviyo, Getting started with Meta Ads, Klaviyo Help Center, 2026, https://help.klaviyo.com/hc/en-us/articles/115005082127

10. Google, About audience segments in Audience manager, Google Ads Help, 2026, https://support.google.com/google-ads/answer/7558048

11. Google, Customer Match policy, Google Ads Help, 2026, https://support.google.com/google-ads/answer/6299717

12. Meta, Website Custom Audiences, Marketing API documentation, Meta for Developers, 2026, https://developers.facebook.com/docs/marketing-api/audiences/guides/website-custom-audiences

13. Klaviyo, Getting started with Google Ads, Klaviyo Help Center, 2026, https://help.klaviyo.com/hc/en-us/articles/6353315757211

14. Google, URL builders: collect campaign data with custom URLs, Google Analytics Help, https://support.google.com/analytics/answer/10917952

15. Regulation (EU) 2016/679, General Data Protection Regulation, Article 6(1)(f), Recital 47, Article 21(2) and (3) and Article 26, EUR-Lex, 2016, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

16. European Data Protection Board, Guidelines 8/2020 on the targeting of social media users, version 2.0, section 5.2.2, EDPB, 2021, https://www.edpb.europa.eu/system/files/documents/2021-04/edpb_guidelines_082020_on_the_targeting_of_social_media_users_en.pdf

17. Meta, Custom Audience terms, Meta, https://www.facebook.com/legal/terms/customaudience