Private-group reading should stay out of public recommendations

As a moderator of pseudonymous communities, I think private-group reading, clicks, and dwell time should be excluded by default from models that shape a member’s public feed, suggested contacts, or social graph. Recommendation systems legitimately use behavioral signals, but a silent visit is weak evidence of a durable public interest: it might be research, support-seeking, curiosity, or a deliberately compartmentalized identity.

The convenience tradeoff is real. Better cross-context recommendations can feel useful. But they can also reveal an inferred affiliation through what gets surfaced, or collapse a temporary pseudonym into a permanent account profile without an explicit disclosure. That is a privacy failure even if nobody publishes the group membership.

I’d start with separate recommendation histories for public activity, private groups, and pseudonymous identities, with an auditable record of which signals may cross the boundary. Opt-in transfer could preserve convenience. Would you implement the boundary differently, or reject it as too costly?

The separate feature stores are straightforward; the hard part is preventing indirect joins. Shared device identifiers, contact graphs, and account recovery paths can quietly recreate the same bridge. An auditable policy needs to cover derived features too, not just raw clicks.

I agree with the default, but I’d make the control legible rather than burying it in settings. “Use my private-group activity to improve public recommendations” is understandable. A dozen scope toggles are not. The product has to explain what users gain and what can leak.

Opt-in is necessary but not sufficient. Consent obtained after a recommendation exposes an affiliation is too late. I’d also require aggregate leakage tests: can an observer infer private participation from the outputs, even when the source feature is supposedly excluded?

The distinction between “should” and “does” matters here. The available evidence supports that platforms use behavioral signals and that profiling can suggest people or content. It does not establish a universal practice of importing private-group dwell time. The proposal is sensible, but should remain a proposal.

There’s a social norm hiding in the implementation. People often read in a group because that audience feels bounded, not because they want the topic attached to every context. If the interface makes the boundary visible at the point of joining, users may understand the tradeoff better.

The strongest objection is discovery. Someone joins a private hobby group and then gets no related public suggestions, even when they would welcome them. I’d avoid a blanket prohibition and make each context’s default explicit: private-to-private by default, private-to-public only by deliberate opt-in.

This is a good fit for scoped identities rather than one universal user vector. Keep the representations separate, then permit a signed, revocable handoff of selected interests. Revocation should stop future use; pretending it can erase every already-trained aggregate would be misleading.

“Dwell time” deserves caution. Time on a page is especially ambiguous: reading, distraction, an open tab, or distress can look identical. Even inside a public context, treating it as a confident interest signal seems questionable; across privacy contexts, the case is weaker.

Implementation question: do you need separate models, or just separate input gates? A small service could label events with a privacy scope and reject cross-scope feature reads. Fewer duplicated models means cheaper operations, though the enforcement point becomes very important.

Don’t forget support and moderation tooling. If staff can export or search a unified activity history, the recommendation boundary is only cosmetic. Retention, logs, abuse investigations, and backups need the same scope rules or exceptions will become the real system.

The old answer was not to measure every pause. “Useful” is doing too much work here. If a person wants public recommendations from a private interest, let them say so. Default inference is convenient right up until it is embarrassing.

For an enterprise deployment, I’d want a data-flow map and an audit report that names every downstream consumer: ranking, contacts, ads, account linking, exports. “Private” cannot mean only the front-end view while internal systems retain unrestricted access.

I’d ship two modes: strict separation as the default, and a simple “blend this interest publicly” action with a clear undo. That gives personalization a conversion path without making every quiet click a permanent identity decision. The metrics should include unwanted inference, not just engagement.