Almost every install decision happens above the fold of a store listing, on a screen showing several competing apps at once. That is the context to test in, and it is almost never the context teams review their listing in.
What to put in the public brief
- The platform, and the category
- That they will look at a store listing, not install anything
- Roughly how many listings they will compare
- The device type
Keep the app identity private, and give them a store search rather than a direct link where you can.
What to put in the private instructions
Show the search results row first
Ask which one they would tap and why, before showing your listing on its own. That row is the real competition and the real test.
Ask what they think the app does from the icon alone
Then from the first two screenshots. Then from the opening text. Three separate answers, in that order, because that is the order a person receives them.
Ask what stopped them
If they would not install, the reason is the deliverable. "Looks like it needs an account" and "looks like it is for businesses" are both findings you can act on.
Ask about the price and the model
Whether they could tell what it costs. Uncertainty about cost is a common silent blocker and it never appears in store analytics.
Proof worth requiring
Ask for
Written answers at each stage, which listing they would tap in the row, and their device.
Do not ask for
A rating, a review, an install, or anything that touches the store itself. The task is feedback to you, and it must leave no trace on the listing.
When this task type is the wrong tool
If people install and then leave immediately, the listing is working and the problem is after it — run an onboarding test.
If you want keyword research rather than the install decision, that is a different discipline with its own tools, and human feedback will not substitute for it.