Conjoint Analysis Survey : Design, Programming and Cost

A conjoint analysis survey lands on this programming desk either as a meticulously engineered experimental design file paired with an annotated questionnaire, or as a four-bullet summary slide accompanied by sheer hope. At Precise Research Solutions, our technical team has programmed, audited, and hosted discrete-choice and advanced quantitative surveys from our Delhi desk since 2007, operating directly inside enterprise client licenses across North American, European, and Asia-Pacific time zones.

We do not invent the underlying mathematical design in the survey script. The quantitative methodologist and research director name the attributes, define the discrete levels, establish statistical efficiency criteria, configure prohibitions, and select the platform. Our responsibility is to translate that experimental architecture into a flawless, bulletproof web instrument—primarily inside Sawtooth Software's Lighthouse Studio, or within enterprise survey engines like Qualtrics, Decipher, or Confirmit where custom choice modules are required. If a prospective client's brief consists of an informal email paragraph saying "standard CBC, you know the kind," the programming clock has not yet started.

We will not invent arbitrary programming fees on a public webpage, nor will we pretend that a rigorous conjoint analysis survey can be rushed through the 24 to 48-hour turnarounds we routinely offer for standard trackers and linear screening questionnaires. A conjoint study captures trade-offs and forced choices under realistic market constraints; it does not collect raw utilities directly in the browser, and it cannot rescue a client-side feature debate that internal stakeholders have failed to settle.

---

What a conjoint analysis survey has to settle before anyone opens a script

Before an engineer writes a single line of logic or imports an attribute list, every conjoint analysis survey requires a locked set of methodological parameters. In standard linear survey programming, ambiguity can occasionally be clarified while initial questions are being scripted. In discrete-choice modeling, an unresolved parameter invalidates the entire experimental design matrix.

Someone on the research leadership team must formally resolve several foundational structural choices:

• Choice Task Configuration: Exactly how many product concepts appear side-by-side on each screen? Showing three alternatives plus a "None" option is common in consumer packaged goods; showing four or five alternatives in enterprise software can easily trigger cognitive overload and straight-line abandonment.
• The "None" Option Architecture: Is an opt-out allowed? If so, is it presented as a traditional unforced choice ("None of these"), or as a dual-response choice where respondents first pick their preferred concept among the set, and then answer a secondary threshold question regarding whether they would genuinely spend money on it?
• Back Navigation Rules: Can respondents return to a previous choice task and revise their selection? Permitting backward navigation in a randomized choice design can cause session-state race conditions and misalign task counters if not deliberately governed by the survey engine.
• Localization and Source Strings: What is the master source language, and how will dynamic attribute text wrap across localized scripts such as German, Japanese, or Arabic? A translation that doubles character counts will break responsive table columns on mobile screens.
• Design Matrix Provenance: Has an experimental design file already been computed and exported using fractional factorial or D-optimal algorithms, or is the scripter expected to configure and generate the design inside Sawtooth Studio from raw attribute tables?

Stakeholders still occasionally attempt to commission a discrete-choice study from an introductory PowerPoint deck containing four bullet points. A single-market study with one language, four concise attributes, a verified orthogonal design, and simple text cards that comfortably fit an entry-level smartphone screen is an orderly engineering build. A multi-country assignment spanning eight languages, dynamic photorealistic 3D pack renders, regulatory claim disclosures, currency-converted price ladders, and complex prohibition matrices is an entirely different operational animal.

Furthermore, a professional choice experiment lives inside an authenticated software account. When programming on client licenses, our team requires a dedicated named seat with administrative or scripter permissions, not an intermittent screen-share session. Shared passwords passed through chat channels inevitably expire or trigger multi-factor authentication lockouts the moment a project sponsor takes leave. The official delivery clock begins only when access credentials function cleanly.

Finally, the instrument must integrate with an external sample ecosystem. Completed interviews, quota-fulls, speeder flags, and demographic screen-outs must reliably ping cryptographic redirect callbacks that panel suppliers require. In our seventeen years of fielding, we have seen supposedly polished scripts deploy with termination points still pointed to staging URLs. Every exit condition must be validated with simulated respondent IDs before live sample spend begins.

Features, values, and the card on a phone

In discrete-choice modeling, attributes and levels constitute the core product vocabulary. These parameters belong exclusively to the client's methodology and brand strategy team. Our programming desk does not originate attribute lists, nor will we insert an extra feature into a conjoint analysis survey simply because an account manager remembered a pet product claim during a kickoff call. The moment an attribute changes, the experimental design becomes obsolete and must be recomputed.

