Conjoint analysis answers the question that most research methods cannot: not what your target market wants, but how much they are willing to give up to get it. Instead of asking personas to rate features in isolation — where everything always sounds good — conjoint presents them with realistic product trade-offs and forces real choices. The result is a quantified ranking of what actually drives decisions.
Use conjoint analysis when you need to:
- Decide which features to include in a product launch and which to deprioritise
- Find the price point that maximises adoption without leaving revenue on the table
- Compare two potential product configurations and predict which one the market prefers
- Understand how feature importance differs across demographic segments
Conjoint is especially valuable during pricing decisions and feature roadmap prioritisation. Run it after a concept test or survey has validated that the core proposition resonates — conjoint tells you how to configure what you already know they want.
How it works
You define your product as a set of attributes (the dimensions that vary) and levels (the values each attribute can take). Boses generates a set of paired choice tasks — each presenting two product configurations side by side — and asks every persona to choose between them.
From these forced choices, Boses computes part-worth utilities: a numeric score for each attribute level that represents how much it contributes to the persona’s overall preference. Levels within the same attribute are zero-centred, so you can directly compare them. The spread between the highest and lowest part-worths within an attribute measures its importance — how much choosing the wrong level costs you.
Submitting your design
You submit your attribute and level design in a single API call. Boses starts the simulation immediately.
curl -X POST https://api.temujintechnologies.com/api/v1/projects/<PROJECT_ID>/simulations/<SIM_ID>/conjoint-design \
-H "Authorization: Bearer <TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"attributes": [
{
"name": "Price",
"levels": ["PHP 39", "PHP 55", "PHP 75"]
},
{
"name": "Flavour",
"levels": ["Classic Salted", "Chili Lime", "Truffle & Cheese"]
},
{
"name": "Pack size",
"levels": ["25g single serve", "80g sharing bag", "200g resealable pouch"]
},
{
"name": "Health claim",
"levels": ["No artificial flavours", "High protein", "No claim"]
}
]
}'
You must first create the simulation record with simulation_type: "conjoint" before submitting the design. The /conjoint-design endpoint accepts the attribute/level structure, stores it, and starts the simulation in one step.
Creating the simulation first:
curl -X POST https://api.temujintechnologies.com/api/v1/projects/<PROJECT_ID>/simulations \
-H "Authorization: Bearer <TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"persona_group_id": "<GROUP_ID>",
"simulation_type": "conjoint"
}'
Polling and fetching results
Poll GET /simulations/<SIM_ID> until status is "complete", then retrieve results.
curl https://api.temujintechnologies.com/api/v1/projects/<PROJECT_ID>/simulations/<SIM_ID> \
-H "Authorization: Bearer <TOKEN>"
curl https://api.temujintechnologies.com/api/v1/projects/<PROJECT_ID>/simulations/<SIM_ID>/results \
-H "Authorization: Bearer <TOKEN>"
Understanding the results
Part-worth utilities
Each level receives a part-worth utility — a score relative to the other levels of the same attribute. Positive values indicate levels the persona prefers; negative values indicate levels that hurt appeal.
{
"part_worths": {
"Price": {
"PHP 39": 0.62,
"PHP 55": 0.11,
"PHP 75": -0.73
},
"Flavour": {
"Classic Salted": -0.18,
"Chili Lime": 0.45,
"Truffle & Cheese": -0.27
},
"Pack size": {
"25g single serve": -0.31,
"80g sharing bag": 0.44,
"200g resealable pouch": -0.13
},
"Health claim": {
"No artificial flavours": 0.35,
"High protein": 0.08,
"No claim": -0.43
}
}
}
Attribute importance scores
Attribute importance tells you how much each attribute as a whole drives choice — expressed as a percentage that sums to 100% across all attributes. A high importance score means the spread between that attribute’s best and worst level is large: consumers care a lot about which level they get.
{
"attribute_importance": {
"Price": 42,
"Flavour": 24,
"Health claim": 19,
"Pack size": 15
}
}
In this example, price accounts for 42% of what drives choice — meaning the difference between PHP 39 and PHP 75 outweighs any flavour or size decision. Optimising flavour without addressing price will have limited impact.
Market share simulation
The aggregate result includes a first-choice market share simulation run on three hypothetical product profiles. This shows you what share of the persona group would choose each configuration when placed head-to-head in a realistic market scenario.
{
"market_share_simulation": [
{
"profile": "PHP 39 · Chili Lime · 80g sharing bag · No artificial flavours",
"predicted_share": 0.61
},
{
"profile": "PHP 55 · Classic Salted · 25g single serve · No claim",
"predicted_share": 0.24
},
{
"profile": "PHP 75 · Truffle & Cheese · 200g resealable pouch · High protein",
"predicted_share": 0.15
}
]
}
Executive summary and recommendations
The aggregate result closes with an LLM-generated narrative that translates the part-worths and importance scores into plain-language guidance — which configuration to lead with, where you have pricing headroom, and which features are hygiene factors versus genuine differentiators.
Design tips
Keep your design to 3–5 attributes with 2–4 levels each. More attributes increase cognitive load for personas and make the results harder to act on. If you have more variables to test, run two separate conjoint studies and compare findings.
Always include price as an attribute. Without it, part-worth utilities are disconnected from willingness to pay — the most actionable output of any conjoint study.