Zero-Signal Recommendations: How to Personalize Before the First Click

TL;DR.

• "Zero signal" is stricter than cold start — it means no interaction history, no linked accounts, no demographic form, nothing.
• Popularity baselines are not personalization; they optimize for the median user and damage long-tail discovery.
• Item-side content embeddings, knowledge graphs, and synthetic user clones let you generate a prior without any behavioral data.
• By 2026, cross-domain transfer and contextual inference at session open can reduce time-to-personalization from days to milliseconds.
• If you only remember one thing: the first recommendation a new user sees sets their expectation of your system — serving a popularity list there is a product decision, not a fallback.

Every recommendation team has a cold-start strategy. Most of them are popularity lists with a gradient of embarrassment about it. A new user opens your app, gets a top-10 chart from last week, and the system logs "personalized recommendations served." This is the zero-signal problem: not just that we lack behavioral history, but that we have convinced ourselves that lack of personalization is an acceptable default.

The truth is that zero-signal is rarely zero-information. A user-agent string, a referral URL, a device locale, an onboarding selection, the time of day — these are signals. The question is which techniques can turn weak, sparse, and indirect evidence into a ranked list that is meaningfully better than the global popularity prior. By 2026, there are several, and most teams are using at most one.

What Does "Zero Signal" Actually Mean?

Zero signal is not the same as cold start. Cold start typically refers to any new user or new item with insufficient interaction data. Zero signal is the strict subset: a user who has just created an account (or who is browsing anonymously), has no linked third-party accounts, has not completed an onboarding questionnaire, and has produced zero clicks, dwell events, or explicit ratings in your system.

This state is transient — within a session, implicit signals accumulate quickly. But it is also the highest-stakes moment in the user lifecycle. Churn probability is highest on the first session (Nielsen Norman Group, 2024), and the relevance of the first five items seen is a strong predictor of whether a user returns. The zero-signal window is short and consequential.

In production systems, zero signal manifests in three scenarios: net-new users who have never interacted with any product in your ecosystem; cross-product new users who exist in your identity graph from another product but whose preference signals do not transfer; and ephemeral users — anonymous sessions, incognito browsers, kiosk installs — where no persistent identity exists at all. Each requires a different intervention.

Why Popularity Baselines Are Not a Solution

The immediate answer everyone reaches for is the popularity prior: serve items ranked by aggregate engagement (plays, clicks, purchases) across all users, possibly windowed to the last 7 or 30 days. It is not a wrong answer — it is the cheapest correct answer for the average user. The problem is that popularity optimizes for the median preference distribution, which means it actively harms users in the tails of that distribution.

Recommending popular items to a new jazz listener on a music platform means recommending pop. Recommending popular items to a new user of a developer tools marketplace means recommending the most-installed packages, not the packages most relevant to their stack. The popularity baseline is a symptom of treating the absence of user data as equivalent to the absence of user identity — these are not the same thing.

There is a compounding effect. Popularity-first systems create feedback loops: popular items get more exposure, more interactions, and more algorithmic reinforcement. This is well-documented in the recommender systems literature as popularity bias (Abdollahpouri et al., 2019), and it is not only a fairness problem — it is a catalog utilization problem. If 80% of your item catalog is never surfaced to new users, you are losing the discovery value that differentiated your platform from a simple editorial list.

The correct role for the popularity prior is as a regularization signal, not a recommendation strategy. Use it as a tiebreaker between otherwise equivalent items. Use it as a confidence floor when other signals are very sparse. Do not use it as the primary ranker.

Content-Based Bootstrapping With Item Embeddings

The most deployable zero-signal technique in 2026 is content-based filtering seeded from item metadata. If your catalog has structured metadata — genre, tags, description text, author, format, duration — you can embed items into a shared semantic space and build a nearest-neighbor graph without any user interaction data.

The mechanism: encode item metadata using a pre-trained dense encoder (sentence transformers, contrastive fine-tunes of CLIP or similar for multimodal catalogs), project into a vector space, and build an approximate nearest-neighbor index. For a new user, seed the recommendation with a single pivot item — derived from whatever weak signal exists at session open (the landing page they came from, a search query, a genre selection) — and return the k-nearest neighbors in embedding space.