When too many attributes are crammed into a study, the concept card stops looking like a product preview and begins resembling a legal contract. If a client specifies nine attributes, each with two lines of explanatory text, the resulting choice task overflows the viewport of standard mobile devices. Respondents are forced to scroll vertically and horizontally across columns, losing visual comparison context. When navigation becomes laborious, respondents unconsciously simplify their cognitive workload by evaluating only the first attribute (often Brand) and the last (often Price), destroying the statistical validity of intermediate features. We actively flag cards that fail ergonomic mobile standards, but the structural decision to prune features rests with the methodology owner.

Price levels must always be defined as discrete, fixed quantitative increments—never as open-ended numeric input fields. Choice-based conjoint measures preference across defined price points. If your product typically retails between $199 and $299, the levels might be set at $199, $229, $259, and $299. The levels assigned to each attribute require two immutable identifiers:

1. A Human-Readable Display Label: The exact consumer-facing string rendered on the card (e.g., "$249 with free shipping").
2. A Permanent Numeric Code: The underlying integer stored in the database (e.g., Level 3). Data analysts and econometricians who run post-field segmentation rely on consistent numerical mapping. A programmer must never renumber levels from 1–4 to 0–3 simply to accommodate personal coding shorthand.

Price tiers that sit unrealistically close together (for instance, testing $49.00 vs $49.50 in a consumer durable category) produce flat, uninformative utility slopes because respondents register no meaningful economic hurdle. Conversely, skipping the actual prevailing market price leaves pricing strategists guessing where the revenue-maximizing sweet spot lies. Our desk will never arbitrarily widen price ranges or pad thin attributes with artificial filler levels just to make a visual layout look balanced.

Every single level specified in the design file must render in the browser with its approved textual and visual assets. A rigorous pre-launch script check catches missing image URLs, broken SVG icons, and truncated translations. In multilingual projects, translation is not merely an editorial exercise; it directly affects card geometry. In German, compound nouns can expand a concise English label into three lines of text. If one column wraps into a tall vertical block while neighboring columns remain compact, the distorted card draws disproportionate visual attention. Respondents select or reject concepts for layout reasons rather than genuine product preference.

CBC and the methods people file next to it

Choice-Based Conjoint (CBC) represents the vast majority of discrete-choice projects programmed on our desk. In CBC, respondents evaluate multiple complete product profiles simultaneously and select the one profile they would purchase. The concepts presented on each screen are drawn strictly from an underlying experimental design matrix—never from an impromptu client-side JavaScript shuffle that merely "feels random."

In standard Choice-Based Conjoint, the vertical ordering of attributes on the card remains static across tasks unless the research specification explicitly calls for rotation. While novice researchers sometimes assume rotating attributes prevents boredom, randomized attribute positioning forces respondents to re-scan the entire card layout on every single screen. Eye-tracking and cognitive research demonstrate that attribute shuffling increases respondent fatigue and introduces severe noise into utility estimations. Unless there is a compelling methodological mandate to test position bias, feature rows should remain fixed.

The "None" option in CBC must always be programmed as an authenticated database code rather than a cosmetic graphic. We have audited broken third-party scripts where clicking the "None of these" button recorded the code for Concept 1 simply because the scripter forgot to bind a unique value to the radio element. During visual previews, the interface appeared to function smoothly; during post-field analysis, the data file erroneously claimed that 100% of opt-out respondents were enthusiastic purchasers of the leftmost product concept.

It is vital to distinguish Choice-Based Conjoint from adjacent trade-off methodologies that often get conflated in preliminary research proposals:

