Anket Akışı Nasıl Tasarlanır? Skip Logic, Branching ve Koşullu Sorular Rehberi

İyi bir anket yalnızca iyi soru yazmak değildir. İyi anket, doğru katılımcıya doğru soruyu doğru sırada göstermektir.

Bir katılımcıya hiç yaşamadığı bir deneyim hakkında soru sormak veri kalitesini bozar. Ama bunun tersi de en az onun kadar tehlikelidir: Görmesi gereken kritik bir soruyu hiç göstermemek veri kaybına yol açar.

Bu yüzden büyük ve karmaşık araştırmalarda anket akışı, teknik bir ayrıntı değil, metodolojik bir mimari meselesidir.

Skip Logic, Branching Logic ve Conditional Logic bu mimarinin temel araçlarıdır. Doğru kullanıldığında katılımcı yorgunluğunu azaltır, ilgisiz soruları gizler, hassas soruları yalnızca ilgili gruplara gösterir ve daha temiz veri üretir. Yanlış kullanıldığında ise bazı katılımcılar yanlış blokları görür, bazıları görmesi gereken soruları hiç görmez, export verisinde açıklanması zor missing data oluşur ve raporlama zayıflar.

Bu rehber, anket akışının nasıl tasarlanacağını, gatekeeper soruların nasıl kullanılacağını, çok dilli anketlerde logic’in nasıl korunacağını, sık yapılan flow hatalarını, test süreçlerini ve PublicOp Advanced Polls’un bu iş akışındaki rolünü açıklar.

Anket akışı nedir?

Anket akışı, katılımcının anket boyunca hangi soruları hangi sırayla göreceğini belirleyen yapıdır.

Basit bir ankette akış düz olabilir:

Soru 1
Soru 2
Soru 3
Soru 4
Teşekkür ekranı

Ama karmaşık araştırmalarda tüm katılımcıların aynı soruları görmesi doğru olmayabilir.

Örneğin:

Bir ürünü hiç kullanmamış kişiye ürün deneyimi soruları gösterilmez.
Belirli bir eğitime katılmamış kişiye eğitim memnuniyeti sorulmamalı.
Consent vermeyen katılımcı araştırmaya devam etmemeli.
Düşük puan veren katılımcıya “neden?” sorusu sorulmalı.
Belirli roldeki katılımcılar farklı soru bloklarına yönlendirilmeli.

Bu durumda anket akışı koşullu hale gelir.

Skip Logic ve Branching Logic nedir?

Skip Logic, katılımcının cevabına göre bazı soruların atlanmasını sağlar.

Basit örnek:

Soru:
Son 6 ayda bu ürünü kullandınız mı?

- Evet
- Hayır

Akış:

Eğer cevap Evet ise:
Ürün deneyimi sorularını göster.

Eğer cevap Hayır ise:
Ürün deneyimi sorularını atla.

Branching Logic ise katılımcıyı farklı yollara veya bölümlere yönlendirmeyi ifade eder.

Örnek:

Eğer katılımcı öğretmense:
Öğretmen bloğuna git.

Eğer katılımcı öğrenciyse:
Öğrenci bloğuna git.

Eğer katılımcı kurum temsilcisiyse:
Kurum temsilcisi bloğuna git.

Skip Logic daha çok “atla” mantığını, Branching Logic ise “farklı yola yönlendir” mantığını anlatır. Pratikte ikisi aynı koşullu akış tasarımının parçalarıdır.

Neden anket akışı veri kalitesi için kritiktir?

Anket akışı yalnızca katılımcı deneyimiyle ilgili değildir. Doğrudan veri kalitesini etkiler.

Kötü akışın etkileri:

• katılımcıya ilgisiz soru gösterilir,
• katılımcı yorulur ve anketi bırakabilir,
• yanlış kişiler yanlış soruları cevaplar,
• doğru kişiler bazı kritik soruları hiç görmez,
• export verisinde açıklanması zor missing data oluşur,
• raporda payda yanlış yorumlanabilir,
• aynı kavram farklı yerlerde farklı şekilde ölçülebilir,
• sonuçlar güven kaybeder.

İyi akışın etkileri:

• yalnızca ilgili sorular gösterilir,
• katılımcı deneyimi daha kısa ve anlamlı olur,
• hassas sorular gereksiz yere açılmaz,
• veri daha temiz olur,
• analizde alt gruplar daha doğru ayrılır,
• raporlama dili daha güvenli hale gelir.

Kısacası, iyi anket akışı görünmez bir kalite kontrol katmanıdır.

