Building an audience
An audience is a set of real reviewers, and the personas clustered out of them. Everything else in userken points at an audience: a survey runs against one, a focus group is staffed from one, an accuracy report is scored on one.
Built-in audiences
You do not have to build anything to start. Every app in the catalogue and every category is already an audience, kept current as reviews arrive:
- One per app, for example the reviewers of one news app. Its personas are that app's personas, weighted by how many reviews sit in each persona's star band.
- One per category, for example every news app at once. Its personas are the union of the member apps' personas, each scaled by that app's share of the reviews and then renormalised.
Built-in audiences are read-only and free to question on every plan. They appear at /app/audiences alongside anything your workspace has saved, and an audience shows no personas rather than a persona list when its app has not been clustered yet.
The builder
The builder at /app/audiences/new narrows the corpus with filters. Preview is free and instant: it counts the reviews, shows the star histogram, the app and platform mix, the date range, the top themes and ten sample reviews, with no model call at all. Keep adjusting until the preview looks like the people you mean.
Filters
| Filter | What it does |
|---|---|
| Apps | One or more apps from the catalogue. |
| Categories | Whole categories. An audience may span several. |
| Platform | Apple, Google Play, or both. |
| Country | Review country codes, where the store reports one. |
| Star range | A contiguous rating range, 1 to 5, inclusive. |
| Date range | Last 90 days, 12 months, 24 months, or all of it. |
| Themes | Theme tags, matched as any-of or all-of. |
| Keywords | Case-insensitive text matches, any of which counts. |
| Excluded keywords | Drops any review containing one of them. |
| Semantic query | A sentence. Reviews are ranked by meaning, using embeddings, not by matching words. |
| Minimum length | Drops very short reviews. Forty characters by default, which removes most one word ratings. |
Describe your audience
Instead of setting filters by hand, write a sentence such as Android users of financial news apps who complain about login, last 12 months and press Suggest filters. userken sends the live catalogue (its categories, apps, themes, platforms, countries and date range) with your sentence in a single model call, then checks what comes back: any app, category or theme that does not exist is dropped and reported as a warning rather than silently accepted.
If the suggested filters select too few reviews to build on, they are relaxed one step at a time, in a fixed order, and the page tells you which step it took: keywords are dropped first, then the rating range is widened, then the date range. You get filters you can edit, not a black box.
Building personas
A saved audience starts as a draft. Building it turns the reviews into personas:
- Selecting. The reviews matching your filters that have embeddings are frozen into a member set, so the audience does not shift underneath a result you already have.
- Clustering. Those reviews are clustered by meaning. The number of personas comes from the size of the audience: three for a small one, rising to eight for a few thousand reviews and up. You can override it. Clusters with fewer than five members are dropped.
- Naming. One model call per cluster writes the persona's name, description, voice and themes from the reviews closest to the cluster centre.
- Storing. Personas are saved with a weight equal to the cluster's share of the audience. The weights sum to one.
The page polls the build and shows the step it is on. Building needs at least 40 usable reviews; below that userken refuses rather than inventing a segment. Refresh re-runs the whole thing against the latest reviews, and editing an audience's filters returns it to draft so a stale persona set is never presented as current.
What a persona carries
A name, a description, a voice, its keywords and themes, its star band, a typical quote from a real review, the number of reviews in the cluster, and its weight. Every survey result and every focus group reply is attributable back to one of these.
Compare and lookalikes
Compare at /app/audiences/{ref}/compare?with={other} puts two audiences side by side: an overlap score, the persona to persona similarity matrix, which segments the two share, which are unique to each side, the themes each over-indexes on, and the difference in star distributions. Use it before assuming two audiences are interchangeable.
Lookalikes rank every other audience, built-in or saved, by how close its centre is to the one you name. It is the fastest way to find out that the audience you just built is nearly the same as one you already had, or that a neighbouring category would answer your question just as well.
Neither costs a model call. Both work on embeddings that already exist.
Refs and MCP
Every audience has a ref, and the ref is what you pass to a tool, a URL or a form:
| Ref | Means |
|---|---|
pub:reuters | One app in the catalogue, by its slug. |
cat:news | A whole category, by its key. |
aud:aud_1a2b3c4d5e6f | A custom audience your workspace built. |
The MCP tools take the same strings. get_audience resolves a ref to its personas and weights; ask_audience and the survey templates take an audience_ref; start_focus_group and get_focus_group_prompt take one too. So does suggest_survey_questions, which is how Claude writes questions in the audience's own vocabulary. See the tool list.
Call list_audiences, or copy it from the address bar: the audience page is /app/audiences/{ref}.