• MaxDiff (Maximum Difference Scaling / Best-Worst Scaling): MaxDiff presents a list of items (e.g., brand claims, feature benefits, or customer service priorities) and asks respondents to select the single most important and single least important item. It does not assemble multi-attribute product profiles. If a study incorporates both a CBC exercise and a MaxDiff battery, they must be scripted as separate, modular sections with independent data export dictionaries.
• Adaptive Choice-Based Conjoint (ACBC): ACBC is a sophisticated multi-stage methodology designed for categories with extensive attribute counts (such as automotive, real estate, or high-end technology). The interview begins with a "Build-Your-Own" (BYO) configuration screen, progresses through a non-compensatory screening section to establish cut-offs and "must-have" features, and culminates in a choice tournament among shortlisted concepts. Re-architecting ACBC inside a generic web survey tool using brute-force logic branches is a high-risk endeavor; ACBC belongs inside dedicated, specialized choice modeling software.
• Menu-Based Choice (MBC): Menu exercises allow respondents to customize a bundle by selecting options à la carte (e.g., fast-food combos, telecom service plans, or insurance coverage tiers), often with dynamic price counters recalculating total cost in real time. MBC requires specialized multi-selection logic and bespoke data structures that differ fundamentally from discrete CBC cards.
• Traditional Full-Profile Conjoint: An older methodology where respondents rate or rank individual product concepts one at a time on Likert scales. While historically popular before the advent of modern computational estimation, rating-based conjoint suffers from scale-usage bias and lacks the realistic market trade-off fidelity of CBC.

When a client brief calls for Choice-Based Conjoint, we build from the design file within the designated specialized platform. If the scope document specifies CBC but the attached questionnaire template displays a grid of 1-to-10 rating scales, our desk halts the build immediately to align on methodology before code is committed.

Rules that block impossible concepts

Prohibitions are formal constraints that prevent illogical, implausible, or unmarketable combinations of attributes from being shown to respondents. Classic examples include pairing an entry-level economy brand with an ultra-luxury price tag, combining a basic plastic chassis with an enterprise industrial warranty, or showing an iOS operating system on an Android hardware profile.

The cardinal rule of choice modeling is that prohibitions must be incorporated directly into the experimental design generation algorithm before the design matrix is finalized. If you generate a standard orthogonal design and subsequently attempt to ban unwanted combinations by applying client-side JavaScript skips or page filters during survey runtime, you break the underlying statistical orthogonality. When you arbitrarily suppress specific tasks, attributes no longer appear with balanced frequencies, and correlations between supposedly independent levels become severely distorted.

Brand and price prohibitions are by far the most common constraints encountered in commercial fieldwork. They are also the area where project teams are most frequently tempted to execute ad-hoc, post-design adjustments. When reviewing a visual preview, an executive might remark, "Brand X would never sell at $400; let's write a script condition to hide that card." Modifying a generated design in the survey script corrupts the design's D-efficiency and compromises the subsequent Hierarchical Bayes estimation. If prohibitions must be added or revised, the entire design matrix must be returned to the methodologist to be re-run through the design generator.

Our quality assurance protocol tests prohibitions bi-directionally across every design version:

• Forward Verification: We confirm that prohibited pairs never appear together across any generated task or respondent version.
• Integrity Verification: We verify that the script displays the exact concepts defined in the approved design file without introducing secondary ad-hoc rules that drop tasks, skip questions, or artificially skew level exposure.

Where the script actually lives

A conjoint analysis survey lives inside specialized software designed specifically for discrete-choice modeling, or within enterprise survey platforms configured with robust custom coding capabilities. The platform is determined by the methodologist and client licensing constraints, not by scripter whim.

In the vast majority of our technical builds, the platform of choice is Sawtooth Software's Lighthouse Studio. Specialized choice software exists because experimental design generation, multi-version task delivery, online data collection, and post-field econometric simulation originate from an integrated mathematical ecosystem. Within a native Sawtooth environment, design matrices map seamlessly to choice exercises, and raw interview logs flow directly into estimation engines without manual column transposition.

However, many global enterprises maintain master agreements with general survey engines such as Decipher (Forsta), Qualtrics, Confirmit, or Alchemer. Programming a choice exercise inside a general-purpose survey platform requires significantly more engineering vigilance. Because general platforms lack automated conjoint loop engines, the programmer must either manually import a pre-generated design matrix into custom database tables, script custom JavaScript loop blocks, or inject specialized SVG/HTML rendering templates into each screen. We program discrete-choice modules inside client Decipher or Qualtrics environments regularly, but we insist that the design matrix, prohibition checks, and data export structures adhere to the exact same rigorous mathematical standards applied in native choice software.

When working within client software accounts, five operational rules govern our workflow:

