Przejdź do treści
Biblioteka skilli
Zarządzanie i produkt · Analiza

algo-price-conjoint

/algo-price-conjoint

Przeprowadza analizę conjoint, która mierzy, jak cechy produktu wpływają na preferencje klientów i gotowość do zapłaty.

Licencja
MIT
Ostatnia zmiana repozytorium
20.07.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
4
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 20.07.2026, bez odwołań do wycofanych modeli i API.

Licencja

MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.

Co robi i kiedy

Przeprowadza analizę conjoint, która mierzy, jak cechy produktu wpływają na preferencje klientów i gotowość do zapłaty.

Wyzwalacze z opisu

which features do customers value mostwillingness to pay for feature Xproduct attribute trade-offs
Oryginalny opis (EN)

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

Jak działa

  1. Overview
  2. When to Use
  3. Algorithm
  4. Output Format
  5. Examples
  6. Gotchas
  7. References
Sekcje z nagłówków SKILL.md, w oryginale · 82 linii, 526 słów
Podgląd SKILL.md
---
name: "algo-price-conjoint"
description: "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'."
metadata:
  category: "WP-39 定價演算法"
  tags: ["pricing", "conjoint-analysis", "market-research", "preference"]
---

# 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

```json
{
  "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`
Pliki w paczce (4)
  • SKILL.md 4 KB
  • examples/sample_scenario.md 5 KB
  • references/experimental-design.md 15 KB
  • references/hb-estimation.md 13 KB

Wersje

W bazie nie ma innych skilli o nazwie algo-price-conjoint.

Identyczna treść występuje jeszcze w 1 innych folderach na GitHubie. Tu pokazujemy jedną, najlepiej ocenioną kopię.

Migawka bazy z 28.10.2026 · wersja paczki 47818567d2a4 (skrót SHA-256 całej paczki)

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 90probe-willingness-to-pay
    Sprawdza, jak pilny jest problem i ile klienci realnie zapłacą, wyceniając produkt według wartości, a nie kosztu.
  • 100pricing-analyzer
    Analizuje i optymalizuje strategię cenową SaaS: poziomy cen, bramkowanie funkcji, gotowość do zapłaty i pozycjonowanie cenowe względem konkurencji.
  • 100algo-price-elasticity
    Oblicza elastyczność cenową popytu i pokazuje, jak zmiany cen wpływają na wolumen sprzedaży oraz przychody.
  • 100price-research
    Pomaga ustalić, ile klienci faktycznie zapłacą, zanim ustalisz cenę, z użyciem metod badawczych takich jak Van Westendorp i testy gotowości do zapłaty.
  • 100pm-pricing
    Analizuje cennik SaaS: metryki wartości, pakietowanie, badanie gotowości do zapłaty, pozycjonowanie wobec konkurencji i projekt modelu cenowego.
  • 100conjoint
    Projektuje i analizuje eksperymenty conjoint jako randomizowane eksperymenty AMCE i jako pomiar preferencji (hierarchiczne partworths Bayesa, WTP, symulacja udziałów wyboru), z korektą błędów pomiaru i wielokrotnych testów.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.