PublicOp’ta Branching / Skip Logic nasıl çalışır?

PublicOp’ta Branching / Skip Logic, Advanced Polls modülünde kullanılır. QuickPoll, kısa ve lineer geri bildirim anketleri için tasarlanmıştır; karmaşık logic içermez.

Advanced Polls içinde akış kuralları temel olarak IF / THEN mantığıyla çalışır:

IF:
Katılımcı şu soruda şu seçeneği işaretlediyse

THEN:
Şu soruya git
Şu bölüme git
Şu bölümü atla
Anketi sonlandır

PublicOp’ta bu mantık metinlere değil, arka plandaki Question ID ve Option ID yapılarına dayanır. Yani kural “Evet” kelimesine değil, o seçeneğin görünmez kimliğine bağlanır.

Bu özellikle çok dilli anketlerde önemlidir. Çünkü Türkçe’de “Evet”, İngilizce’de “Yes”, Fransızca’da “Oui”, Almanca’da “Ja” yazsa bile aynı Option ID korunuyorsa logic aynı şekilde çalışır.

Rule Builder nedir?

PublicOp’ta logic kuralları Görsel Editör içindeki Logic Editor / Rule Builder üzerinden oluşturulur.

Genel yapı şöyledir:

IF cevap belirli koşulu karşılıyorsa
THEN belirli hedefe yönlendir

Örneğin:

IF “Bu hizmeti kullandınız mı?” = “Hayır”
THEN “Hizmet deneyimi” bölümünü atla.

Rule Builder, araştırmacının kurguladığı koşullu akışı uygular. Ancak kuralı kendiliğinden tasarlamaz. Hangi sorunun hangi cevaba göre hangi bloğu açacağı araştırmacı tarafından düşünülmelidir.

Bu ayrım önemlidir:

PublicOp flow’u uygular.
Araştırmacı flow’u tasarlar.

Hangi soru tipleri logic için uygundur?

Branching / Skip Logic için en sağlıklı soru tipleri kapalı uçlu ve seçenekli sorulardır.

Single choice

Single choice, logic kurmak için en temiz ve en çok önerilen soru tipidir.

Örnek:

Son 6 ayda bu hizmeti kullandınız mı?

- Evet
- Hayır

Bu soru üzerinden net bir akış kurulabilir.

Evet -> Deneyim soruları
Hayır -> Deneyim sorularını atla

Multiple choice

Multiple choice sorular üzerinden de belirli bir seçeneğin seçilip seçilmediğine göre kural kurulabilir.

Örnek:

Hangi hizmetleri kullandınız?

- Hizmet A
- Hizmet B
- Hizmet C

Eğer katılımcı “Hizmet B” seçtiyse, Hizmet B deneyim bloğu açılabilir.

Ancak multiple choice logic, single choice’a göre daha karmaşık hale gelebilir. Özellikle aynı katılımcı birden fazla blok açacaksa test yükü artar.

Likert / rating

Likert veya rating yanıtları seçenek gibi tasarlandığında logic için kullanılabilir.

Örnek:

Bu hizmeti 1-5 arasında nasıl değerlendirirsiniz?

Düşük puan verenlere ek soru açılabilir:

Eğer puan 1, 2 veya 3 ise:
“Bu puanı vermenizin ana nedeni nedir?” sorusunu göster.

Consent

Consent soruları da akış yönlendirme için kullanılabilir.

Örnek:

Araştırmaya katılmayı kabul ediyor musunuz?

- Evet, kabul ediyorum
- Hayır, kabul etmiyorum

Akış:

Hayır -> End survey
Evet -> Anket sorularına devam

Numeric input ve açık uçlu metinler

PublicOp’ta logic, ağırlıklı olarak kapalı uçlu seçeneklere dayanır. Numeric input, Short text veya Long text içeriğine göre “yaş > 18” veya “metin şu kelimeyi içeriyor” gibi logic kurmak desteklenmez.

Bu yüzden yaş, gelir aralığı, deneyim durumu gibi akış belirleyecek değişkenler gerekiyorsa bunları seçenekli soru olarak tasarlamak daha güvenlidir.

Örnek:

Yaş grubunuz nedir?

- 18 yaş altı
- 18-24
- 25-34
- 35-44
- 45+

Bu yapı logic için numeric input’tan daha uygundur.

Desteklenen temel koşul türleri

PublicOp’ta logic kapalı uçlu yanıtlar üzerinden kurulur.

Desteklenen başlıca koşullar:

equals
not equals
selected option includes
selected option does not include
contains
does not contain

Özellikle multiple choice sorularda “seçenek içeriyor mu?” mantığı kullanışlıdır.