1. Dedicated User Access: We require an individual named developer credential within your tenant. Relying on shared logins or informal team accounts risks mid-field lockouts and compromises compliance auditing.
2. No Design Improvisation: The script must faithfully execute the locked design. We will never add features, change level phrasing, or reorder tasks inside the software environment without written methodology sign-off.
3. ACBC Stays in Native Tools: If your project specification mandates Adaptive CBC, it must remain inside Sawtooth Software. Attempting to replicate an adaptive tournament model inside a standard survey tool through nested logic branches creates an unmaintainable codebase prone to mid-field crashes.
4. Rigorous Mobile Card Geometry: We test task rendering on physical mobile hardware. While high-resolution desktop monitors comfortably display wide multi-column tables, a standard smartphone viewport wraps narrow columns aggressively. If an extended feature description pushes price below the initial scroll fold, respondents will evaluate products without viewing price, introducing severe systematic bias into price sensitivity models.
5. Clear Quota and Screener Separation: If screener questions and demographic quotas reside in one survey platform while the choice exercise is hosted in a secondary specialized tool, the server-to-server redirects and URL query parameters (UID, PID, sample source tokens) must be meticulously mapped and tested. We have bridged split-platform architectures from our Delhi programming desk since 2007.

How the loop gets built

Once the experimental design matrix is finalized and validated, the choice module is engineered as an automated programmatic loop—never as a bloated sequence of manually duplicated static survey screens. Duplicating screens by hand is a notorious source of human error, leading to missed logic conditions, mismatched piping tags, and corrupted variable naming.

In a properly constructed loop architecture, the survey engine executes one dynamic iteration per choice task. The specific concepts displayed on screen are retrieved directly from the row of the design matrix assigned to that respondent's version. Concepts must appear strictly in the spatial positions (Concept 1, Concept 2, Concept 3) designated by the design algorithm. Introducing a secondary randomization step that shuffles concepts on the page undermines the balanced experimental plan and introduces undocumented variance.

Key technical considerations during the loop build include:

• Code Consistency Across Languages: Attribute text must be dynamically populated from indexed code lists. The underlying level code (e.g., Attribute 2, Level 4) must remain strictly identical across English, Spanish, Mandarin, or German. Only the display string changes; the underlying relational key is immutable.
• Asset and Image Mapping: When concept cards incorporate product imagery, pack renders, or brand logos, image filenames must be programmatically derived from level IDs (e.g., brand_03.png). An off-by-one indexing error will pair a premium brand logo with a discount product description, rendering all subsequent respondent choices meaningless. Every asset must be verified task-by-task against the master matrix.
• "None" Option State Management: If an opt-out choice is present, selecting "None" must cleanly clear any active concept selections and record an explicit, reserved value (such as 0 or 99). If a dual-response follow-up question is required ("Would you actually purchase this product in real life? Yes/No"), it must be conditionally displayed as a secondary input field without overwriting the primary concept choice.
• Robust Back-Button Navigation: If back navigation is permitted by the study design, the loop state machine must accurately restore previously selected answers and return to the exact prior task without skipping rows, incrementing task counters, or re-randomizing the design version. A state tracking flaw here produces clean-looking completions that contain duplicate or orphaned task records.
• Comprehensive Variable Logging: The data engine must record the exact design version number, the specific task index, the precise level codes displayed across every concept on screen, and the final selected alternative. If a respondent abandons or screens out prior to completing the choice battery, their partial session must be explicitly flagged so incomplete iterations are not accidentally ingested into final utility models.
• Holdout Task Isolation: Fixed holdout tasks (used to benchmark model predictive validity) must be flagged with permanent diagnostic identifiers. If an attribute does not apply to a specific brand level (for example, a digital-only software tier that has no physical packaging attribute), the blank cell must be formatted cleanly so text does not collapse awkwardly and distort adjacent price displays.

A coffee-machine spec, with no fake shares

To understand how a discrete-choice survey is constructed from the ground up, consider an authentic engineering specification rather than a theoretical textbook diagram. Let us examine a classic Choice-Based Conjoint study designed for a consumer kitchen appliance: an automated home espresso and coffee machine.

The research methodology specifies five core attributes with defined discrete levels:

• Brand (3 levels): Brand A (Premium Italian), Brand B (Mainstream Consumer), Brand C (Value Retailer).
• Price (4 levels): $149, $199, $249, $299.
• Cup Size Versatility (3 levels): Single Espresso Only, Espresso & 8oz Mug, Full Carafe Compatible.
• Milk System (2 levels): Manual Steam Wand, Automatic One-Touch Frother.
• Warranty Coverage (2 levels): 1-Year Limited Warranty, 3-Year Comprehensive Warranty.

