Ketch and Sourcepoint
Migrate off Sourcepoint without forcing every visitor to consent again on day one.
About Sourcepoint
Switching consent management platforms risks showing a fresh consent banner to visitors who already made a choice under the old platform, which is both a worse experience and a real risk to opt-in rates during a transition. The Sourcepoint Consent Migrator is built specifically to avoid that.
Capabilities
How the Sourcepoint Consent Migrator works
The migrator has two components. First, a Local Device Rapid Read (LDRR) reads the Sourcepoint cookie storing a visitor's existing consent preferences and sets that same consent state directly in Ketch. This prevents an auto-initiated Ketch banner from appearing for visitors who already made a choice under Sourcepoint, during the migration window.Second, a Sourcepoint Consent Listener continues listening for Sourcepoint consent events even after that initial read, for as long as an active Sourcepoint script is still running on the page. This lets a site keep rendering the Sourcepoint-branded experience on the frontend during a transition period, while Ketch orchestrates consent behind the scenes.Setup requires entering the Sourcepoint cookie containing the stored consent string, and mapping every Ketch purpose to the applicable Sourcepoint protocol purpose that consent was actually collected under. This migrator is specifically built for the Sourcepoint Cookie Consent script; a different Sourcepoint product may not work as designed, and Ketch Support can advise on migrations involving other Sourcepoint modules.
With Ketch, teams can
- Avoid re-prompting visitors who already consented under Sourcepoint, using the LDRR to carry that choice into Ketch directly
- Keep a Sourcepoint-branded frontend running temporarily while Ketch orchestrates consent behind the scenes
- Map every Ketch purpose to the Sourcepoint protocol purpose it was actually collected under, keeping the transferred consent accurate
The gap
The problem this integration solves
A naive migration off any incumbent CMP creates real friction that a well-built migrator specifically avoids:
02. A hard, all-at-once cutover leaves no room for validating the new platform's behavior against the old one before fully committing
03. Mapping Ketch purposes incorrectly to the Sourcepoint protocol purposes consent was actually collected under risks carrying over an inaccurate consent state
Ketch's migrator resolves the first two by reading and honoring existing Sourcepoint consent directly and supporting a transitional period where both platforms coexist, and addresses the third by requiring an explicit, accurate purpose mapping as part of setup.
Why Ketch
Why teams choose Ketch's Sourcepoint Consent Migrator
Permissioning infrastructure that governs Sourcepoint the same way it governs every other system in your stack — not a one-off connector bolted onto a banner.
Doesn't force visitors to re-consent
Existing Sourcepoint consent choices carry directly into Ketch through the LDRR mechanism.
Supports a real transition period
The Consent Listener lets a Sourcepoint frontend keep running while Ketch takes over orchestration behind the scenes.
Backed by enforcement precedent
Regulators increasingly expect businesses to demonstrate real, continuous consent enforcement, the same expectation a migration needs to satisfy without a gap during the transition itself.
Questions about the Sourcepoint integration
Related reading
Expert insights for teams connecting Sourcepoint
Integrations
Pre-built APIs with 1,000+ systems, apps, and models
Ketch ships connectors and SDKs so consent, rights, and policy flow into your CDPs, warehouses, ad platforms, and AI stack — without a custom data pipeline.
See Sourcepoint permissioning running end to end
Book a demo to walk through rights, consent, and preference orchestration on your stack — or start free and connect Sourcepoint yourself.
Get Started Free
Get started in less than 5 min