Your Power Users Are Living Double Lives. Your Dashboards Don't Know It.

Based on the research ofMingzhang Yin, Ziwei Cong, and Jia Liu, "Unraveling Multifaceted User Preferences on Digital Platforms: A Bayesian Deep-Learning Approach," Marketing Science, 2026

Mingzhang Yin, Ziwei Cong, and Jia Liu built a Bayesian deep-learning model to test what happens when you stop treating a user's consumption and their contribution as separate problems. Applied to a large knowledge-sharing platform, their model jointly estimates both activity types inside one framework, recovers factors that are semantically interpretable rather than opaque embeddings, tracks how those preferences drift over time, and scales to a full platform's user base through stochastic variational inference. Against benchmark factor models built the conventional way, one model for consumption, a separate one for contribution, the joint model wins on both factor quality and out-of-sample predictive fit. The paper is a methods contribution: it does not report a field experiment or a causal estimate of revenue lift, and its authors have not published the specific numeric margin by which the joint model outperforms, only that it does so on both interpretability and fit, tested against standard factor-model benchmarks. But the architectural claim underneath it is the part operators should sit with: the behaviors you have been modeling separately carry information about each other that a split system structurally cannot see.

The Platform That Splits Its Own Users in Two

Most content and knowledge platforms do not run one user model. They run two, built by different teams, optimized for different goals, often reading from different warehouses. A consumption model watches clicks, dwell time, and scroll depth to feed the recommendation feed. A contribution model watches posts, answers, and edits to feed a creator dashboard, a reputation score, or a payout calculation. Nothing forces these two systems to compare notes, and in most stacks nothing does.

That split tracks a split in how platform operators have long thought about their users. Jakob Nielsen's 2006 description of online-community participation, now widely known by its shorthand the "90-9-1 rule," observed that in most communities a small minority of members account for a disproportionate share of contributions while the large majority mostly watch. The exact ratios vary by community and are better treated as a heuristic than a fixed law, but the underlying pattern Nielsen pointed to, that platforms contain a mass of mostly-consuming users and a much smaller mass of mostly-contributing users, has shaped two decades of product thinking. Build the feed for the consumers, since there are more of them. Build a different set of tools for the contributors, since they are the ones producing what gets consumed. Treat the two populations, and therefore the two models, as different problems.

Substack's own product architecture makes that split literal rather than implicit. The company's Reader app, built around the newsletter-reading experience, was launched as a dedicated reading surface, and its own writer FAQ is explicit that writers cannot publish a post from inside the app; an in-app read even counts toward a writer's stats the same way an email open does, rather than flowing through any separate behavioral pipeline. Writing and publishing still happen through the web dashboard. The product decision is defensible on its own terms, a focused reading experience is a real feature, but it is also a visible example of the industry default: route the reading behavior one way, the writing behavior another, and let each system optimize in isolation.

What the Joint Model Finds That the Split Model Cannot

The mechanism in Yin, Cong, and Liu's paper is specifically about what that isolation costs. A model trained only on consumption data can tell you what a user tends to click. A model trained only on contribution data can tell you what a user tends to post about. Neither one, on its own, can represent the fact that what someone chooses to read and what they choose to write are generated by the same underlying, evolving set of interests, expressed through two different channels at two different moments. The paper's Bayesian deep-learning approach, built to jointly capture both activity types with temporal and cross-activity dependencies, is explicitly designed to recover that shared structure rather than discard it at the point where the two data streams are normally forked into separate systems.

That the resulting model outperforms single-activity factor-model benchmarks on both interpretability and out-of-sample fit is the empirical case for why the shared structure matters: it is not a redundant signal the split system was safely ignoring, it is predictive information the split system was leaving on the table. The paper's own managerial framing is blunt about what that means operationally: model a user as a single many-sided actor whose consumption and contribution are linked, not through two disconnected dashboards whose outputs you reconcile by hand afterward, if you reconcile them at all.

The behaviors a platform has been modeling as two separate populations may be two separate signals from the same person.

The Cold-Start Case Nobody Is Measuring

The clearest place the split architecture breaks is the moment a user's role changes. A long-time reader decides to write their first answer, post, or review. In the vocabulary of recommender-systems research, this moment is a cold-start problem: when a system has little or no history for a user along a given dimension, it typically falls back on generic defaults or asks the user to rebuild a profile from scratch, exactly the standard characterization of the user cold-start case in the recommender-systems literature. A split architecture experiences that fallback literally. The contribution model has never seen this account post before, so it has nothing: no topic affinity, no audience fit, no sense of what this person is likely to be good at writing about. It treats a ten-year reader as a brand-new contributor, even though the platform's own consumption model has been accumulating a rich, specific picture of that person's interests for a decade.

A joint model, by construction, does not have to start over. If consumption and contribution preferences are modeled as expressions of one underlying, time-varying set of interests, then a decade of reading behavior is already a strong prior on what this person will be worth reading when they start writing, and conversely a new piece of writing is informative about what that same account is likely to want recommended back to them. The paper's claim that its factors are interpretable and track preference drift over time is what makes that transfer usable in practice rather than just theoretically present: an operator can inspect what the model believes about a user and watch that belief update as the user's role shifts, rather than treating the shift as an unmodeled event that resets the clock.

The Managerial Takeaway

The paper's own framing is the right place to end: platforms should model users as many-sided actors whose consumption and contribution are linked, not as two disconnected populations measured by two disconnected dashboards. That is a modeling claim, not a growth-hack claim, and the authors are explicit that their contribution is methodological, a model that outperforms standard factor-model benchmarks on fit and interpretability, not a reported revenue or retention lift from deploying it in production. But the practical implication for any platform that separates its reader analytics from its creator analytics is concrete. Every reader is a potential future contributor, and the platform's own consumption data is sitting on exactly the information a contribution model would otherwise have to acquire from scratch. Every contributor was a reader first, and the preferences revealed in what they chose to write are informative about what they, and people like them, should be shown next. Treating those as two separate questions, answered by two separate teams with two separate models, is not a neutral default. It is the architecture choice that throws that signal away before anyone gets a chance to use it.