Calculating the full factorial expansion reveals: \(3 imes 4 imes 3 imes 2 imes 2 = 144\) unique product configurations. Presenting 144 individual concept cards to a single consumer is humanly impossible; severe cognitive exhaustion would destroy response quality after the tenth screen.

Instead, the methodologist deploys a balanced fractional factorial design generating multiple questionnaire versions. Each respondent is assigned to evaluate twelve choice tasks. Each task presents three distinct coffee machine concepts side-by-side, plus a "None of these" option. Over the course of the survey, a respondent evaluates exactly \(12 imes 3 = 36\) concept profiles. Across a sample of 500 completed interviews, the design algorithm guarantees that every level appears with balanced frequency and that attribute correlations remain near zero.

The engineering specification establishes two mandatory prohibitions:

1. The lowest price point ($149) cannot be paired with the longest warranty (3-Year Comprehensive). Such a combination is commercially unviable and would distort warranty utility.
2. Brand C (Value Retailer) cannot be paired with Full Carafe Compatibility, as the manufacturer does not produce a commercial-grade brewing chamber under that sub-brand.

These prohibitions are compiled directly into the experimental design generation engine. When the resulting design file arrives at our Delhi programming desk, the scripter imports the design versions and executes systematic QA checks. The engineer inspects Task 1 on screen against the exact matrix values for Version 1, Task 1. Then Task 7, then Task 12. The engineer tests the "None" path to ensure code 0 is recorded in the database, and checks that prohibited combinations never materialize.

We do not fabricate simulated market share predictions on our blog and pretend that an informal pre-test in our office represents real consumer behavior. A real-world conjoint specification is an exercise in rigorous database validation, pixel-perfect layout testing, and zero-defect data routing.

What estimation needs from the file

Respondents who complete an online survey never see part-worth utilities, zero-centered diffs, or covariance matrices. They see product cards, evaluate trade-offs, and click their preferred alternative. The programmer's core deliverable is an uncorrupted, perfectly structured data file that econometricians can ingest directly into estimation engines without spending hours cleaning misaligned records.

Part-worth utilities are calculated mathematically after fieldwork concludes, using the observed respondent choices combined with the known experimental design matrix. The gold-standard estimation methodology for modern Choice-Based Conjoint is Hierarchical Bayes (HB). In our client kickoff meetings, we establish data export specifications early so that the output structure matches the estimation team's workflow while schema changes are still effortless.

Hierarchical Bayes requires a complete, unbroken record for every respondent:

• The Assigned Design Version: An integer identifying which specific block of the experimental matrix the respondent completed.
• The Complete Attribute Profile: The exact level codes displayed for every concept shown across every choice task.
• The Observed Choice Indicator: A binary flag (1 for chosen, 0 for unchosen) or an explicit concept index indicating the selected option, including an unambiguous code for the "None" alternative.

Whether the analytical team requires a "stacked/long" format (where each concept occupies an individual row) or an "unstacked/wide" format (where each choice task occupies a single row with multiple concept columns), the schema must be agreed upon in writing before launch. A data import failure in Sawtooth CBC/HB, R, or Python is treated as an urgent fieldwork crisis, even when the underlying root cause was simply an unmapped column header.

A fatal hazard of discrete-choice modeling is that statistical software will happily process corrupted data without throwing an error. If an inexperienced scripter transposes columns during export—mapping the Brand column into the Price slot and vice versa—the Hierarchical Bayes algorithm will still converge and output numeric utilities. The resulting coefficients will appear mathematically sophisticated, but they will model a phantom study that was never actually fielded. Brand elasticity will be interpreted as price sensitivity, and executive decisions will be guided by nonsense. Comparing raw database exports against the master design file is our mandatory pre-launch safeguard.

Once individual-level part-worth utilities are estimated, secondary analytical metrics can be derived:

• Willingness to Pay (WTP): The monetary value consumers attach to a specific feature enhancement, calculated by dividing the utility difference between two feature levels by the price attribute coefficient (price utility per dollar). If price levels were spaced too narrowly or defined as vague qualitative bands, WTP calculations produce volatile, distorted estimates.
• Market Simulation Models: Analytical simulators (incorporating Logit, First Choice, or Randomized First Choice algorithms) that allow product managers to simulate "what-if" competitive scenarios. A simulator fed corrupted utility files will confidently declare the wrong product configuration as the market winner.