This is not collaborative filtering. You are not inferring "users like you also liked." You are saying: "this item is semantically similar to your entry point." The quality is bounded by your metadata completeness and your embedding model's semantic alignment with your domain.

Several refinements matter. First, semantic similarity in embedding space is not the same as preference similarity — items can be similar but serve different intent modes (a user searching "Django" might want a web framework tutorial or a Tarantino film). Second, embedding models trained on general corpora underperform on narrow domain vocabularies; fine-tuning on in-domain text improves significantly. Third, nearest-neighbor in high-dimensional space degrades with catalog size — use HNSW or IVF-PQ indices rather than flat search at scale (Malkov & Yashunin, 2018).

The advantage of content-based bootstrapping is that it requires no user data, scales with catalog size, and produces explainable outputs: "because you searched for X, here are items matching that topic." The disadvantage is that it is structurally unable to surface serendipitous discoveries — it cannot recommend something a user did not already signal interest in.

Knowledge Graphs as the Cold-Start Scaffold

Content embeddings capture surface-level similarity. A knowledge graph captures relational structure — and for zero-signal recommendation, that relational structure is often what differentiates a good recommendation from a merely similar one.

A knowledge graph for recommendations encodes items as nodes, with typed edges representing semantic relationships: a film directed_by a director, a director influenced_by another director, an actor known_for a genre. For a new user with a single implicit signal — say, a click on a Coen Brothers film — a knowledge graph traversal lets you reason across multiple hops: this film → this director → directors with similar cinematography → films in that style. This produces a richer prior than flat embedding similarity.

The technique is not new. KGAT (Wang et al., 2019) demonstrated that graph attention networks over knowledge graphs significantly outperform collaborative filtering in low-interaction regimes. The insight is that the knowledge graph encodes community structure that took humans decades to curate — it is a form of prior knowledge about item relationships that does not require user interaction to be useful.

In practice, the knowledge graph does not need to be custom-built. Wikidata, MusicBrainz, IMDB's public graph, Open Library — depending on your domain, large-scale open graphs can be aligned to your catalog and traversed at query time. The challenge is entity alignment (matching your internal item IDs to graph entities) and traversal latency (multi-hop graph queries at p99 in under 30 ms requires caching or precomputed neighborhoods).

Knowledge Graph + Embedding Hybrid

The production pattern we use at ×marble is a two-stage system: embed items into a dense space using content metadata, then re-rank the nearest-neighbor candidates using graph-distance scores as a feature. This combines the recall breadth of approximate nearest-neighbor search with the precision boost from relational structure. For zero-signal users, the graph features carry more weight; as behavioral signals accumulate, the collaborative features take over.

Synthetic User Clones for Structural Priors

Content and graph techniques work well when you have a clear entry point — a search query, a landing page, a category selection. They break down for the truly anonymous user: someone who opens your app directly, skips any onboarding, and waits for you to show them something.

For this case, the most powerful technique in 2026 is synthetic user modeling. The idea: pre-compute a set of representative latent user profiles — synthetic "clones" — derived by clustering your existing behavioral data. These are not real users; they are statistical archetypes that represent the distinct preference modes in your user base.

At session open, the system assigns a new anonymous user to one or more synthetic clones based on whatever weak contextual signals are available: device type, operating system, referral source, locale, time of day, session entry point. The assignment is probabilistic. A new user from a referral link clicked on a curated jazz playlist gets a high prior weight on the "jazz listener" synthetic clone. A new user opening the app directly on a Tuesday morning gets a distribution across several plausible clones.

The synthetic clone's precomputed preference vector then serves as a stand-in for the missing personalization signal. This is conceptually related to DropoutNet (Volkovs et al., 2017), which demonstrated that training a recommendation model to handle missing user features (by randomly dropping input features during training) produces models that gracefully degrade to archetype-based recommendations when user features are unavailable.

The practical limitation is that synthetic clone assignment is a classification problem with low-confidence inputs. A misassignment early in the session produces a bad prior that may take many interactions to correct. The fix is to make clone assignment bayesian: maintain a posterior over clone assignments and update it with each interaction, rather than committing to a single assignment at session open.

Cross-Domain Transfer and Contextual Inference

