Can You Still Retarget Users Who Withdrew Marketing Consent: A Pixel Gating Design Story

Audience: Marketers · Growth  ·  Case: Telecom/rental comparison sign-up service  ·  2026-06-17

I Thought It Was an Easy Question

At first, it really seemed like an easy question. A member goes to their account page and toggles off "Receive marketing information." So shouldn't we just turn off the ad pixel (the tracking code that sends visitor behavior to ad platforms) for that person? They didn't consent, after all.

So I wrote down one rule: "If marketing consent is not true, block all 5 pixels from firing." Clean. One line, done.

But after writing that one line, something felt off.

Where I Got Stuck: What Happens to Non-Members, Then?

Most visitors to our site aren't logged in. Telecom and rental comparison sign-up follows a browse-then-request-consultation flow, so the overwhelming majority of people just look around and leave. One pillar of our re-engagement strategy was exactly this: "bring non-member drop-offs back with retargeting."

But non-members have no marketing consent value at all. Under the rule above, since consent isn't true, every non-member pixel gets blocked. The majority of our traffic, and the core target of our retargeting strategy, would vanish entirely.

The rule was clean, but it was killing our strategy. In trying to honor one member's consent withdrawal, I'd shut off tens of thousands of anonymous visitors along with them. The problem was tying two different things to a single switch.

The Turning Point: This Isn't One Side, It's Two

I stopped here and rethought things. We'd been lumping everything together as "marketing," but in fact two completely different things were mixed in.

Side A means showing ads again to "a browser that has visited this site," based on a cookie whose owner is unknown. Side B means knowing exactly who this person is, sending them a text at their phone number, or targeting them specifically with ads.

A member turning off consent means rejecting Side B. "Don't text me, don't target me by name with ads." But it doesn't mean turning off the trace of them browsing the site as an anonymous browser. Legally, at least, those are two different layers.

So the gating had to split in two as well. Side A on cookie consent, Side B on member consent. Not one switch, but two.

A False Start: Almost Claiming "We Don't Know Who That Cookie Is"

Once I'd worked this out, I was fairly satisfied. "Even a member who opted out can just be treated like an ordinary non-member at the anonymous cookie level, because we don't know which member that cookie belongs to." That was my defense.

Then I looked back at our data structure again. And I stopped.

We use something called a device_id, an arbitrary identifier bridging the logged-out and logged-in states. When an anonymous visitor who came through an ad signs up and activates a plan days later, we use this device_id as a bridge to link cookie ↔ phone number ↔ member into a single chain, so we can feed that revenue back as ad performance. In our BigQuery (data warehouse), all of that sits together in one table.

In other words, "we don't know who this cookie is" was a lie. We do know. We built it that way on purpose, so we could know. The very bridge we'd carefully built to track offline conversions was exactly what broke our anonymity defense.

This is the real danger line. If even one path remains where the system can resolve "this anonymous cookie = member Minseop who opted out," regulators will view it simply as "member retargeting in disguise, circumventing consent withdrawal." Writing "we don't look at this" in a policy document isn't enough. The defense only holds if the data flow itself makes it impossible to see.

The solution ultimately came down to one rule: let ad platforms build Side A retargeting audiences on their own pixel cookies, and never use our BigQuery person-graph for ad targeting, period. Even if we have the ability to identify someone, as long as we don't use that ability for advertising, the privacy-policy statement that "personalized ads don't directly identify individuals" becomes true.

Another False Start: Does Korea Also Need a Cookie Banner?

Partway through, I overcorrected once. I concluded that "running behavioral ads for non-members absolutely requires a cookie-consent surface," meaning that cookie-consent banner that pops up on European sites.

Wrong. That isn't mandatory in Korea. In Europe, the ePrivacy Directive effectively forces a prior-consent banner for non-essential cookies, but Korea has no equivalent cookie-specific law. Korea runs on notice + opt-out, not prior opt-in consent. It's enough to state in the privacy policy that "we collect behavioral information for these purposes, provide it to ad platforms, and here's how to opt out." No blocking banner is required.

When I checked, our privacy policy already covered almost all of it: the categories of behavioral data collected, the purpose of personalized advertising, the phrase "does not directly identify individuals," even opt-out links for Google and Naver. The surface needed for Side A's defense had already been in place. I'd simply misapplied the EU standard onto Korea.

This is a lesson worth recording. Whenever privacy comes up, my mental default keeps reaching for GDPR (Europe's General Data Protection Regulation). But we operate in Korea, and the standard is different.

The Scar That Remains: A Hashed Phone Number Isn't "Anonymous"

The last decision was to send hashed phone numbers to Meta and Google via CAPI (Conversions API, which sends conversions directly from our server to ad platforms) for more accurate conversion measurement.

Rather than sending the phone number as-is, we one-way hash it with SHA-256. For a while, I treated this as "a minor issue since it's anonymous," on the assumption that hashing meant it was no longer personal information.

This needs to be stated precisely. A hashed phone number is not "not personal information" under Korean law. It's pseudonymized information. Phone numbers have a limited range of possible values, so if the recipient (the ad platform) holds matching data, they can re-identify who it belongs to. "It's hashed, so it's safe" is false reassurance.

And sending it to Meta and Google means transferring pseudonymized personal information to a third party overseas (in the US). This is where the fork in the road appears.

If this is simply "processing entrustment that measures our conversions on our behalf," a privacy policy notice is enough. But if Meta also uses that data to optimize its own advertising, that's "third-party provision," and separate consent is required in principle.

Honestly, this isn't a call I can make on my own. It's a matter for legal to decide. So I'm leaving this not as "solved" but as "still unresolved, pending legal review." Better to leave it honestly open than to fill the gap with guesswork.

One more small scar. While compiling the ad-vendor names for the privacy policy, I wrote down "Bizspring" as the operator of the retargeting platform "Mobion." Checking again, it was actually Inliple Co., Ltd. Never write a company name that goes into a legal document from memory. Looking it up takes a minute.

Takeaways: A Checklist for Designing Consent and Pixels

Approaching this with the mindset of dropping in a single e-commerce pixel will burn you. If you're designing consent for a lead-gen business where members and non-members mix, and online and offline mix, the conclusion always converges on "not one switch, but two."

I started with one question, and by the end I found that our entire conversion-tracking structure was inseparable from consent design. You don't lay down all the tracking first and bolt consent on afterward, they have to be designed together from the start. These two problems were never separate to begin with.

A record of consent and pixel gating design for Bigyowon's telecom/rental comparison sign-up service. I've kept the decisions, false starts, and unresolved items (pending legal review) intact, so the next time around I don't wander down the same path again.