Desteklenmeyen veya gelişmiş logic kapsamında olmayan yapılar:

greater than
less than
is empty
is not empty
karmaşık nested condition
gelişmiş AND / OR gruplama
numeric range logic
metin içeriğine dayalı logic

Birden fazla kural zincirleme kurulabilir, ancak çok karmaşık iç içe koşullar desteklenmez. Bu nedenle akış tasarımını mümkün olduğunca sade tutmak daha doğrudur.

Logic sonucunda hangi aksiyonlar yapılabilir?

PublicOp Advanced Polls’ta logic sonucunda şu tür yönlendirmeler yapılabilir:

Skip to question
Skip to section
Skip to section end
End survey

Bunların anlamı şöyledir:

Skip to question

Katılımcıyı belirli bir sonraki soruya gönderir. Aradaki sorular atlanır.

Skip to section

Katılımcıyı belirli bir bölüme yönlendirir. Büyük bloklar için daha temiz bir yapıdır.

Skip to section end

Katılımcının belirli bir bölümü atlamasını sağlar.

End survey

Katılımcının anketini sonlandırır. Consent vermeyenler veya uygun olmayan katılımcılar için screen-out akışında kullanılabilir.

Desteklenmeyen aksiyonlar:

• logic ile farklı rapor sayfasına gönderme,
• logic ile farklı sonuç ekranı üretme,
• logic ile soruyu zorunlu veya opsiyonel hale getirme,
• logic ile default değer atama,
• logic ile soru metnini değiştirme.

Soru metnini dinamik değiştirme logic ile değil, Piping ile ilgilidir.

Section yapısı neden önemlidir?

Büyük anketlerde logic’i tek tek soru düzeyinde kurmak hızla karmaşıklaşabilir. Bu nedenle PublicOp Advanced Polls’ta Section yapısı önemlidir.

Section, anketin bölümlere veya sayfalara ayrılmasıdır.

Örnek yapı:

Section 1: Demografi
Section 2: Ürünü kullananlar
Section 3: Ürünü kullanmayanlar
Section 4: Memnuniyet değerlendirmesi
Section 5: Açık uçlu geri bildirim

Best practice şudur:

Aynı deneyime ait soruları aynı section içinde gruplayın.
Farklı grupların göreceği soruları aynı section içine karıştırmayın.
Gatekeeper soruya göre katılımcıyı ilgili section’a yönlendirin.

Kötü yapı:

Bir sayfada hem kullananlara hem kullanmayanlara özel sorular karışık durur.
Her soru için ayrı ayrı karmaşık logic kurulur.

Daha iyi yapı:

Ürünü kullananlara özel sorular ayrı section’da.
Ürünü kullanmayanlara özel sorular ayrı section’da.
Gatekeeper soru bu section’lara yönlendirir.

Bu yaklaşım hem test etmeyi hem de export sonrası yorumlamayı kolaylaştırır.

Gatekeeper soru nedir?

Gatekeeper question veya trigger question, bir katılımcının anketin sonraki bölümünde hangi soruları göreceğini belirleyen ana sorudur.

Örnek:

Son 6 ayda bu hizmeti kullandınız mı?

Bu soru, sonraki büyük blokları açıp kapatır.

Evet -> Kullanım deneyimi bloğu
Hayır -> Kullanım deneyimi bloğunu atla

Gatekeeper soru, anket akışının kapısıdır.

İyi gatekeeper sorular:

• net yazılır,
• kapalı uçludur,
• seçenekleri birbirini dışlar,
• analiz için de anlamlıdır,
• aynı kavramı tekrar tekrar sormaz,
• ilgili tüm blokları tek bir ana cevaba bağlar.

Aynı gatekeeper değişkeni iki kez sorulmamalı

Büyük araştırmalarda sık yapılan hatalardan biri, aynı kavramı farklı yerlerde benzer sorularla tekrar sormaktır.

Örneğin:

Bu hizmeti kullandınız mı?

ve daha sonra:

Bu hizmetten yararlandınız mı?

Eğer bu iki soru farklı blokları açıyorsa, katılımcı iki yerde farklı cevap verdiğinde logic çatışır.

Bu durum şu sorunlara yol açabilir:

• hangi cevabın ana değişken olduğu belirsizleşir,
• farklı bloklar farklı trigger’lara bağlanır,
• veri analizinde çelişkiler oluşur,
• bazı katılımcılar gereksiz blokları görür,
• bazı katılımcılar görmesi gereken blokları kaçırır.

Daha iyi uygulama:

