What the onboarding questionnaire is for
Before the first message there are questions. Pick a name, pick a look, pick a manner, answer a few things about yourself and what you are looking for. That sequence is doing three separate jobs at once, and only the first one is the one it appears to be doing.
Job one: it writes the character description
Your answers are converted into text. Not into settings in any deep sense — into a paragraph or a structured block of sentences describing who this character is, how it speaks, and what it knows about you. That text is then included with every single request to the model for as long as the character exists.
This is why the questionnaire has the reach it does. It is not configuring a system; it is writing the document the character is made of. The character has no existence apart from that description and the history, so the questions you answered in ninety seconds are a large fraction of everything the product knows about who it is meant to be.
It also explains a specific frustration. If you chose a trait during setup and the character does not display it consistently, the trait is a line of text competing with a growing conversation history for the model’s attention. Nothing enforces it. It is a written instruction, weighted against everything else in the request.
Job two: it collects a profile
The same answers are account data. Age band, relationship status, interests, what you said you wanted from the product, mood at signup, and whatever else was asked. Some of it is needed to build the character text. All of it is stored.
This is worth naming because a form that looks like character customisation is also a survey, and the two purposes are not distinguished at the point you fill it in. Profile fields of this kind support the ordinary work of running a subscription business: segmentation, lifecycle messaging, deciding which cohort sees which tier. It sits alongside everything else the app collects that is not the conversation.
None of that requires bad intent to be true. It requires only that the fields exist and that a product team has questions about its users.
Job three: it gets you invested before you have used anything
Setup flows across consumer software are built to secure effort early, because effort predicts continuation. Naming something, choosing its appearance, answering questions about yourself — each step is small and the accumulation is the point. By the first message you have contributed something.
Stated plainly rather than pointedly: a questionnaire before the product is a design decision, and the reason it comes before rather than after is that it works better there. The same logic is why some products generate a first message that references your answers, which demonstrates that the setup mattered at exactly the moment you would want proof of it.
That is also the connection to the rest of the product’s economics. Setup effort is one of the things a retention metric responds to, in the same family as streaks and progress scaffolding.
THE PRODUCT — onboarding
· "Customise your companion"
→ writing a text description that is sent
with every request thereafter.
· A trait you selected being ignored
→ an instruction competing with a growing
history. Nothing enforces it.
· Questions about you
→ character material and profile data.
One form, two purposes, not
distinguished.
· A setup flow before first use
→ effort secured early, because effort
predicts continuation.
· What is asked, what is stored, what it seeds
→ THE OPERATOR DECIDES, and the answers
persist independently of the character.
· Where those answers are covered
→ CHECK THE POLICY. Search "information
you provide", "profile", "preferences",
"delete".
· Whether you can see or edit the description
→ VARIES BY APP.What you can check
Look for whether the character description is visible and editable after setup. Some products expose the text and let you rewrite it. Some expose a set of sliders over it. Some expose nothing. This is the single most informative thing to establish about a companion app’s customisation, because a description you can read is a description you can reason about when the character behaves oddly.
Check whether your questionnaire answers appear in an export. They are your data by any reasonable reading, and what an export actually includes is often narrower than expected.
Notice which questions were needed and which were not. A name and a manner are needed to write a character. Some questions in a setup flow are for the profile, and telling them apart is straightforward once you know both purposes exist.
Answer only what you want stored. Nothing about setup requires accuracy about you. Where a field is optional, skipping it is a normal use of the product, and where it is required, the answer is still yours to choose.
What this doesn’t tell you
It does not tell you what any specific app asks or stores, and no named product’s onboarding is described here.
It does not tell you how your answers are weighted against the conversation, because that is internal and unpublished — and the how-to of building such a thing belongs to a builder’s subject rather than this one.
And it does not tell you whether the character you set up will stay that way. The description is the operator’s text, editable and versionable on their side, and your answers were the starting point rather than a specification.