AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Algo Price Conjoint

skill-asgard-ai-platform-skills-algo-price-conjoint · by asgard-ai-platform

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'.

No reviews yet
0 installs
19 views
0.0% view→install

Install

$ agentstack add skill-asgard-ai-platform-skills-algo-price-conjoint

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-asgard-ai-platform-skills-algo-price-conjoint)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
2mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Algo Price Conjoint? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

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

  1. Generate choice sets using experimental design (D-optimal or balanced overlap)
  2. Present respondents with sets of 3-4 product profiles, ask to choose preferred
  3. Estimate part-worth utilities using multinomial logit (MNL) or hierarchical Bayes (HB)
  4. Compute: attribute importance = range of part-worths within attribute / sum of all ranges
  5. 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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.