Bir ana gatekeeper soru belirleyin.
Tüm ilgili blokları bu sorunun Option ID’lerine bağlayın.
Aynı kavramı ikinci kez trigger olarak sormayın.

Gerekirse sonraki sorularda açıklama veya detay isteyin, ama akışın ana kapısını tek tutun.

Çok taraflı deneyim soruları nasıl tasarlanmalı?

Bazı araştırmalarda deneyim yalnızca katılımcının kendisiyle ilgili değildir. Partner, aile üyesi, ekip arkadaşı, kurum veya başka bir kişiyle ilgili olabilir.

Genel örnek:

Bu deneyimi kim yaşadı?

- Ben
- Partnerim / başka kişi
- İkimiz de
- Hiç kimse

Bu tür sorular flow açısından dikkat ister.

Basit mantık şöyledir:

Ben -> katılımcının kendi deneyim bloğu
Partnerim / başka kişi -> partner / başka kişi bloğu
İkimiz de -> önce kendi deneyim bloğu, sonra partner / başka kişi bloğu
Hiç kimse -> ilgili blokları atla

Bu tür gatekeeper sorular için genellikle Single choice daha temizdir. Multiple choice kullanıldığında, katılımcı aynı anda birçok seçenek işaretleyebilir ve logic ağacı hızla karmaşıklaşabilir.

Özellikle “ikimiz de” seçeneği varsa bunun neyi açacağı baştan net düşünülmelidir.

Örnek:

“Ben” seçeneği sadece self bloğunu açar.
“Partnerim” seçeneği sadece partner bloğunu açar.
“İkimiz de” seçeneği self bloğunu ve ardından partner bloğunu açar.
“Hiç kimse” seçeneği her iki bloğu da atlar.

Burada amaç, her bloğun hangi cevaplarla açılacağını açık ve tekil biçimde belirlemektir.

Piping ile Branching / Skip Logic karıştırılmamalı

Piping, önceki cevabı sonraki soru metnine taşımaktır.

Örnek:

Önceki soru:
En çok hangi hizmeti kullandınız?
Cevap:
Hizmet A

Sonraki soru:
Hizmet A ile ilgili deneyiminizi anlatır mısınız?

Piping soru metnini kişiselleştirir.

Branching / Skip Logic ise anketin yönünü değiştirir.

Örnek:

Eğer Hizmet A seçildiyse:
Hizmet A sorularına git.

Eğer Hizmet B seçildiyse:
Hizmet B sorularına git.

Kısaca:

Piping = metni değiştirir.
Branching / Skip Logic = akışı değiştirir.

Bu iki özellik birlikte kullanılabilir, ama aynı şey değildir.

QuickPoll ve Advanced Polls ayrımı

PublicOp’ta QuickPoll ve Advanced Polls farklı ihtiyaçlara hizmet eder.

QuickPoll:

• kısa,
• hızlı,
• lineer,
• düşük sürtünmeli,
• logic içermeyen geri bildirimler için uygundur.

Advanced Polls:

• daha uzun,
• bölümlü,
• koşullu akış içeren,
• hedef gruplara göre farklı yollar açan,
• derin araştırmalar için uygundur.

Makalede ayrım net olmalıdır:

Kısa ve standart anket = QuickPoll
Koşullu akış ve kapsamlı araştırma = Advanced Polls

Karmaşık logic gerekiyorsa QuickPoll zorlanmamalı, Advanced Polls kullanılmalıdır.

Çok dilli anketlerde logic nasıl korunur?

Çok dilli anketlerde logic’in metinlere değil, ID’lere dayanması kritik önemdedir.

PublicOp’ta logic:

Question ID
Option ID

üzerinden çalışır.

Bu nedenle farklı dillerde seçenek metni değişse bile, aynı Option ID korunuyorsa logic bozulmaz.

Örnek:

Türkçe: Evet
İngilizce: Yes
Fransızca: Oui
Almanca: Ja

Bunlar aynı Option ID’ye bağlıysa aynı logic kuralını tetikler.

Bu PublicOp’un çok dilli araştırmalar için güçlü yanlarından biridir. Ancak bunun bir şartı vardır:

Anketin soru ağacı tüm dillerde simetrik olmalıdır.

Yani İngilizce versiyonda başka bir akış, Fransızca versiyonda tamamen farklı bir akış kurmak desteklenmez. Single dataset mimarisi gereği tüm diller aynı temel soru yapısını paylaşır.

Çeviri logic’i bozmaz, ama anlamı bozabilir

