Consent as architecture, not paperwork.
Most telemetry tools collect first and let you filter later. Pharen inverts that: consent is stamped on every event and enforced at the point of collection. An event whose purpose isn’t granted is dropped at the boundary — before it’s ever stored or sent.
Consent context on every event
Every event carries the set of purposes granted, and when — present even when the set is empty. There is no unlabeled data in the pipeline.
Opt-in by default
Nothing is granted until you grant it. A freshly started SDK with no purposes collects nothing — it installs its handlers and drops every event. You decide the policy; Pharen provides the mechanism to honour it.
PII never touches the event stream
Traits you pass to identify() route to a restricted attribute store, separate from events — never inlined into properties, never written to logs. The stream carries only a pseudonymous id. The SDK drops obvious identifying keys from track() properties; the server enforces the rule regardless. Even deep-link opens are minimised: the event carries the route path only — never the query string, which can hide tokens or PII.
Tenant and environment stamped server-side
The SDK never sends your tenant_id or environment. Both derive on the server from the ingest key the request authenticates with — an isolation boundary the client can't spoof.
Purposes map to why data is processed, not to product features.
Each event type resolves to exactly one purpose. Grant them at build time in Info.plist for classes you process from first launch, or at runtime — after your consent banner returns. Grants and revocations take effect immediately.
The health purpose gates special-category data and can only be granted at runtime, explicitly — the SDK rejects it in a plist, and it never rides along in a “grant all” banner action.
- telemetry
- Crashes, handled errors, performance
- behavioral
- Sessions, screen views, your track() events
- identity
- Associating activity with a known user via identify()
- content
- User-submitted content, such as feedback
- health
- Special-category / sensitive data — explicit, runtime-only
// Replace the whole granted set (from a banner result):
Pharen.shared?.consent.setConsent(granted: [.telemetry, .behavioral])
// Or one purpose at a time:
Pharen.shared?.consent.grant(.behavioral)
Pharen.shared?.consent.revoke(.behavioral)What this means for GDPR and CCPA — and what it doesn’t.
This architecture exists to make privacy obligations tractable: purpose-limited processing, opt-in collection, immediate revocation, data minimisation on the event stream, and a clean separation of identifying data are structural properties of the pipeline, not settings you have to remember. Those properties map naturally onto GDPR-style consent regimes and CCPA-style opt-out regimes alike — grant() and revoke() are the same mechanism either way. That’s the part Pharen can honestly claim.
Whether your particular use of Pharen complies with the GDPR, the CCPA, or any other regime is a legal determination that depends on your purposes, your users, and your disclosures — it stays with you and your counsel. We’ll never sell you “compliance in a checkbox,” because that isn’t a thing anyone can sell.
Questions your DPO will ask? Good.
We’d rather answer them before you integrate. hello@pharen.ai