Every consent management platform links purposes to collection points. A web form captures marketing consent. A mobile app captures analytics consent. A branch form captures service delivery consent. Three entry points, three consent records — and no unified view of what a given user has actually agreed to.
The Problem with Collection Point-Centric Consent
In the traditional model, a Purpose belongs to a Collection Point. If a user encounters your platform through three different entry points, they may be shown the same purpose three times — or not shown it at all on a subsequent entry point because it wasn't mapped there.
A typical scenario: → User signs up via your website. Shown purposes A, B, C. Consents to A and B. Declines C. → Same user downloads your mobile app. App has its own collection point. Purposes A and D are shown. → Same user calls customer care. Agent accesses the system. Which consent state does the agent see?
The consent record is fragmented by entry point. The user's actual consent profile is invisible.
Under the DPDPA, this fragmentation creates compliance exposure. Section 6 requires consent to be specific and informed. If your consent state is fragmented across collection points, you cannot demonstrate what processing is actually authorised for a given Data Principal at any moment.
Profile-Based Purposes: The User as the Anchor
Profile-based purposes invert the model. Instead of a purpose belonging to a collection point, a profile-based purpose belongs to an Asset — a product or system — and follows the user regardless of which collection point they came through.
When a Data Principal encounters any collection point within that asset, the same purpose set is presented — and the consent state from their previous interaction is carried forward. If they already consented to a purpose in a prior session, they won't be asked again unnecessarily. If they declined, that decline is respected across all entry points.
Collection Point-Centric (Traditional)
- Purpose mapped to web form only
- Purpose mapped to mobile app only
- Consent state fragmented by channel
- No unified view of the user's consent profile
- Rights requests require stitching across systems
Profile-Based (Asset-Level)
- Purpose mapped to the Asset
- Follows the user across all collection points
- Single unified consent profile per user
- Consistent state across web, mobile, branch, API
- Rights requests answered from one source of truth
Where Profile-Based Purposes Matter Most
Multi-channel enterprises: Banks, insurers, telecoms, and e-commerce platforms that interact with users across web, mobile, branch, and IVR. Without profile-based purposes, each channel maintains its own consent island.
Recurring processing (marketing, analytics, personalisation): These purposes are the most likely to be contested. Having a single, authoritative consent record — rather than a patchwork of per-channel records — is critical when responding to the Board or a Data Principal complaint.
Post-withdrawal scenarios: When a Data Principal withdraws consent, the withdrawal needs to propagate across all entry points that could trigger processing under that purpose. Profile-based architecture means there is one record to update, not six.
Consent refresh campaigns: When a purpose changes or expires, re-consent needs to reach users — not every collection point independently. Profile-based purposes mean you contact the user once.
How It Looks in Practice
A fintech with three products — a payments app, a credit card platform, and a wealth management service — can configure profile-based purposes per product (Asset). A user who consents to personalisation through the payments app carries that consent state into every subsequent interaction with that product — regardless of whether they access it via mobile, web, or API. A separate consent state governs the credit card platform.
Within each product, the user's consent profile is consistent, complete, and auditable from a single source.