AI çeviri veya manuel çeviri, teknik olarak Option ID’leri değiştirmezse logic’i bozmaz. Ancak çeviri sırasında seçenek anlamı değişirse metodolojik risk doğar.

Örneğin bir seçeneğin Türkçe anlamı “hiç kullanmadım” iken, başka dilde “nadiren kullandım” gibi çevrilirse, aynı Option ID farklı anlam taşımaya başlar. Teknik flow çalışır, ama metodolojik anlam bozulur.

Bu nedenle çok dilli logic tasarımında şu kontroller yapılmalıdır:

• tüm dillerde seçenek anlamları aynı mı?
• gatekeeper seçenekleri doğru çevrilmiş mi?
• “hiçbiri”, “ikisi de”, “uygun değil” gibi seçenekler doğru karşılanmış mı?
• tüm dillerde aynı soru ağacı korunmuş mu?
• preview mode’da farklı dillerde aynı cevap yolları test edilmiş mi?

LANGUAGE column logic koşulu değildir

PublicOp çok dilli anketlerde LANGUAGE column tutar. Bu sütun, katılımcının hangi dilde yanıt verdiğini export ve analizde kullanmak için değerlidir.

Ancak LANGUAGE column üzerinden “yalnızca şu dilde yanıtlayanlara ek soru göster” gibi logic kurmak desteklenmez. Logic, katılımcı cevaplarına bağlıdır; yanıt diline göre ayrı akış desteklenmez.

Dil bazlı analiz daha sonra Live Report, Global Filter veya export sonrası analizde yapılmalıdır.

Logic veri kalitesini nasıl artırır?

Doğru kullanılan logic, veri kalitesine doğrudan katkı sağlar.

Gereksiz soruları gizler

Katılımcıya ilgisiz sorular gösterilmez. Bu da anketi kısaltır ve yorgunluğu azaltır.

Deneyime dayalı soruları doğru gruba gösterir

Bir deneyimi yaşamayan katılımcıya o deneyimle ilgili detay sorulmaz.

Hassas soruları sınırlı gösterir

Hassas sorular yalnızca ilgili gruplara gösterilebilir. Ancak bu, etik riski tamamen ortadan kaldırmaz.

Daha temiz alt grup verisi üretir

Belirli bir ürünü kullananlar, belirli roldeki katılımcılar veya belirli puanı verenler ayrı bloklara yönlendirilebilir.

Açık uçlu takip sorularını daha anlamlı hale getirir

Örneğin düşük puan verenlere “neden?” sorusu sormak, yüksek puan veren herkese aynı soruyu sormaktan daha hedeflidir.

Sık görülen flow hataları

Büyük ve karmaşık araştırmalarda bazı flow hataları tekrar tekrar görülür.

Yanlış kişiye soru göstermek

Bir deneyimi yaşamayan katılımcıya o deneyimle ilgili soru gösterilirse veri kirlenir.

Örnek:

Bir hizmeti kullanmamış kişiye “Hizmet kalitesini nasıl değerlendirirsiniz?” diye sormak.

Doğru kişiye soru göstermemek

Bu daha sessiz ama çok tehlikeli bir hatadır. Katılımcı ilgili gruptadır, ama logic hatası nedeniyle kritik soruyu hiç görmez.

Bu durumda veri eksik kalır ve çoğu zaman ancak export sonrası kontrolle fark edilir.

Aynı kavramı iki farklı trigger soru ile sormak

Aynı deneyim veya statü iki yerde tekrar sorulursa çelişkili cevaplar oluşabilir. Hangi cevabın flow’u belirlediği belirsizleşir.

Aynı bloktaki soruları farklı koşullara bağlamak

Bir bloktaki ilk sorular doğru kişilere açılırken son sorular başka koşula bağlı olabilir. Bu durumda blok içi eksiklik oluşur.

Best practice:

Aynı bloktaki tüm sorular aynı ana trigger koşuluna bağlanmalıdır.

“İkisi de” seçeneğini eksik yorumlamak

Self / partner / both gibi çok taraflı yapılarda “ikisi de” seçeneği hem self hem partner bloğunu açmalıdır. Sadece bir bloğa bağlanırsa veri eksik kalır.

Consent akışını yanlış kurmak

Consent vermeyen katılımcının ankete devam etmesi etik ve metodolojik sorun yaratır. Consent ret cevabı genellikle End survey ile sonlandırılmalıdır.

Kısmi kayıtları flow hatası sanmak

Katılımcının anketi yarıda bırakması flow hatası değildir. Flow validasyonu yapılırken kısmi kayıtlar dikkatle ayrıştırılmalıdır.

