Blog

2026-09-15

Blog

Put plan and role on the respondent, not in the survey

Plan, role, and tenure belong on the person you already know, not as extra questions after NPS. How traits keep the survey short and the sample readable.

Tuesday, 10:14. In #product, a PM pastes a form link and writes "quick NPS before standup." The form has eleven questions. Question 1 is the 0-10. Question 2 is "What plan are you on?" Question 3 is role. Then company size, industry, how they heard about you, which feature they use most, and whether they are the buyer. Three people finish before 10:30. The score is +67. By Thursday the two people who picked Enterprise from a dropdown have become enterprise NPS on a slide.

That is survey bloat. You asked people for facts the product already had, and you paid for it in drop-off and in a sample of whoever likes filling forms.

The weak version, and what it costs by Thursday

The form that went into Slack looked like this:

1. How likely are you to recommend us to a colleague? (0-10)

2. What plan are you on? (Free / Pro / Enterprise)

3. What is your role? (IC / Manager / Admin / Exec)

4. Company size?

5. How did you hear about us?

6. Anything else?

The version that keeps the sample readable looks like this. After login, the app already knows the person:

UserVane.identify({ userId: "acct_1842", traits: { plan: "pro", role: "admin", account_age_days: 47 } })

Then one NPS question, and an optional comment.

The weak version costs you the people who bounced at question 3. The three finishers are not a slice of the product. They are a slice of patience. It also costs you a fight with finance on Friday, because the plan they typed is not the plan billing has, and now neither system owns the number on the slide.

Facts on the respondent, opinions in the survey

Put on the respondent, via identify, the facts you already store: plan, role, account age, workspace size, surface, locale if you actually branch on it. Put in the survey the thing only they can tell you: the score, and a comment if they want to write one.

In the widget quickstart that is one call. identify is repeatable; traits merge. Call it when the auth session is known, the same way you would set analytics user properties. The open-source SDKs live at github.com/uservane/uservane-js if you want to read the contract rather than a marketing page.

Do not turn email, user id, or a free-text "company name" into a segment key. Those explode into one-person buckets, and a one-person bucket is not a segment. It is a row.

Target the ask instead of filtering the wreckage

If you only want admins on Pro, say so before the widget appears: trait plan equals pro, trait role equals admin. The classic widget guide covers how those predicates sit next to the trigger and the sample percent. You still get one question. You just stop interrupting people whose answers you planned to throw away.

Hosted links are the exception that proves the rule. A URL in a support macro does not see in-app traits unless you encode them on the link or capture them on the page. That is why the channel chooser treats a hosted link as an adapter, not as a license to rebuild the eleven-question form "just for email."

When you slice later, the properties already rode along

A response that landed with plan=pro can be read as Pro without asking again. That is the whole point of sending traits: the opinion and the facts arrive together, so you are not reconstructing "who was this" from a dropdown they may have guessed.

Slicing does not create sample size. Four enterprise answers is still not enterprise NPS, no matter how clean the trait is. Show N next to the slice, and suppress the headline when the slice is thin, the same way you would for the overall score. The sample size calculator is the place to check whether a slice can carry a number; the older post on why a naked score lies is the decision rule. A precise plus/minus on four people is a precise measurement of the wrong claim.

Traits are a snapshot you sent, not a live join to billing

Identify is not a billing sync. If someone upgrades from free to scale at 16:02 and you identified them at 09:11 as free, the response still says free. Send current traits when identity is known, and treat a stale trait as a stale trait. That is the limit. It does not make the eleven-question form a better source of truth, because that form was stale in a different way: it was whatever the person remembered at 10:16.

Bottom line: keep the survey to the opinion. Put plan, role, and tenure on the respondent you already have. Target who sees the ask. Read a slice only when N can carry it. The extra questions feel like diligence at 10:14, and by Thursday they are how a two-person dropdown became a strategy slide.