algo-price-conjoint
Skill238 starsChanged 6 months agoMITView on GitHub
Run conjoint analysis to measure how product attributes drive consumer preferences and willingness to pay. Use this skill when the user needs to quantify feature value trade-offs, estimate willingness to pay for specific features, or optimize product configuration — even if they say 'which features do customers value most', 'willingness to pay for feature X', or 'product attribute trade-offs'.
In this repository315 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- algo-ad-biddingSkill
- algo-ad-budgetSkill
- algo-ad-ctrSkill
- algo-ad-gspSkill
- algo-ad-vcgSkill
- algo-blockchain-basicsSkill
- algo-blockchain-smart-contractSkill
- algo-ecom-bm25Skill
- algo-ecom-rankingSkill
- algo-ecom-searchSkill
- algo-forecast-arimaSkill
- algo-forecast-ensembleSkill
- algo-forecast-exponentialSkill
- algo-forecast-prophetSkill
- algo-hr-compensationSkill
- algo-hr-matchingSkill
- algo-hr-turnoverSkill
- algo-mfg-cpkSkill
- algo-mfg-doeSkill
- algo-mfg-fmeaSkill
- algo-mfg-spcSkill
- algo-net-centralitySkill
- algo-net-communitySkill
- algo-net-influenceSkill
- algo-nlp-ldaSkill
- algo-nlp-nerSkill
- algo-nlp-similaritySkill
- algo-nlp-summarizationSkill
- algo-price-bundleSkill
- algo-price-dynamicSkill
- algo-price-elasticitySkill
- algo-price-van-westendorpSkill
- algo-rank-bayesianSkill
- algo-rank-eloSkill
- algo-rank-trueskillSkill
- algo-rank-wilsonSkill
- algo-rec-cfSkill
- algo-rec-contentSkill
- algo-rec-hybridSkill
- algo-rec-mfSkill
- algo-rec-sessionSkill
- algo-risk-altman-zSkill
- algo-risk-benfordSkill
- algo-risk-creditSkill
- algo-risk-varSkill
- algo-sc-bullwhipSkill
- algo-sc-eoqSkill
- algo-sc-newsvendorSkill
- algo-sc-routingSkill
- algo-sc-safety-stockSkill
- algo-seo-backlinkSkill
- algo-seo-contentSkill
- algo-seo-crawlSkill
- algo-seo-pagerankSkill
- algo-seo-schemaSkill
- algo-seo-technicalSkill
- algo-seo-tfidfSkill
- algo-social-engagementSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
When you only need an acceptable price range (use Van Westendorp — simpler)
- Distinctive: line 24
When attributes can't be varied independently (natural constraints)
- Distinctive: line 47
Check: holdout task prediction accuracy (hit rate > 60%), signs of part-worths are logical (higher price → lower utility).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Conjoint Analysis
Overview
Conjoint analysis estimates the relative value consumers place on product attributes by analyzing their choices among hypothetical product profiles. Choice-Based Conjoint (CBC) is the most common variant. Produces part-worth utilities per attribute level and derived willingness-to-pay estimates.
When to Use
Trigger conditions:
- Determining which features drive purchase decisions and how much they're worth
- Estimating willingness to pay for specific product features
- Optimizing product configuration for a target segment
When NOT to use:
- When you only need an acceptable price range (use Van Westendorp — simpler)
- When attributes can't be varied independently (natural constraints)
Algorithm
IRON LAW: Conjoint Results Are Valid ONLY for Tested Attribute Levels
Extrapolating beyond tested ranges is unreliable. If you tested
prices $10-$50, you cannot predict preference at $100. The utility
function is only defined within the experimental design space.Phase 1: Input Validation
Define: attributes (3-7), levels per attribute (2-5 each), design type (full factorial if small, fractional/D-optimal if large). Survey 200+ respondents minimum. Gate: Attributes independent, levels realistic, sample size sufficient.
Phase 2: Core Algorithm
- Generate choice sets using experimental design (D-optimal or balanced overlap)
- Present respondents with sets of 3-4 product profiles, ask to choose preferred
- Estimate part-worth utilities using multinomial logit (MNL) or hierarchical Bayes (HB)
- Compute: attribute importance = range of part-worths within attribute / sum of all ranges
- Derive WTP: utility-to-price conversion using the price attribute coefficient
Phase 3: Verification
Check: holdout task prediction accuracy (hit rate > 60%), signs of part-worths are logical (higher price → lower utility). Gate: Holdout hit rate acceptable, utilities directionally correct.
Phase 4: Output
Return part-worth utilities, attribute importance, and WTP estimates.
Output Format
{
"attribute_importance": [{"attribute": "price", "importance_pct": 35}, {"attribute": "brand", "importance_pct": 28}],
"part_worths": {"price": {"$10": 2.1, "$30": 0.5, "$50": -1.8}},
"wtp": {"feature_x": 12.50, "brand_premium": 8.00},
"metadata": {"respondents": 300, "model": "hierarchical_bayes", "holdout_hit_rate": 0.72}
}Examples
Sample I/O
Input: Laptop with attributes: Brand(Apple/Dell/Lenovo), RAM(8/16/32GB), Price($800/$1200/$1600) Expected: Apple has highest brand utility, 32GB RAM preferred, price negative utility. WTP for Apple brand premium ≈ $200.
Edge Cases
| Input | Expected | Why |
| All attributes equally important | No clear driver | Product is commodity-like |
| Price dominates (>60%) | Highly price-sensitive market | Features don't differentiate enough |
| One level never chosen | Extreme negative utility | That level is a deal-breaker |
Gotchas
- Hypothetical bias: Respondents making hypothetical choices may not reflect real purchase behavior. Incentive-compatible designs (real choices) are better but expensive.
- Number of attributes: More than 6-7 attributes overwhelms respondents, leading to simplification strategies (ignore some attributes). Keep designs manageable.
- Interaction effects: Standard analysis assumes attributes are independent. If brand affects price sensitivity (brand×price interaction), you need interaction terms.
- Segment heterogeneity: Average part-worths mask segments with opposite preferences. Use latent class or HB models to uncover segments.
- Design efficiency: Poor experimental designs (unbalanced, correlated attributes) produce imprecise estimates. Use proper design software.
References
- For experimental design generation, see
references/experimental-design.md - For hierarchical Bayes estimation, see
references/hb-estimation.md
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

