A useful data profile view needs sources, inferences and controls
Yes: when a companion app builds a persistent data profile, users should be able to inspect a practical version of it. A useful view goes beyond account fields. It separates information the person supplied, activity the app observed, conclusions the system inferred, and settings that change what happens next. Each item should show its source, last update, purpose, affected feature and available control. This is not a demand to expose security secrets or model code. It is a way to notice stale or surprising assumptions before they silently steer memory, recommendations, prompts or visibility.
Separate supplied, observed and inferred data
Start with three columns. Supplied data includes profile fields, selected interests and journal text. Observed data includes feature use, clicks, session timing and interaction history disclosed by the service. Inferred data includes a preference, routine, topic label or likely interest calculated from the other columns. A fourth column can hold system state such as account tier or enabled feature, because it may change the experience without being an inference. Keeping these origins separate prevents a guess from looking like a fact the user explicitly stated. The ICO describes profiling as analysis that classifies or predicts aspects of a person from multiple information sources.
Require seven fields for every profile item
Every visible profile item needs seven fields: the value, its kind, source, creation or update date, stated purpose, product effect and available control. “Enjoys travel” is incomplete if the user cannot tell whether it came from one saved choice, many conversations or a connected service. Confidence may be shown when meaningful, but it must not become a decorative score that hides the source. The ledger should also say whether the item is account-wide, device-only or limited to one character or feature. An absent field is a specific question, not evidence that the missing path does not exist.
Connect each item to a visible product effect
A profile matters because it changes something. Link each item to the memory, ordering, suggestion, notification, audience, advertisement or feature decision it actually affects. Google’s My Ad Center is one current example that exposes categories and lets people control some account, activity and area inputs used for ad personalization. Android’s shared-data setting shows another important boundary: a device index can have per-source controls while separate account activity settings continue to exist. A companion app should similarly avoid presenting one switch as control over unrelated personalization systems.
Handle correction, deletion and reset as different actions
Correction, deletion, reduced personalization and a full reset solve different problems. Correcting “prefers evening reminders” should update a wrong item while preserving unrelated choices. Deleting a source conversation should state whether derived labels are also recalculated. Turning off future personalization should explain whether the old profile remains stored. A reset should list what it clears, what it keeps and which features will rebuild new observations. Where applicable, official data-access and correction routes provide another path, but the article does not assume identical rules in every region. The immediate product test is whether ordinary controls have clear, narrow consequences.
Test refresh behavior with one harmless change
Use a harmless refresh test. Change one explicit preference, note the time, and observe which profile item and feature change. Then remove or reverse that preference and check whether the item updates, remains with a new status, or requires a separate reset. Do not flood the app with repeated artificial activity; one controlled change is easier to interpret. Record the account, device, feature and version. If an inference remains, ask whether it has other sources rather than declaring the system broken. A good interface reveals enough provenance to distinguish delayed refresh, multiple evidence sources and an unresponsive control.
Review profile visibility after every feature change
Keep a profile receipt after onboarding and after adding memory, voice, images, integrations, community features or model-improvement settings. For each new surface, ask what supplied, observed and inferred fields it adds; who can see them; what they affect; and where they can be corrected, removed or reset. Compare the profile view with export data and current privacy explanations, because none of those views necessarily contains everything by itself. The unique value of the seven-field ledger is traceability: it turns a vague “the app knows me” impression into items that can be inspected, challenged and intentionally kept.
Common questions
Should a profile view reveal the app’s model code?
No. It should reveal meaningful personal data, sources, uses, effects and controls without exposing security-sensitive implementation details.
Is deleting a conversation the same as resetting its inferences?
Not necessarily. The service should explain whether derived items are recalculated or need a separate control.
What if an inference is correct?
You may keep it, but you should still be able to see its source, effect and scope before relying on it.