4.2.1 Study Overview🔗

In this study, participants are placed into groups of 4:

• 3 Proposers: Each makes two offers — an actual offer (the real amount they would give) and a communicated offer (what the Responder sees). These values can differ, allowing Proposers to potentially mislead the Responder.

• 1 Responder: Sees only the communicated offers from all three Proposers and decides whether to accept or reject.

The Responder is randomly assigned to one of two conditions:

• Control group: If they accept, a random Proposer is selected for them

• Treatment group: If they accept, they choose which specific Proposer to pair with

If the Responder accepts (and a Proposer is selected/chosen), the Responder receives the actual offer from that Proposer, which may differ from what was communicated.

4.2.2 Preamble🔗

#lang conscript

(require conscript/form0

conscript/survey-tools

racket/list

racket/match)

(provide proposal-choice)

As always we begin with #lang conscript, require the additional modules we’ll need, and provide the name of our study. The comment block at the top serves as helpful documentation for anyone reading the code.

We require racket/list for shuffle, and racket/match for match-define and match*, which we’ll use to extract values from complex data structures.

4.2.3 Instance-Scoped Variables and Role Assignment🔗

;; =============================================================================

;; INSTANCE-SCOPED VARIABLES, ROLE ASSIGNMENT

;; =============================================================================

(defvar/instance group-roles)            ; (shuffle '(proposer proposer proposer responder))

(defvar/instance responder-treatments)   ; list of #t/#f for treatment assignment

(defvar role)                            ; 'proposer or 'responder

(defstep (assign-roles)

; Balanced assignment of 3 proposers and 1 responder

(with-study-transaction

(when (or (undefined? group-roles) (null? group-roles))

(set! group-roles (shuffle '(proposer proposer proposer responder))))

(set! role (first group-roles))

(set! group-roles (rest group-roles)))

(skip))

We use two types of variable scopes here:

• Instance-scoped variables (group-roles, responder-treatments): These are shared across all participants in the study instance. We use them to coordinate role assignment and treatment assignment.

• Participant-scoped variables (role): Stores a unique value for each participant.

The assign-roles step assigns each participant to either the 'proposer or 'responder role:

1. The first participant to reach this step creates a shuffled list of roles: '(proposer proposer proposer responder)

2. Each participant takes the first role from the list and stores it in their role variable

3. The role is removed from the shared list, so the next participant gets the next role

The with-study-transaction ensures that even if multiple participants reach this step simultaneously, they each get a unique role without conflicts.

4.2.4 Participant-Scoped Variables🔗

;; =============================================================================

;; PARTICIPANT-SCOPED VARIABLES

;; =============================================================================

(defvar is-responder-treatment?)        ; #t or #f (only for responders)

(defvar actual-offer)                   ; number 0-5

(defvar communicated-offer)             ; number 0-5

(defvar responder-decision)             ; 'accept or 'reject

(defvar chosen-proposer-id)             ; participant id or #f

(defvar outcome)                        ; string describing outcome

These variables store data that is unique to each participant. All participants will have these variables, though not all will use them (for example, only Responders will use is-responder-treatment?, and only Proposers will use actual-offer and communicated-offer).

4.2.5 Instructions🔗

;; =============================================================================

;; INSTRUCTIONS

;; =============================================================================

(defstep (instructions)

@md{# Proposal Choice Study

Welcome! In this study, you will be placed in a group of 4 participants.

Three participants will be **Proposers** and one will be a **Responder**.

## How it works:

**Proposers** will make two types of offers:

- An **actual offer**: the real amount they would give to the Responder (0-5)

- A **communicated offer**: the amount they tell the Responder (0-5)

These two values can differ.

**Responders** will see only the communicated offers from all three Proposers.

They can then either accept or reject the offers.

The specific pairing mechanism will be explained to you based on your assigned role.

@button{Continue}})

This is a straightforward instructions step that explains the study to all participants before they are assigned to roles. The instructions are intentionally general since participants don’t yet know whether they will be Proposers or Responders.

4.2.6 Matchmaking🔗

;; =============================================================================

;; MATCHMAKING

;; =============================================================================

(defstep (waiter)

@md{# Please Wait

Please wait while other participants join your group...

@refresh-every[5]})

(define matchmaker (make-matchmaker 4))

(defstep (matchmake)

(matchmaker waiter))

The matchmaking section creates groups of 4 participants. We define a waiter step that displays while participants are waiting, then use make-matchmaker to create a matchmaker function for groups of 4. The matchmake step calls this function, passing it the waiter step to display while waiting.

When all 4 participants are matched into a group, they automatically proceed to the next step.

4.2.7 Responder Treatment Assignment🔗

;; =============================================================================

;; RESPONDER TREATMENT ASSIGNMENT

;; =============================================================================

(defstep (assign-responder-treatment)

; Balanced: out of every 2 responders, assign 1 to treatment, 1 to control

(with-study-transaction

(when (or (undefined? responder-treatments) (null? responder-treatments))

(set! responder-treatments (shuffle '(#t #f))))

(set! is-responder-treatment? (first responder-treatments))

(set! responder-treatments (rest responder-treatments)))

(skip))

This step uses the same pattern as role assignment, but only affects Responders. Out of every 2 Responders, one is assigned to treatment (#t) and one to control (#f). This ensures balanced assignment across the treatment conditions.

4.2.8 Proposer: Make Offers and Await Responder Choice🔗

;; =============================================================================

;; PROPOSER: MAKE OFFERS AND AWAIT RESPONDER CHOICE

;; =============================================================================

(define-values (offers-form offers-onsubmit)

(form+submit

[actual-offer (ensure binding/number (range/inclusive 0 5) (required))]

[communicated-offer (ensure binding/number (range/inclusive 0 5) (required))]))

(define (render-offers-form rw)

@md*{

@rw["actual-offer" @input-number{Actual offer (the real amount you will give): }]

@rw["communicated-offer" @input-number{Communicated offer (what the Responder sees): }]

@|submit-button|})

(defstep (proposer-make-offers)

@md{# Proposer: Make Your Offers

You are a **Proposer**.

Please choose two numbers between 0 and 5:

1. **Actual offer**: The real amount you would give to the Responder if chosen

2. **Communicated offer**: The amount you tell the Responder you will give

These two values can differ. The Responder will only see your communicated offer.

@form[offers-form offers-onsubmit render-offers-form]})

(defstep (store-proposer-offers)

(store-my-result-in-group! 'offer (list actual-offer communicated-offer))

(skip))

(defstep (proposer-wait-for-responder)

(define decision (filter values (current-group-member-results 'decision)))

(if (and decision (not (null? decision)))

(skip)

@md{# Waiting for Responder

You have submitted your offers. Please wait while the Responder makes their decision...

@refresh-every[5]}))

This section handles the Proposer experience. Let’s break it down:

4.2.9 Responder: View Offers and Make Decision🔗

;; =============================================================================

;; RESPONDER: VIEW OFFERS AND MAKE DECISION

;; =============================================================================

(defstep (responder-wait-for-offers)

; Check if all 3 proposers have submitted (we're the 4th member, so count should be 3)

(if (= 3 (current-group-results-count 'offer))

(skip)

@md{# Responder: Waiting for Proposers

You are assigned to be the **Responder**.

Please wait while all Proposers submit their offers...

@refresh-every[3]}))

; Helper to get sorted list of (pid communicated-offer) pairs

(define (get-offers-with-pids)

(define offers (current-group-member-results 'offer #:include-ids? #t))

;(sort offers < #:key car) ; We could sort offers, perhaps introducing bias

offers)

The responder-wait-for-offers step checks if all 3 Proposers have submitted their offers by counting the number of results stored under the 'offer key. If the count is 3, it skips to the next step; otherwise, it displays a waiting page.

The helper function get-offers-with-pids retrieves the offers from all group members along with their participant IDs. The #:include-ids? #t argument makes current-group-member-results return a list of (cons pid result) pairs. Note the commented-out line about sorting — the study deliberately doesn’t sort the offers to avoid introducing bias.

4.2.10 Outcomes🔗

4.2.11 Main Study Flow🔗

;; =============================================================================

;; MAIN STUDY FLOW

;; =============================================================================

(defstudy proposal-choice

[instructions

--> matchmake

--> assign-roles

--> ,(lambda ()

(if (equal? role 'responder)

'assign-responder-treatment

'proposer-make-offers))]

; Responder path

[assign-responder-treatment

--> responder-wait-for-offers

--> ,(lambda ()

(if is-responder-treatment?

'responder-view-offers-treatment

'responder-view-offers-control))]

[responder-view-offers-control

--> store-responder-decision

--> show-outcome-responder]

[responder-view-offers-treatment

--> store-responder-decision

--> show-outcome-responder]

; Proposer path

[proposer-make-offers

--> store-proposer-offers

--> proposer-wait-for-responder

--> show-outcome-proposer]

[show-outcome-proposer --> show-outcome-proposer]

[show-outcome-responder --> show-outcome-responder])

The transition graph uses inline lambda functions to route participants down different paths based on their role and treatment assignment. All participants start with the same sequence: instructions, matchmake, and assign-roles. After role assignment, the first conditional transition checks (equal? role 'responder) to send Responders to 'assign-responder-treatment and Proposers to 'proposer-make-offers.

Responders then encounter a second conditional transition that checks is-responder-treatment? to route them to either 'responder-view-offers-treatment or 'responder-view-offers-control. Both responder paths converge at store-responder-decision and end at show-outcome-responder. Meanwhile, Proposers follow their own linear path through making offers, storing them, waiting for the Responder’s decision, and seeing their outcome.

The final two transitions ([show-outcome-proposer --> show-outcome-proposer] and [show-outcome-responder --> show-outcome-responder]) make these terminal steps where participants remain once the study is complete.

4.2.12 Key Concepts Recap🔗

This tutorial demonstrated several advanced patterns for multi-participant studies:

• Role-based experiences: Using instance-scoped variables and conditional transitions to assign participants to different roles with completely different interfaces

• Conditional UI rendering: Creating multiple step definitions for different conditions (control vs. treatment) and routing participants to the appropriate version

• Information asymmetry: Storing multiple values (actual vs. communicated offers) and selectively revealing different information to different participants

• Pattern matching with match-define: Extracting values from complex nested data structures returned by group result functions

• Conditional data manipulation: Implementing random selection in code (control group) versus user selection (treatment group) before storing the final decision

• Coordination through waiting steps: Using current-group-results-count and refresh-every to create waiting steps that poll until all participants are ready

4.2.13 Next Steps🔗

This study demonstrates how to create rich, multi-role experiments with different experiences for different participants. You might want to explore:

• Add multiple rounds to the study, allowing participants to learn and adapt their strategies over time

• Implement feedback systems where participants can rate or comment on their experience

• Consult the Conscript Cookbook for more recipes and patterns for common study tasks