Datenvorverarbeitung und Synchronisierung von Playback Projekten: Unterschied zwischen den Versionen
(Diese Seite wurde zum Übersetzen freigegeben) |
|||
Zeile 1: | Zeile 1: | ||
− | <languages /> | + | <languages/> |
<translate> | <translate> | ||
Version vom 26. Juni 2023, 07:17 Uhr
Hinweis: Die Datenvorverarbeitung mit der Sessionsynchronisierung funktioniert nur für Sessions einer Durchführung, nicht Durchführungs-übergreifend.
Problemstellung
Bei Playback-Studien finden die Sessions für gewöhnlich asynchron statt. Um die Daten aller Sessions vergleichen zu können, müssen die Parts vor dem Resampling genau übereinandergelegt werden. Dieser Artikel erklärt das Verfahren, mit dem die Sessions (automatisiert) synchronisiert werden. Dabei müssen folgende Umstände beachtet werden:
- Ein Part in Session 1 ist in den seltensten Fällen exakt gleich lang wie derselbe Part in Session 2.
- Beinhaltet ein Part ein pausierbares Medium, so können in der Pause Zeiträume entstehen, in denen keine Daten erzeugt werden.
- Wird in der Studie eine Randomisierung verwendet, können Parts doppelt auftreten oder fehlen. Auch diese Daten müssen vergleichbar sein.
Synchronisierungsprozess
Die Synchronisierung passiert in mehreren Schritten, die in hier grafisch an zwei Beispielsessions dargestellt sind.
- Die Rohdaten:
- Die Sessions haben nacheinander stattgefunden und die Rohdaten sind gespeichert. Die Grenzlinien innerhalb eines Parts markieren Start- und Pausenevents eines abgespielten Mediums. Zwischen den Begrenzungen ist das Medium also pausiert, d.h. die in diesem Zeitraum ggf. erhobenen Daten sind nicht mehr Mediumsbezogen und damit für die Studie vernachlässigbar.
- Es werden Synchronisierungsevents erzeugt. Diese entsprechen jeweils dem Start-Event eines Mediums, also z.B. dem Abspielen eines Vodeos.
- Die Pausen innerhalb der Parts werden für das Resampling übersprungen.
- Dadurch entstehen ggf. Pausen zwischen den Parts, da Abschnitte entfernt wurden. Das Start-Event des nächsten Parts bleibt aber an Ort und Stelle und wird nicht mit verschoben.
- Die Sessions werden synchronisiert.
- Gedoppelte Parts innerhalb einer Session werden gebündelt übereinandergelegt.
- Die Synchroniesierungsevents aller Sessions werden übereinandergelegt. Dabei richten sich alle Parts nach demjenigen aus, welcher den meisten "Leerlauf" vor dem ersten Sync-Event hatte. Auch dadurch können also wieder Lücken entstehen.
- Part-End Events werden erstellt.
- Relative Zeitstempel werden erstellt. Es existieren 2 Arten von relativen Zeitstempeln:
- Session-bezogene relative Zeitstempel (Session Zeitstempel)
- Part-bezogener relativer Zeitstempel (Part-Zeitstempel)
Synchronisierung bei Live-Studien
In Live Studien können die Sessions auch versetzt beginnen (z.B. Wenn ein Teilnehmer später dazustößt oder leichte Latenzen auftreten). Die Part-Start Events dürfen in diesem Fall allerdings nicht synchronisiert werden, da die Daten sonst verschoben werden würden. In Live Studien muss also der absolute Zeitstempel das Maß bestimmen, also ein konkreter Zeitpunkt während der Studie, oder alternativ ein von den Durchführenden ausgehendes konkretes Event.