Completed kayıtları kontrol etmeden flow’un doğru çalıştığını varsaymak

Preview başarılı olsa bile, yayın sonrası export verisinde mantıksal kontroller yapılmalıdır.

Logic test etme neden zorunludur?

Logic tasarımı test edilmeden yayınlanmamalıdır.

Çünkü bir logic hatası çoğu zaman ekranda hemen fark edilmez. Katılımcı sadece kendisine gösterilen yolu görür. Görmesi gereken ama gösterilmeyen soruyu fark edemez.

Bu yüzden araştırmacı farklı cevap yollarını test etmelidir.

PublicOp’ta preview / test mode ile anket farklı cevap senaryoları üzerinden denenebilir. Çok dilli anketlerde farklı diller arasında geçiş yapılarak aynı flow’un korunup korunmadığı kontrol edilebilir.

Ancak PublicOp tüm unreachable question, logic conflict veya flow validation sorunlarını otomatik tespit etmez. Manuel test şarttır.

Logic test checklist’i

Yayın öncesi şu kontroller yapılmalıdır:

Tüm gatekeeper sorular test edildi mi?
Her cevap seçeneği için hangi blokların açıldığı kontrol edildi mi?
“Hiçbiri” veya “uygun değil” seçenekleri doğru blokları atlıyor mu?
“İkisi de” gibi seçenekler gereken tüm blokları açıyor mu?
Consent vermeyen katılımcı doğru şekilde sonlandırılıyor mu?
Düşük puan veren katılımcı takip sorusunu görüyor mu?
Yüksek puan veren katılımcı gereksiz takip sorusunu atlıyor mu?
Her section’a en az bir test yolundan ulaşılabiliyor mu?
Aynı bloktaki tüm sorular aynı koşulla açılıyor mu?
Çok dilli versiyonlarda aynı cevaplar aynı akışı üretiyor mu?

Persona bazlı test senaryoları oluşturmak çok faydalıdır.

Örnek:

Hiç deneyimi olmayan katılımcı
Yalnızca kendi deneyimi olan katılımcı
Partner / başka kişi deneyimi olan katılımcı
İki taraf için de deneyim olan katılımcı
Belirli yaş altında olan katılımcı
Belirli roldeki katılımcı
Consent vermeyen katılımcı
Düşük puan veren katılımcı
Yüksek puan veren katılımcı

Bu senaryolar sırayla denenmeden büyük bir anket yayına alınmamalıdır.

Yayın sonrası flow validasyonu

Yayın öncesi test yetmez. Gerçek veri geldikten sonra flow validasyonu yapılmalıdır.

Yayın sonrası kontrol şu sorularla yapılabilir:

Bu bloğu görmemesi gereken kaç kişi cevaplamış?
Bu bloğu görmesi gereken kaç kişi boş bırakmış?
Gatekeeper cevabı ile blok cevapları tutarlı mı?
Aynı bloktaki sorular aynı sayıda kişiye açılmış mı?
“İkisi de” diyenler iki ilgili bloğu da cevaplamış mı?
Consent vermeyen kayıtlar devam etmiş mi?

Bu kontroller özellikle completed kayıtlar üzerinden yapılmalıdır. Partial kayıtlar ayrıca incelenebilir, ama her boşluk flow hatası sayılmamalıdır. Katılımcı o noktada anketi terk etmiş olabilir.

PublicOp bu validasyonu otomatik olarak yapmaz. Araştırmacı Data Export aldıktan sonra Excel, SPSS veya başka analiz araçlarıyla mantıksal çapraz kontrolleri kendisi yapmalıdır.

Logic sonrası export verisi nasıl yorumlanmalı?

Skip edilen sorular export içinde boş, null veya system missing olarak görünebilir.

Burada önemli sınır şudur:

PublicOp export içinde “soruyu gördü ama cevaplamadı” ile “logic nedeniyle soru gösterilmedi” durumlarını otomatik ayrı etiketlerle ayırmaz.

Bu nedenle missing data yorumlanırken logic haritası dikkate alınmalıdır.

Örnek:

Bir bloğun boş olması gerçekten cevapsızlık mı?
Yoksa katılımcı o bloğu hiç görmedi mi?

Bu ayrım raporlamada kritiktir.

Doğru raporlama dili bazen şudur:

Bu soruya yanıt veren katılımcılar arasında...

Bazı durumlarda şu ifade riskli olabilir:

Bu koşulu sağlayan katılımcılar arasında...

Eğer flow hatası veya versiyon farkı varsa, daha temkinli dil kullanılmalıdır.

