Tags
Read time
6 min read
Last updated
July 9, 2026
Growing tired of OneTrust? Let's break you free
Ketch makes consent banner set-up a breeze with drag-and-drop tools that match your brand perfectly. Let us show you.
The five questions that separate a real privacy integration from vendor theater: (1) Who's actually building the integration — the vendor or your engineers? (2) What consumer privacy right does it cover — the easy DSR requests, or the hard consent opt-outs? (3) How does it identify the person — email only, or every system-native ID? (4) Can the vendor prove the integration fired, with a downstream log? (5) Does it keep working over time, with monitoring and alerts? A sixth question — can the vendor give an honest breakdown of automated vs. manual "integrations" — reveals whether their total integration count is real.
"We integrate with that" is the biggest lie in privacy tech.
Every data privacy management software vendor has an integrations page. It is a wall of logos, arranged in a tidy grid, and it is built to do one thing: end the conversation. "Yes, we integrate with that." Potential buyer checks the box, and moves to the next eval question.
I'm begging you: don't move on. Your future self will thank you.
The vendor list of system/app integrations is the most misleading artifact in a privacy software evaluation. "Integration" has been stretched to cover everything from a real-time API call to an automated email to a human requesting a manual task to be completed. Both of these things earn a logo on the list, and they are not remotely the same product. The difference between them is the difference between a privacy program that works, and one that only looks like it does.
I have sat through a lot of these evaluations on both sides of the table. The integrations conversation almost always goes the same way:
The vendor claims the integration exists. The buyer assumes the obvious meaning of the word. Nobody checks the gap between the two until implementation, when the gap turns out to be $$$ engineering work the buyer never budgeted for.
By that time, the contract is signed and the leverage is gone.
So this is an article about how to check. How to tell, before you sign, whether a given integration is real or whether you are buying a manual human task in disguise.
It is tempting to treat integrations as plumbing. A technical detail to sort out after the important decisions are made. That is a critical mistake. Integrations are required to comply with privacy regulations and enforcer expectations.
An opt-out or deletion request are examples of consumer privacy choices. Capturing those choices is the easy part, and just about any tool on the market can do it well. (See my other rant, "the infuriating success of the cookie banner," for more details on this.)
Honoring those opt-outs and requests is the hard part, and it's the part that actually matters. What we're talking about here is the difference between data collection, and data processing.
The opt-out or request means nothing until it flows into systems and apps that process personal data: CRM, CDP, ad platforms, databases. THAT is what an integration is supposed to do. It is the mechanism that turns a privacy choice or request into a privacy outcome.
Consumer privacy regulations like the CCPA refer to this requirement as a flow-down obligation. In the context of deletion and opt-out requests, businesses must notify and/or update downstream vendors wherever relevant consumer data is processed.
Implement integrations correctly, and your program scales with software. Do it wrong (or not at all) and it scales with headcount, because somewhere a person is manually forwarding requests, logging into god knows how many consoles, and hoping nothing was missed.
One of our customers, a quick-service restaurant business north of $10B in revenue, automated 95% of its data subject request activity and now runs the entire program with half the operational staff it used to need. That is what real integration buys.
An integration that captures a choice but never carries it downstream is an unaddressed liability, sitting in a system you told a regulator you could control.
Here are the five critical questions about integrations, and exactly why you must address each one. HubSpot, Segment, Snowflake, you name it: ask these questions about any integration that matters to you, and you'll quickly find out if your vendor's list of integrations is real or theatre.
This is the first and most clarifying question, because when you trace it all the way through, the honest answer is rarely the vendor. It's you.
When a vendor says the word "integration" to you, there are a few things they might mean.
The vendor owns the connection end-to-end and you configure it with clicks. The vendor hands your engineers an API and a set of docs and wishes you luck.
The vendor "fires a webhook" when something happens (a polite way of saying it notifies your engineering team, and then your engineering team writes the code). The vendor's software triggers an email to a human being at the destination company and waiting for them to act.
Three of those four are you doing the work. Only the first is the vendor doing the work.
Be especially alert to the webhook and its respectable-looking cousin, "here's our API." 👀
Neither is a bad thing on its own. A webhook or an open API is exactly what you want when your own developers have a specific, custom case they've decided to build for, and want programmatic control on their own terms. That's an intentional choice your team makes because it serves a need only you can see.
The problem? Lots of systems and apps should not require a custom build. When your vendor says "we fire a webhook" or "we expose an API," that's vendor speak for: here are the parts, now you assemble. It sounds like a feature, but they're transferring the work and the liability to your team.
Let's use Facebook as an example. There is NO good reason you should have to write code to connect a privacy platform to Facebook. Facebook is a commodity destination that nearly every business needs, and building and maintaining an integration should be the privacy vendor's job.
Most privacy vendors will read the tags out of your tag manager (like GTM) and present them in a tidy interface for you to classify. That is genuinely useful, and almost every vendor can do it. But classifying a tag isn't the same as enforcing the rule.
In most products, after your privacy team finishes classifying, someone on your side still has to go into the tag manager and hand-build the consent trigger that actually gates the tag. The platform read your tags. It didn't write the rule back. That last step, the one that does the actual work, is yours, forever, every time a tag changes. If you're not sure how exposed you are here, a tracker and cookie scan will show you exactly what's firing without a corresponding enforcement rule.
Ask: "Walk me through the individual integration setup, step-by-step. If you have APIs and webhooks that's great, but it's not enough information for me to understand the integration setup LOE. To make this connection do its job, does someone on my side have to write and maintain code?"
All consumer privacy rights are not created equal. Many vendors solve for the easy ones and obfuscate the harder ones.
Broadly, there are two categories of rights to worry about when it comes to integrating with your systems and apps.
Access and deletion requests are the obvious reason to integrate with data systems. Pull the data, return it or delete it, confirm. Many vendors can do this for most systems. If a vendor is going to be good at anything, it will be this. So when a vendor's integration story leans heavily on access and delete, they are showing you the part of the test everyone passes.
Do Not Sell/Share (DNS) and consumer opt-outs is the #1 most-enforced consumer privacy right today. (See Honda, Disney, and SlingTV for evidence, per California's official CCPA enforcement guidance.) Regulators require businesses to give consumers a frictionless, one-click right to opt-out of sell/share.
When we say "consent integration" we're talking about exactly this: complying with the right to opt-out. (As opposed to access/delete integrations, defined above.)
Most vendors define "consent integration" as blocking a tag in the browser. Consumer opts out of sell/share; brand stops firing associated tags/trackers. The problem? Blocking a tag from collecting future data does nothing about the consumer's data already sitting inside business systems.
Privacy regulations require you to reach into downstream data processing systems to stop processing that consumer's data. You cannot do that by blocking a script on your own website.
You do it with a server-to-server API call into the platform, using the identifier that platform knows the person by, that changes how the already-collected data is allowed to be used. That is a real consent integration. It is hard to build, and very few vendors do it.
When a vendor's consent integration story doesn't hold up, it usually falls into one of three patterns:
Ask: "Show me, live, an opt-out request reaching one of my actual downstream systems through an API, using that system's own identifier, with no custom code, and show me the data actually change on the other side."
This is the question buyers almost never ask. It is the one that quietly kills more implementations than any other.
Most vendors assume email is the universal key. The whole integration model rests on the idea that you opt out [email protected] and the platform fans that email out to every connected system.
The problem is simple: many data systems do not rely on email to identify a person's data.
Your analytics tool knows a device ID. Your CDP knows an anonymous ID it generated. Your messaging platform knows its own internal ID.
None of these IDs is the email. If your privacy vendor centers consumer identity on email, you will never be successful in achieving comprehensive opt-out or deletion requirements.
The reason this matters so much is that nobody discovers the gap during the sales cycle. It surfaces months later, when the opt-out that looked like it worked turns out to have reached almost nothing, because the identifier never matched. Getting the right identifier is real work, and it has to happen at the moment consent is established, by capturing whatever identifiers are present on the page and tying them together.
When you stack up privacy vendors, you'll see three generalized answers to this challenge.
Ask: "A consumer opts out and I need to suppress them in a system that uses a device ID, not an email. How does your platform get that device ID, and who does the work to connect it?"
This is the requirement that regulators care about the most, and almost no one asks about.
Look closely at the enforcement record and a pattern jumps out. Targeted companies had something that looked like an opt-out mechanism. There was an opt-out webform. There was a banner. On the integrations page, the connection existed. What they could not produce was evidence that a specific person's choice actually changed what happened to their data downstream, and in plenty of cases the honest reason they could not produce it is that it never did.
That is the theater this whole piece is about, and proof is how it gets exposed. Without a downstream record, you cannot tell a real integration from a convincing imitation, and neither can a regulator. The missing proof is not a separate problem from the broken integration. It is the thing that lets a broken integration pass for a working one, right up until someone asks.
So an integration you cannot produce a record for is, for regulatory purposes, an integration that did not happen. The question is not whether the call goes out. It is whether, when a regulator or a plaintiff's attorney asks you to prove that this named person's opt-out reached this named system, you can answer.
Most platforms can show you a browser cookie with a timestamp. Almost none can show you the downstream API log: which identifier was sent to which system, whether the call succeeded, and if it failed, why. That log is the difference between a defense and a settlement.
Ask: "A regulator asks me to prove this specific person's opt-out reached this specific ad platform. Can you produce that record, with the identifier and the result of the call, in thirty seconds, without filing a support ticket?"
Integrations are not a one-time install. Unfortunately, there are many minor actions that can inadvertently cause an integration to stop working.
Destination systems change their APIs. You add a new tag. You republish a banner.
Any of these can quietly break a connection that worked perfectly on the day you went live. Some platforms even turn routine privacy operations into breakage by design, wiping stored preferences every time the configuration is republished, so that fixing a typo in your banner silently un-suppresses every person who had opted out.
The right question is not "does it work?" Any vendor can show you a demo that works. The right question is, "how do I know if it's still working next quarter?" Someone, or something, has to watch the connection and flag for issues.
Ask: "Six months from now, if this integration silently stops firing, how do I find out? Who monitors it, and do I get an alert, or do I get a fine?"
Once you have the first five questions answered, it's time to revisit where we started this article: that impressive-looking list of all the integrations your vendor claims to have.
A vendor's total number of integrations is nearly always a blended number, quietly combining three very different things:
True, automated API connections that do the work for you. Integrations your own engineers have to build. "Direct contact" connections where the software emails a human at the vendor and waits, sometimes for a week or two, for them to act.
If your goal is scalable automation, only the first category counts. The other two are headcount and hope, wearing the costume of automation. When a vendor leans on the size of the number, that is the moment to make them decompose it.
Ask: "Of that total, how many are fully automated API connections, how many require my team to build something, and how many are 'you notify a human and wait'? Give me the breakdown for the specific systems in my stack, not the total."
There is one more trap, and it is the one I most want buyers to internalize, because it is invisible by design.
The demo is theater. When you sit in a proof of concept and watch an opt-out flow beautifully into your CDP in real time, you are watching a result. You are not necessarily watching the product.
It is common, almost standard, for a vendor's sales engineer to hand-build a one-off bridge behind the scenes to make that moment land. A custom script. A bit of glue code. A manual step off-screen. The opt-out really does reach the system, live, in front of you, but none of it is the productized, configurable integration that ships to customers. You are being shown what is possible with the vendor's engineering effort, and you will be sold what is available with yours.
This is not always nefarious. Sometimes the SE is genuinely trying to show you the art of the possible. But the effect on your evaluation is the same either way. You see custom code do the work, and you hear "integration," and you connect the two, and you are wrong.
The defense is simple and you should use it every time. Ask, directly: "Is what I just saw the standard, configurable integration that every customer gets, or was anything built specifically for this demo?" Then ask to watch it set up from scratch, in the admin interface, by configuration, with no one touching code. Then ask for the answer in writing. A real integration survives all three. Theater does not.
Take these questions into your next vendor conversation, verbatim. The quality of the answers will tell you more than any wall of logos.
I will be direct about this: the scorecard above is the one we built Ketch to pass.
Here's how we approach privacy integrations:
None of that is the point of this piece. (Although we're happy to discuss it if you're interested.) The point is that you should demand all of it, from whoever you choose.
Integrations are where privacy programs are won or lost. They deserve more scrutiny than a grid of logos. Ask the questions, watch for the custom code, and make the vendor show you the work.