Precise Research Solutions guarantees that your data export matches the underlying experimental design with absolute mathematical fidelity. Building post-field econometric market simulators or running bespoke segmentation models sits outside standard survey programming scope, but our export files ensure your data science team can execute their models without friction.

Days, not the simple-survey window

For standard linear questionnaires—such as brand trackers, ad-testing surveys, or customer satisfaction benchmarks with verified screeners—our Delhi programming desk routinely turns around fully tested, field-ready links in 24 to 48 hours. When prospective clients ask whether a complex conjoint analysis survey can be delivered within that same 24-hour window, our answer is an unequivocal no.

Quoting a discrete-choice survey inside a 24-hour turnaround window requires skipping the experimental design audit, rushing mobile layout rendering checks, and bypassing cross-table export reconciliation. The design audit is precisely why choice studies take the time they take. In a conjoint project, an undetected error does not result in a single awkward question wording; it invalidates thousands of dollars in panel sample spend.

A professional conjoint analysis survey is quoted in business days, reflecting the multiple phases of rigorous engineering required:

• Phase 1: Design Matrix Audit (Day 1): Verification of attributes, discrete levels, variable labels, statistical balance, D-efficiency scores, and prohibition logic.
• Phase 2: Core Instrument Engineering (Days 2–3): Scripting screeners, demographic logic, dynamic choice task loop architectures, custom CSS responsive tables, and panel redirect handshakes.
• Phase 3: Multi-Device and Accessibility QA (Day 4): Exhaustive visual and functional testing across physical iOS, Android, and desktop screen widths, ensuring cards do not cause vertical or horizontal overflow.
• Phase 4: Simulated Data Run and Export Reconciliation (Day 5): Pushing 500 automated test completes through the live survey engine, pulling raw CSV and SPSS (.sav) data exports, and verifying that every level code maps 1:1 back to the original design matrix.

A balanced experimental design is the craft of the research methodologist; rendering that design without technical drift is ours. If client stakeholders revise attributes, adjust price points, or introduce new prohibitions after survey programming has commenced, the experimental design must be regenerated and the project schedule reset. We archive the finalized experimental design file alongside the survey codebase with strict version control, ensuring complete auditability for longitudinal research waves.

Soft launch and the test export

In discrete-choice research, the first live respondents to enter the survey must be treated as a controlled operational soft launch. A conjoint soft launch is not an informal check of dashboard charts; it is a systematic audit of the first 20 to 50 real respondent data records against the master experimental design matrix.

Fieldwork must be paused immediately if any of three critical anomalies appear in soft launch data:

1. Duplicate Concept Rendering: If a respondent's data record reveals that two identical product concepts were presented on the same screen, an error has occurred in the design file or loop indexing.
2. Orphaned or Missing "None" Records: If the study includes an opt-out choice but the soft launch data contains zero "None" selections across fifty respondents—or if "None" selections are recording invalid null values—the input binding is broken.
3. Mobile Layout Overflow in Translated Locales: If mobile completion times in a translated language (such as German or Japanese) are 40% longer than in English, extended text strings are likely forcing mobile respondents into tedious horizontal scrolling, artificially suppressing selection rates for wrapped features.

Pausing fieldwork during the soft launch costs virtually nothing; discovering an unmapped column or a misaligned level code after 1,000 respondents have completed the survey ruins the research budget. In addition to technical validation, soft launch data reveals behavioral anomalies such as straight-line speeders who click through 12 choice tasks in 20 seconds without reviewing concept details.

The mock test export for a conjoint analysis survey must be generated, reviewed, and signed off before any live panel respondent is invited. Using automated survey bots, our team generates a synthetic data file containing hundreds of test iterations. We output fully labeled SPSS (.sav) files and structured CSVs containing respondent IDs, assigned design versions, task numbers, concept positions, attribute level codes, and choice indicators. If an attribute column labeled "Brand" in the design file appears under "Cup Size" in the export, the project does not launch. Ambiguous database column names like Q_Conjoint_F1_1 that cannot be traced back to the survey card have no place in a professional research deliverable.

Questions we actually get

How long does a conjoint analysis survey take to program?

A professional discrete-choice survey is quoted in business days, not hours. A straightforward single-language Choice-Based Conjoint study with a finalized design file, clean attribute labels, and standard responsive cards typically requires 3 to 5 business days for programming, mobile optimization, and test export validation. Multi-country projects involving multiple languages, custom graphical assets, complex screener quotas, or split-platform integrations typically require 6 to 10 business days. Projects that attempt to compress this timeline inevitably skip essential export verification steps.