PublicOp export’ta Variable Labels, Value Labels, Codebook ve LANGUAGE column yapısını korur. Logic kullanılması bu export yapısını bozmaz. Ancak boşlukların yorumlanması araştırmacının veri temizleme sorumluluğudur.

Live Report logic kullanılan anketlerde nasıl çalışır?

PublicOp’ta logic ile bir soru atlanmışsa, Live Report ilgili soruyu yalnızca gören ve yanıtlayan kişiler üzerinden raporlar. Soruyu hiç görmeyen katılımcılar o sorunun paydasına dahil edilmez.

Bu davranış çoğu durumda doğrudur. Çünkü bir soruyu hiç görmemiş kişiyi o sorunun cevapsızı gibi saymak yanıltıcı olur.

Ancak rapor yorumlarken payda dikkatle okunmalıdır.

Örneğin:

Bu soruyu 100 katılımcı değil, yalnızca ilgili bloğu gören 37 katılımcı yanıtlamış olabilir.

Global Filter ile belirli alt gruplar incelenebilir. Örneğin yalnızca belirli roldeki veya belirli deneyime sahip katılımcıların yanıtları filtrelenebilir.

Ama örneklem küçüldükçe yorum gücü azalır. Çok fazla branching, çok küçük alt gruplar üretebilir.

Ne zaman logic kullanılmamalı?

Logic güçlüdür, ama her yerde kullanılmamalıdır.

Aşağıdaki durumlarda daha dikkatli olunmalıdır:

• küçük örneklem varsa,
• her küçük fark için ayrı yol oluşturuluyorsa,
• anketin bakımı zorlaşıyorsa,
• test senaryosu sayısı kontrol edilemeyecek kadar artıyorsa,
• bazı soruların hiç görünmemesi riski doğuyorsa,
• tüm katılımcılara aynı çekirdek soruları sormak analiz için önemliyse,
• kısa ve hızlı bir anket hedefleniyorsa.

Bazı durumlarda skip logic yerine şu seçenek daha iyi olabilir:

Uygun değil
Bilmiyorum
Yanıtlamak istemiyorum
Bu deneyimi yaşamadım

Bu seçenekler katılımcıya dürüst bir çıkış verir ve veri analizinde görünür kalır.

Özellikle küçük örneklemli araştırmalarda çok fazla branching alt grupları anlamsız derecede küçültebilir.

Hassas sorularda logic etik riski tamamen çözmez

Logic, hassas soruları yalnızca ilgili katılımcılara göstermek için kullanılabilir. Bu iyi bir pratiktir. Ancak etik riski tamamen ortadan kaldırmaz.

Dikkat edilmesi gerekenler:

• gatekeeper soru açık ve güvenli yazılmalı,
• katılımcı istemeden hassas bloğa yönlendirilmemeli,
• “yanıtlamak istemiyorum” seçeneği düşünülmeli,
• consent ve bilgilendirme logic’ten önce gelmeli,
• hassas bloklarda zorunlu açık uçlu sorular dikkatli kullanılmalı,
• küçük alt gruplarda tanınabilirlik riski değerlendirilmelidir.

Hassas konularda “soruyu gizledim, etik sorun çözüldü” yaklaşımı yeterli değildir. Logic, etik tasarımın yalnızca bir parçasıdır.

Versiyon değişiklikleri ve raporlama

Büyük araştırmalarda bazen anket yayına çıktıktan sonra flow hatası fark edilir ve yeni versiyon yayınlanır.

Bu durumda eski ve yeni versiyon verileri dikkatle ele alınmalıdır.

Önemli noktalar:

PublicOp geçmiş verileri yeni flow’a göre otomatik metodolojik olarak düzeltmez.
Eski versiyonda yanlış kişilere açılan sorular varsa bu not edilmelidir.
Görmesi gereken kişilere açılmayan sorular varsa veri kaybı değerlendirilmelidir.
Versiyonlar arasında karşılaştırma yapılırken flow farkı açıklanmalıdır.

Eski versiyon verisi her zaman tamamen çöpe atılmak zorunda değildir. Ama sınırlı, açıklamalı ve temkinli kullanılmalıdır.

Bazı durumlarda güvenli raporlama dili şudur:

Bu soruya yanıt veren katılımcılar arasında...

Daha iddialı ifade ise riskli olabilir:

Bu koşulu sağlayan tüm katılımcılar arasında...

Eğer flow değişmişse rapora metodolojik not eklemek gerekir.

PublicOp’un rolü nedir?

PublicOp’u “logic’i otomatik düşünen sistem” gibi anlatmak yanlış olur.