Zero-signal in one product does not mean zero-signal everywhere. If a user has a profile in your ecosystem from another product — or if they arrived via an OAuth login from a third-party platform — their signals elsewhere encode information about their preferences.

Cross-domain transfer for recommendations exploits the correlation between preference structures across domains. A user's music listening patterns correlate with their video preferences (Cantador et al., 2015). A user's reading history correlates with their podcast consumption. These correlations are not deterministic, but they provide a Bayesian prior that is strictly better than the population prior.

The architecture: train a cross-domain encoder that maps user behavioral embeddings from a source domain (where the user has history) into the target domain's embedding space. This is a transfer learning problem, and the standard approach is a shared latent space with domain-specific decoders, trained on users who appear in both domains.

Even without cross-domain identity data, contextual inference at session open provides signal. A user accessing your platform from a developer-focused newsletter carries different prior than a user from a general social media share. A user opening your app at 6 AM on a weekday has different intent than one opening it at 10 PM on a Saturday. Device type correlates with content format preference. Session entry point (direct, search, referral) correlates with intent mode.

None of these signals individually is strong. Together, they constitute a feature vector that a lightweight model — logistic regression, gradient boosted trees, or a small neural net — can map to an initial preference distribution with meaningfully lower entropy than the uniform prior. The key engineering requirement is that this inference must happen at session open, before the first recommendation is served, and must complete in single-digit milliseconds.

What About Onboarding Questionnaires?

The obvious alternative to all of the above is to ask users directly: "what are you interested in?" Onboarding questionnaires are a legitimate technique, but they carry a cost that most product teams underestimate.

Completion rates for onboarding flows drop sharply after 2-3 questions (Mixpanel Benchmark Report, 2024). Users who skip onboarding are disproportionately the users who arrived with strong intent — they wanted to use the product, not answer questions about it. Forcing an onboarding gate on high-intent users is a churn mechanism.

The correct use of explicit onboarding is narrow: capture a single high-signal preference that the system cannot infer (preferred language, explicit interest in a niche category), present it as a choice with immediate visible impact on the recommendations shown, and make it skippable. Do not treat the onboarding questionnaire as a substitute for the implicit inference pipeline. Treat it as a fast-path confirmation signal that helps the implicit system converge faster.

Onboarding selections should be treated as weak labels, not ground truth. Users frequently select items in onboarding that do not reflect their consumption behavior — they pick what they aspire to like, not what they actually engage with. Weight them accordingly.

Where to Start

If you are building zero-signal recommendation capability from scratch, the priority ordering is as follows:

1. Instrument the entry point

Before you can use any contextual signal, you need to capture it. Instrument every session open event with: referral source (with UTM parsing), device type, locale, client timestamp (for time-of-day features), and session entry point (which item or category page triggered the session, if any). This instrumentation is a prerequisite for every technique described above.

2. Build content embeddings for your catalog

If your catalog has metadata, embed it today. Use a domain-adapted sentence transformer or a fine-tuned CLIP variant for multimodal catalogs. Build an HNSW index. This gives you a content-based fallback that is strictly better than popularity for users with a known entry point.

3. Pre-compute synthetic clone prototypes

Cluster your behavioral data (matrix factorization embeddings are a good starting point) into 20-100 archetypes. Store the precomputed recommendation lists for each archetype. Build a classifier that maps your session open feature vector to a distribution over archetypes. This is your zero-signal fallback for truly anonymous users.

4. Add knowledge graph re-ranking

Once the content-based and synthetic clone pipelines are stable, add graph-distance as a re-ranking feature. Start with an open graph (Wikidata, domain-specific ontologies) rather than trying to build a custom one. The entity alignment work is real, but it pays off in precision on long-tail catalog items.

5. Measure convergence, not first-impression accuracy

The right metric for zero-signal recommendation is not how good the first recommendation was — it is how quickly the system converges to accurate personalization as signals accumulate. Track the interaction count at which per-user NDCG reaches your steady-state baseline. Compressing that convergence time from 50 interactions to 5 is the real product goal.

The zero-signal moment is not a failure state to be tolerated until real data arrives. It is a product surface that encodes your system's confidence in its own priors. Teams that get this right build systems that feel intelligent from the first session — which is the only session that matters for determining whether there will be a second.