



















Integration sounds super simple. It's just an integration, but they're radically different. Most people that you speak to through buying privacy software will tell you they have integrations, and they probably do. The nature of those integrations has a lot of variance. Most companies that are building integrations with privacy are really focused on, accessing the lead, and they think mostly about email. Where it gets a whole lot harder is when you're thinking about content management, for example. First and foremost, most companies that you're integrating with don't have some magical privacy API that you can program to and say, hey. You know, do not sell, everything is done. That's why this is hard. You actually have to understand the system deeply, what it does, and find the applicable APIs that actually effectuate the objective that the privacy laws require. And that takes a ton of work. Another really key consideration is this idea around identity. Most of systems that you're gonna integrate to don't actually have email address, but they're still in scope. And so if you don't have some way to handshake with that third party and get the identifier that they use to represent the data subject making some consent related request, you are simply not gonna be able to effectuate that do not sell or whatever the consent related objective is. And so when you think about integrations, it's worth going one level deeper with your prospect or even your internal colleagues to think about exactly what you want the integration to do and ask a few questions as to how they do that. And by the way, integration does not count if the documentation says, paste this code snippet on your website and have your developer actually don't do that. Integration should be clickable. They should be simple. And if developers are involved writing code, it just isn't going to be scalable.