Daha doğru konumlandırma şudur:

PublicOp, araştırmacının kurduğu koşullu akışı uygulayan profesyonel bir Research Operations aracıdır.

PublicOp:

• Advanced Polls içinde Branching / Skip Logic destekler,
• Rule Builder ile IF / THEN kuralları kurulmasını sağlar,
• Question ID ve Option ID yapısıyla logic’i metinden bağımsız yürütür,
• Section bazlı yönlendirmeyi destekler,
• End survey ile screen-out akışları kurulmasına imkân verir,
• çok dilli anketlerde aynı logic yapısını korur,
• Preview / Test mode ile akışların test edilmesini destekler,
• Data Export ile ham veriyi CSV, Excel ve SPSS olarak dışa aktarır,
• Live Report ve Global Filter ile alt grup sonuçlarını izlemeye yardımcı olur,
• single dataset ve LANGUAGE column yapısını korur.

PublicOp şunları yapmaz:

• tüm logic hatalarını otomatik bulmaz,
• unreachable question tespiti yapmaz,
• logic conflict’leri otomatik çözmez,
• araştırmacının akışını kendiliğinden tasarlamaz,
• QuickPoll’da karmaşık branching sunmaz,
• dile göre tamamen farklı akışlar oluşturmaz,
• export’ta seen but unanswered ile not shown due to logic ayrımını otomatik etiketlemez,
• flow validasyon raporunu otomatik üretmez,
• quota sampling veya panel screening yapmaz.

Bu sınırları bilmek, platformu daha doğru kullanmayı sağlar.

Anket akışı tasarlamak için pratik öneriler

1. Önce akış haritasını çizin

Anket editörüne girmeden önce ana yolları yazın:

Kim hangi blokları görecek?
Hangi cevap hangi bölümü açacak?
Hangi cevap anketi sonlandıracak?
Hangi blok herkes tarafından görülecek?

2. Gatekeeper soruları tekilleştirin

Aynı kavramı iki kez trigger olarak sormayın. Bir ana gatekeeper soru belirleyin ve ilgili tüm blokları ona bağlayın.

3. Section yapısını temiz kurun

Aynı deneyime ait soruları aynı section içinde gruplayın. Farklı gruplara ait soruları aynı bölümde karıştırmayın.

4. Single choice kullanmayı tercih edin

Kritik flow sorularında Single choice, multiple choice’a göre daha güvenlidir. Multiple choice logic daha çok test gerektirir.

5. “İkisi de” gibi seçenekleri özellikle test edin

Bu seçenekler çoğu flow hatasının kaynağıdır. Hem self hem partner veya iki ilgili bloğu açması gerekiyorsa testte mutlaka kontrol edilmelidir.

6. Piping ve logic’i ayrı düşünün

Piping metni kişiselleştirir. Branching akışı değiştirir. Aynı şey değillerdir.

7. Çok dilli versiyonları ayrı ayrı test edin

Logic ID bazlı çalışsa bile çeviri anlamı bozulmuş olabilir. Her dilde ana gatekeeper soruların anlamı kontrol edilmelidir.

8. Yayın sonrası veri kontrolü yapın

İlk veri geldikten sonra export alıp mantıksal çapraz kontrol yapın. Özellikle büyük araştırmalarda bu adım atlanmamalıdır.

Sonuç

Anket akışı tasarımı, araştırma kalitesinin en kritik ama en kolay gözden kaçan parçalarından biridir.

İyi flow:

• doğru katılımcıya doğru soruyu gösterir,
• gereksiz soruları gizler,
• survey fatigue’i azaltır,
• hassas soruları daha dikkatli yönetir,
• veri kalitesini artırır,
• raporlamayı güçlendirir.

Kötü flow:

• yanlış kişilere soru gösterir,
• doğru kişilere kritik soruları göstermeyebilir,
• missing data üretir,
• alt grupları yanlış böler,
• raporlamayı zayıflatır,
• araştırmanın güvenilirliğini düşürür.

Büyük araştırmalarda anket akış tasarımı teknolojik bir sihir değil, metodolojik bir mimari işidir.

PublicOp Advanced Polls, araştırmacının tasarladığı bu IF / THEN mantığını uygulayan, çok dilli anketlerde Question ID ve Option ID yapısıyla akışı koruyan, Live Report ve Data Export ile kontrolü kolaylaştıran güçlü bir Research Operations aracıdır.

Ama akışı doğru kurmak, test etmek, yayın sonrası doğrulamak ve veriyi temkinli yorumlamak araştırmacının sorumluluğundadır.