When a user reaches you through different entry points, whose consent record governs — the channel's, or the person's? Profile-based purposes are how you make the person the anchor instead.
June 2026 · 6 min read
Most consent management platforms tie a purpose to a collection point. A web form captures marketing consent. A mobile app captures analytics consent. A branch form captures service-delivery consent. Three entry points, three separate consent records — and no single view of what one actual user has agreed to across all of them.
In the conventional model, a purpose belongs to the collection point where it was configured. If the same person reaches your platform through three different entry points, they might see the same purpose presented three separate times — or not see it at all on a later entry point simply because nobody mapped it there.
A typical version of this: a user signs up on your website, is shown purposes A, B, and C, consents to A and B, and declines C. The same user later downloads your mobile app, which has its own collection point showing purposes A and D. The same user then calls customer care — and the agent pulling up the account has no clear answer for which consent state actually applies.
The consent record is fragmented by channel. The user's actual, current consent position is effectively invisible.
Under DPDPA, that fragmentation is a real exposure, not just an operational annoyance. Section 6 requires consent to be specific and informed. If your consent state is scattered across collection points with no reconciliation, you can't actually demonstrate what processing is authorised for a given Data Principal at any given moment — and that's the exact question a rights request or a Board inquiry will ask.
Profile-based purposes flip the model. Instead of a purpose belonging to a collection point, it belongs to an Asset — a product or system — and follows the person, regardless of which entry point they used to reach it.
When that same Data Principal encounters any collection point within that asset, they're shown the same purpose set, and their prior consent state carries forward automatically. If they already consented to a purpose in an earlier session, they're not asked again unnecessarily. If they declined it, that decline is honoured everywhere, not just on the channel where they gave it.
Collection point-centric, the traditional approach: a purpose mapped to the web form only, a separate purpose mapped to the mobile app only, consent state fragmented by channel, no unified view of the user's actual profile, and rights requests that require manually stitching records together across systems.
Profile-based, the asset-level approach: a purpose mapped once to the asset itself, following the user across every collection point that belongs to it, a single unified consent profile per user, consistent state across web, mobile, branch, and API, and rights requests that get answered from one authoritative source.
Multi-channel enterprises. Banks, insurers, telecoms, and e-commerce platforms interacting with users across web, mobile, branch, and IVR are the clearest case — without a profile-based model, each channel effectively runs its own consent island.
Recurring processing purposes. Marketing, analytics, and personalisation are the purposes most likely to be contested by a Data Principal or examined by the Board. Having a single authoritative consent record, instead of a patchwork of per-channel entries, matters considerably when you're the one responding to that inquiry.
Post-withdrawal handling. When someone withdraws consent, that withdrawal needs to reach every entry point that could still trigger processing under that purpose. A profile-based architecture means there's one record to update, not six separate ones to track down.
Consent refresh campaigns. When a purpose changes or expires, re-consent needs to reach the person — not every collection point independently and redundantly. Profile-based purposes mean you contact the user once, not once per channel they've ever touched.
Take a fintech running three products — a payments app, a credit card platform, and a wealth management service. Profile-based purposes get configured per product, at the Asset level. A user who consents to personalisation through the payments app carries that consent state into every later interaction with that specific product, whether they come back through mobile, web, or an API call. A separate, independent consent state governs the credit card platform entirely — the two don't bleed into each other.
Within each product, though, the user's consent profile stays consistent, complete, and auditable from one single source, no matter how they arrive.
Getting the underlying model right before you build is exactly what our consent architecture design service is for.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation