Overview
Many interactive environments respond to what a visitor is doing.
A personalized spatial environment goes further.
It can also adapt according to contextual information associated with the visitor, session, selected content, or experience condition.
For example, two visitors may enter the same physical environment but encounter:
- different visual content
- different interaction behaviour
- different narrative sequences
- different spatial responses
- different combinations of media
The challenge is that personalization can easily become tightly coupled to identity.
A fragile implementation may directly encode rules such as:
visitor A
→ content A
visitor B
→ content B
This works for a small installation but becomes difficult to reuse, extend, or study systematically.
A more flexible architecture introduces an intermediate representation:
Experience Profile
System Architecture
Left → Right
The responsive environment does not necessarily need to know who the visitor is. It needs to know which experience configuration should be active.
1. Personalization Is Not Identification
Identification answers:
Who or what has entered the system?
Personalization answers:
How should the experience behave for this session?
These are related but different responsibilities.
For example:
INPUT
participant selection
↓
IDENTIFICATION
input reference
↓
PERSONALIZATION
experience profile
↓
EXPERIENCE
content + interaction
The experience runtime does not necessarily need access to the original identifying input.
It can receive:
profile_id = theme_03
instead of:
visitor_name = ...
This separation reduces unnecessary dependence on personal information.
2. The Personalization Pipeline
A generalized personalization pipeline can be represented as:
System Architecture
Left → Right
The stages have different responsibilities.
Input
Receives contextual information.
Interpretation
Transforms the input into a meaningful system representation.
Experience Profile
Defines the active experience configuration.
Selection
Determines relevant content and interaction parameters.
Runtime
Executes the resulting spatial experience.
This allows the source of personalization to change without necessarily rewriting the experience itself.
3. Sources of Personalization
Personalization does not require one specific input technology.
Possible sources include:
scanned object
QR code
RFID
user selection
session condition
previous interaction
research condition
external application
physical token
Conceptually:
System Architecture
Left → Right
Different inputs can therefore produce the same profile representation.
For example:
RFID token
→ profile_02
and:
tablet selection
→ profile_02
can activate the same experience.
4. Experience Profiles
An experience profile is an abstract description of how the environment should behave for a session.
A profile may contain:
profile_id
theme_id
content_set
interaction_set
visual_parameters
audio_parameters
experience_condition
For example:
profile_id = profile_03
theme_id = theme_03
content_set = content_C
interaction_set = interaction_C
The profile becomes the interface between personalization logic and experience logic.
System Architecture
Left → Right
5. Why Use an Intermediate Profile?
Without an intermediate profile:
scanner
→ visitor information
→ TouchDesigner logic
→ content
The rendering application becomes responsible for understanding the original input system.
With an intermediate profile:
scanner
→ personalization service
→ experience profile
→ TouchDesigner
The runtime only needs to understand the profile.
This provides several advantages:
- input devices can change
- content can change
- runtime software can change
- research conditions can change
- personal information can remain outside the runtime
The profile becomes a stable contract.
6. Profile Example
A conceptual profile may look like:
profile_id: profile_03
theme_id: theme_03
content_set: set_03
interaction_set: interaction_03
visual_mode: floating_letters
audio_mode: ambient_03
The exact implementation may use:
JSON
REST
OSC
database record
local configuration
The architectural concept remains the same.
7. Profile Versus Session
A profile and a session are not the same thing.
A profile describes:
How should this experience behave?
A session describes:
Which occurrence of the experience is currently happening?
For example:
session_id = S0042
profile_id = profile_03
Another visitor may later receive the same profile:
session_id = S0057
profile_id = profile_03
The profile can therefore be reused across many sessions.
System Architecture
Left → Right
This distinction becomes important for research analysis.
8. Session Initialization
Personalization should normally be established before or during session initialization.
A simplified flow is:
visitor arrives
↓
input received
↓
profile resolved
↓
session created
↓
profile attached to session
↓
experience starts
Conceptually:
System Architecture
Left → Right
The session now carries an experience configuration.
9. Personalized Content Selection
A profile can determine which content is available.
For example:
profile_01
→ content_set_A
profile_02
→ content_set_B
profile_03
→ content_set_C
The runtime can request:
active_content_set
rather than implementing identification logic itself.
This separates:
WHY this content was selected
from:
HOW this content is presented
The personalization layer handles the first.
The experience runtime handles the second.
10. Personalization Beyond Content
Personalization does not need to mean only changing images or videos.
A profile may influence:
Visual Behaviour
particle behaviour
colour parameters
animation style
visual density
Audio Behaviour
sound layer
music variation
spatial audio response
Interaction Behaviour
active areas
interaction thresholds
available actions
response intensity
Narrative Behaviour
scene order
content sequence
ending condition
The architecture therefore supports personalized behaviour, not only personalized media.
11. Spatial Personalization
Personalization becomes particularly interesting when it affects the relationship between the visitor and physical space.
For example:
Profile A
→ Area 1 activates visual behaviour A
Profile B
→ Area 1 activates visual behaviour B
The physical area remains the same.
The meaning of the area changes according to the active profile.
System Architecture
Left → Right
This allows one physical environment to support multiple experience interpretations.
12. Profile + Interaction
K03 introduced interaction data such as:
presence
x
y
area_enter
area_exit
K05 adds profile context.
Instead of:
area_2_enter
→ play content B
the logic can become:
area_2_enter
+
profile_03
→ response(profile_03, area_2)
Conceptually:
System Architecture
Left → Right
The resulting response depends on both:
what the visitor does
and
which experience configuration is active.
13. Profile + Scene Architecture
K02 introduced scene-based experience logic.
Personalization can be integrated without replacing that architecture.
For example:
IDLE
↓
INTRO(profile)
↓
ACTIVE(profile)
↓
COMPLETE(profile)
↓
RESET
The scene structure remains stable.
The content inside the scenes changes according to the profile.
System Architecture
Left → Right
This avoids creating an entirely separate application for every personalized experience.
14. Shared Scene Structure
Suppose an installation has five profiles.
A fragile architecture might create:
Profile 1 application
Profile 2 application
Profile 3 application
Profile 4 application
Profile 5 application
A reusable architecture can instead use:
Shared Scene System
+
Active Profile
Conceptually:
PROFILE 1
↓
PROFILE 2
↓
SHARED → EXPERIENCE LOGIC
PROFILE 3
↓
PROFILE 4
↓
PROFILE 5
The same interaction engine can therefore support multiple experience variations.
15. Profile Resolution
The system needs a rule for transforming input into a profile.
Conceptually:
input
↓
lookup / mapping
↓
profile
For example:
input_reference_001
→ profile_03
The mapping may exist in:
- a local configuration
- a database
- a content-management system
- an API
- a study condition table
The runtime should not need to know how the mapping was resolved.
16. Personalization Service
For larger systems, profile resolution can become its own service.
System Architecture
Left → Right
The service may be responsible for:
input validation
profile lookup
session creation
profile assignment
configuration retrieval
This keeps personalization logic outside the rendering application.
17. Example Profile Interface
A runtime-facing profile might conceptually contain:
session_id
profile_id
theme_id
content_set
interaction_set
Example:
session_id = S0042
profile_id = profile_03
theme_id = theme_03
content_set = set_03
interaction_set = interaction_03
The runtime receives only what it needs.
Additional identifying or study information can remain elsewhere.
18. Profile State
Once an experience begins, the active profile should remain stable unless the experience explicitly supports dynamic personalization.
For example:
session starts
→ profile_03 loaded
→ profile_03 remains active
→ session ends
→ profile cleared
This prevents unexpected profile changes during the experience.
A simplified state flow is:
Rendering diagram
19. Reset Behaviour
Personalized systems require explicit reset behaviour.
After a session ends, the runtime should clear:
session_id
profile_id
selected content
temporary interaction state
visitor-specific runtime state
The environment can then return to:
IDLE
Conceptually:
System Architecture
Left → Right
Without a reliable reset, one visitor's configuration may leak into the next session.
20. Default Experience
The system should define what happens when no valid profile exists.
Possible behaviour includes:
idle experience
generic experience
request new input
fallback profile
For example:
profile_id = null
→ default_profile
A fallback should be explicit rather than accidental.
21. Invalid Input
Input resolution may fail.
Examples include:
unknown token
invalid QR
missing database record
network failure
expired session
The experience should not silently load an arbitrary profile.
A possible flow is:
input
↓
validate
↓
valid?
├── yes → profile
└── no → fallback / retry
This separates failure handling from experience logic.
22. Dynamic Personalization
Some experiences may adapt while the visitor is already inside the environment.
For example:
initial profile
+
interaction history
+
current spatial behaviour
→ updated experience parameters
This can be represented as:
System Architecture
Left → Right
This is more complex than static profile selection.
It should therefore be distinguished from basic personalization.
23. Personalization Versus Adaptation
These terms can describe different processes.
Personalization
Experience configuration is selected using information associated with the session.
input
→ profile
→ experience
Adaptation
Experience behaviour changes according to ongoing interaction.
behaviour
→ system interpretation
→ updated response
An environment can support either or both.
System Architecture
Left → Right
Keeping these concepts distinct makes the system easier to reason about.
24. Personalization and Research
Personalization introduces variables that may become relevant to research.
For example:
session_id
profile_id
theme_id
condition_id
These can be associated with the session.
Then researchers can examine behaviour under different experience configurations.
Conceptually:
SESSION
├── profile
├── trajectory
├── interaction events
└── study instruments
The profile becomes contextual information rather than the visitor's identity.
25. Logging Personalized Experiences
K04 established the core logging schema.
Personalization can extend it without changing the core trajectory structure.
For example:
Core session data
| Field | Example |
|---|---|
session_id | S0042 |
deployment_id | deployment_A |
status | completed |
Personalization extension
| Field | Example |
|---|---|
profile_id | profile_03 |
theme_id | theme_03 |
content_set | set_03 |
condition_id | condition_A |
Trajectory data remains:
session_id,timestamp,visitor_id,x,y,area
This means personalization context can change without changing the fundamental spatial logging model.
26. Research Comparison
Suppose multiple sessions use different profiles.
S0001 → profile_01
S0002 → profile_03
S0003 → profile_02
S0004 → profile_03
Later analysis can group sessions by:
profile_id
and compare measurements such as:
dwell time
area visits
trajectory patterns
interaction counts
questionnaire responses
This does not by itself establish that the profile caused behavioural differences.
It provides a structured basis for comparison when supported by the study design.
27. Personalization Without Personal Identity
A useful design principle is:
visitor identity
≠
experience profile
A visitor may provide information at check-in.
The system can transform that information into:
profile_id
The immersive runtime only receives the profile.
System Architecture
Left → Right
This limits the amount of personal information distributed across the system.
28. Identity Boundary
A conceptual architecture may create an explicit boundary.
IDENTITY DOMAIN
participant information
↓
profile resolution
──────────── boundary ────────────
EXPERIENCE DOMAIN
session_id
profile_id
interaction data
experience state
The experience domain does not need direct access to all information stored in the identity domain.
This supports both modularity and data minimization.
29. Anonymous Personalization
Personalization can also occur without identifying a visitor at all.
For example:
visitor chooses theme
→ profile created
→ session starts
No persistent personal identity is required.
Similarly:
physical token
→ profile
can provide a differentiated experience while the system remains unaware of who is holding the token.
Personalization should therefore not automatically be equated with personal-data collection.
30. Content Management
As the number of profiles grows, hard-coding every profile inside the runtime becomes difficult.
A content model may define:
PROFILE
│
├── theme
├── content
├── interaction configuration
└── media references
The runtime can load configuration rather than contain all personalization rules internally.
System Architecture
Left → Right
This allows content changes without necessarily changing interaction-engine code.
31. Profile Versioning
Profiles may evolve.
For example:
profile_03
version 1
may later become:
profile_03
version 2
If research data is collected across versions, the dataset should preserve which configuration was used.
Possible fields include:
profile_id
profile_version
system_version
This allows later analysis to distinguish sessions produced by different configurations.
32. Profile Composition
A profile does not necessarily need to be one monolithic object.
It can be composed from several dimensions.
For example:
Experience Profile
theme
+
content set
+
interaction set
+
visual parameters
+
audio parameters
This allows combinations such as:
Theme A + Interaction 1
Theme A + Interaction 2
Theme B + Interaction 1
Composition can reduce duplicated configuration.
33. Profile Inheritance
For larger systems, several profiles may share common defaults.
Conceptually:
DEFAULT PROFILE
│
├── visual defaults
├── audio defaults
└── interaction defaults
↓
PROFILE 03
├── theme = 03
└── interaction override
This allows common behaviour to remain centralized.
Profile inheritance is an implementation option rather than a requirement, but it becomes useful as the number of experience variations grows.
34. Spatial Meaning as Configuration
An advanced personalization system can change not only content but the meaning of space itself.
For example:
Area 1
may represent:
Profile A → rhythm interaction
Profile B → narrative fragment
Profile C → visual transformation
The physical geometry remains unchanged.
The semantic mapping changes.
This can be represented as:
System Architecture
Left → Right
This creates a configurable relationship between physical space and experience meaning.
35. Shared Physical Infrastructure
A major benefit of this architecture is that multiple personalized experiences can share the same physical infrastructure.
For example:
SENSORS
PROJECTORS
AUDIO
ROOM
INTERACTION ENGINE
remain constant.
Only:
profile
content
interaction configuration
change between sessions.
This can make personalized responsive environments operationally practical without duplicating the entire installation.
36. Personalization Failure Boundaries
Failures should remain localized where possible.
For example:
profile lookup fails
should not necessarily cause:
sensor server failure
Similarly:
media file missing
should not destroy:
session logging
A modular architecture creates failure boundaries.
System Architecture
Left → Right
Each subsystem can report its own state.
37. Personalized Experience Architecture
The complete architecture can now be represented as:
System Architecture
Left → Right
The experience response is therefore produced from three major forms of context:
PROFILE
+
INTERACTION
+
SESSION STATE
rather than from identity alone.
38. Relationship to K01–K04
The Knowledge architecture now contains five complementary layers.
K01 — Modular Sensor Server Architecture
How should sensing infrastructure be separated?
K02 — Scene-Based Interaction
How should experience behaviour be structured?
K03 — Raw Sensor Data to Interaction Data
How do physical measurements become interaction information?
K04 — Spatial Interaction Logging & Session Architecture
How should interactions become research-ready observations?
K05 — Personalized Spatial Experience Architecture
How can contextual input configure the experience without coupling the runtime directly to identity?
Together:
System Architecture
Left → Right
K05 introduces a second input into experience logic:
what the visitor is doing
plus
which experience configuration is active.
39. Relationship to Research Infrastructure
Personalization also extends the research model.
SESSION
│
├── EXPERIENCE CONTEXT
│ ├── profile_id
│ ├── theme_id
│ └── condition_id
│
├── SPATIAL OBSERVATIONS
│ ├── trajectory
│ ├── area events
│ └── interaction events
│
├── EXPERIENCE EVENTS
│ ├── scene transitions
│ └── content responses
│
└── STUDY INSTRUMENTS
├── questionnaire
├── interview
└── observation
This provides a structure for examining how different experience configurations relate to observed interaction patterns.
40. Design Principles
Several design principles emerge.
Separate identity from experience configuration
The runtime should receive only the information required to control the experience.
Use an intermediate experience profile
Input systems and experience systems should communicate through a stable representation.
Keep profiles separate from sessions
Profiles can be reused; sessions represent individual occurrences.
Personalize behaviour, not only content
Interaction rules and spatial meaning can also vary.
Preserve shared experience architecture
Avoid building an entirely separate application for every profile when common logic can be reused.
Define fallback behaviour
Invalid or missing personalization input should produce an explicit system state.
Reset between sessions
Temporary personalized state must not leak into the next experience.
Version profiles used in research
Changes to personalization configuration should remain traceable.
41. Limitations
Personalization introduces additional complexity.
Possible challenges include:
- profile-management overhead
- incorrect input-to-profile mapping
- increased content requirements
- inconsistent experience quality across profiles
- additional testing combinations
- privacy considerations
- profile versioning
- interaction conflicts
- dynamic adaptation complexity
More personalization does not automatically produce a better experience.
The degree of personalization should be justified by the experience and research goals.
42. Research Direction
Personalized spatial environments create several research questions.
Examples include:
- How does personalized spatial content affect visitor engagement?
- Does changing the meaning of interaction areas influence movement patterns?
- How do visitors perceive environments that respond differently across sessions?
- What level of personalization is noticeable or meaningful?
- Can personalization be provided without persistent personal identification?
- How should personalized experiences remain comparable across research sessions?
- How can adaptive behaviour be distinguished from predetermined personalization?
- How do profile-specific spatial responses affect exploration and dwell?
A broader question is:
How can responsive environments provide meaningful individualized experiences while preserving reusable interaction architecture and research comparability?
This connects personalization with spatial interaction, HCI, responsive environments, and research infrastructure.
43. Key Takeaways
Personalization should not be implemented as a direct dependency between personal identity and media content.
A more reusable architecture is:
Input → Profile Resolution → Experience Profile → Experience Logic → Personalized Spatial Response
The experience profile becomes an intermediate representation between contextual input and the responsive environment.
The final response can depend on:
Experience Profile
+
Spatial Interaction
+
Session State
rather than personal identity alone.
Profiles can configure:
- content
- visual behaviour
- audio behaviour
- interaction rules
- narrative structure
- spatial meaning
The same physical infrastructure and experience engine can therefore support multiple differentiated experiences.
For research, the profile becomes contextual session information that can be associated with trajectories, interaction events, derived metrics, and study instruments without changing the core spatial logging schema.
The broader principle is:
Personalize the experience through an abstract configuration layer, not by embedding personal identity directly into the runtime.