Can you script a conjoint analysis survey outside Sawtooth?

Yes, provided the project is engineered properly for the target environment. If a choice study is generated and managed within a Sawtooth Software project, it should remain in Lighthouse Studio to preserve seamless integration with Hierarchical Bayes estimation and market simulators. However, our Delhi desk regularly scripts robust discrete-choice modules inside enterprise survey engines including Decipher (Forsta), Qualtrics, and Confirmit. When working outside Sawtooth, we import the external experimental design matrix into custom server-side data tables, build custom responsive HTML/CSS choice cards, enforce prohibition rules, and structure the data export so that it mirrors native conjoint data schemas.

What should we send so a conjoint analysis survey quote is real?

To receive an accurate, binding programming quote and timeline, provide a finalized specification rather than an exploratory summary. We need:

• The complete list of attributes and discrete levels, including exact consumer-facing labels and underlying numerical codes.
• The prohibition matrix detailing all forbidden attribute pairings.
• The task architecture: number of choice tasks per respondent, number of product concepts displayed per screen, and whether a "None" or dual-response opt-out is included.
• The experimental design file (if already generated) or a request for our desk to generate the design in Sawtooth Studio.
• The target survey platform and hosting environment, list of target languages, and sample provider redirect requirements.

Do you run the estimation?

Our primary operational scope covers survey programming, responsive layout engineering, quota architecture, mobile QA, and verified data exports. Post-field econometric modeling—including Hierarchical Bayes (HB) estimation, utility segmentation, Willingness to Pay (WTP) analysis, and custom market simulator construction—is typically handled by our clients' internal methodology or data science teams. However, our desk frequently partners with research agencies to provide end-to-end support, including running Sawtooth HB estimation routines and delivering pre-configured market simulator workbooks when explicitly included in the statement of work.

Where should holdout tasks sit?

Fixed holdout tasks (choice tasks identical across all respondents, used to benchmark the internal predictive validity of the estimated model) should sit precisely where the experimental design algorithm placed them—typically distributed among the randomized choice tasks. They must be explicitly tagged with unique diagnostic variable names in the survey script so that the estimation software can isolate them from the randomized tasks used to estimate part-worth utilities. Holdout tasks should never be inserted haphazardly as an uncoordinated afterthought during fielding.

What fails in the first real completes?

The issues that most commonly surface during initial live completes include:

• Mobile Viewport Overflow: Concept cards that look clean on wide desktop workstations wrap excessively on smartphones, pushing critical price levels below the fold.
• Mascoded "None" Options: The opt-out button fails to record an explicit code or erroneously saves the data of an adjacent concept.
• Discrepancies Between Screen and Database: A column shift in the export template causes Attribute A to be recorded under Attribute B's variable name.
• Broken Panel Redirects: Terminated or completed respondents fail to pass secure cryptographic status parameters back to the sample exchange, triggering sample delivery stoppages.
• Localized Text Expansion: Translated copy breaks table cell alignment in non-English survey versions.

Allowing a discrete-choice survey to field over an unmonitored weekend without auditing the initial soft launch records is the most expensive mistake in quantitative market research.

What the kickoff still has to name

No project director or research lead should ever sign off on a conjoint analysis survey based solely on static desktop screenshots. In the project kickoff document, clearly name the survey hosting environment, identify the system administrator authorized to grant named developer seats, and document the exact software license tier under which the study will run.

If the study architecture splits screeners and demographic quotas into one platform while the choice tasks reside in another, test bidirectional server redirects across all outcome paths—completes, screen-outs, quota-fulls, and quality terminations—using dummy IDs before live panelists are dispatched. Furthermore, ensure that subsequent waves of tracking studies open on the exact version-controlled design file that actually fielded in Wave 1, rather than relying on an informal memory of what was approved.

A survey programming desk cannot resolve an attribute list that remains an internal corporate debate, repair an overloaded card that forces mobile respondents into excessive scrolling, or fix an experimental design file that conflicts with written specifications. Conjoint analysis measures real consumer trade-offs; its validity depends upon unyielding engineering precision.

Send the design file, not a slide deck. Our Delhi programming desk is open, and our services are detailed here: conjoint analysis survey. You will receive an honest timeline quoted in days, the exact software platform we will deploy, and an engineering team that refuses to paper over methodological flaws.