Tindakan pengguna sekali sehari: Reset 24 Jam vs. Reset Tengah Malam [ditutup]

Ketika seorang pengguna dapat melakukan tindakan hanya sekali sehari, misalnya mendapatkan tiket gratis untuk kompetisi, ada dua kemungkinan yang saya temui dalam pengalaman saya.

1) 24 Jam Atur Ulang

Jika dia melakukan tindakan pada hari 1 pada 11:45, dia hanya dapat melakukan tindakan lagi pada hari 2 pada atau setelah 11:45. Dia tidak akan mampu melakukannya 11:44 pada hari ke 2.

2) Atur Ulang Tengah Malam (atau waktu tetap apa pun)

Tidak peduli berapa lama pengguna melakukan tindakan pada hari 1, segera setelah itu berubah tengah malam dan hari 2 dimulai, ia akan dapat melakukannya lagi.

Keduanya membatasi pengguna dalam melakukan hanya satu tindakan sehari, tetapi saya paling sering menemukan metode 1, yang menurut saya cukup merepotkan karena dua alasan:

• Pertama saya harus menunggu waktu
• dan yang kedua dalam periode waktu yang lama, cap waktu saya yang melakukan tindakan akan menjadi lambat dan lambat, karena saya tidak akan dapat melakukan tindakan tepat di stempel waktu itu setiap hari, hanya beberapa detik atau menit kemudian.

Apakah ada alasan teknis , bahwa orang akan lebih suka metode 1, meskipun menurut saya kerugian penting bagi pengguna yang dinyatakan sebelumnya?

Edit, untuk menentukan: Saya terutama berbicara tentang contoh, di mana timegap sebenarnya 24 jam jelas tidak diperlukan, seperti dalam acara putaran bebas saat ini dari Theory11 , di mana Anda mendapatkan 1 putaran gratis setiap 24 jam untuk mendapatkan kesempatan untuk memenangkan hadiah.

Saya terkejut karena biasanya saya mengharapkan reset tengah malam.

Namun, itu datang dengan kerugian besar, yaitu ada lebih dari satu tengah malam setiap 24 jam. Anda harus memilih zona waktu Anda.

Mungkin ini sebabnya universal sekali per 24 jam dipilih, Anda dapat membayangkan perusahaan mungkin tidak ingin menerima bahwa pengguna setengah di negara yang berbeda mungkin memiliki waktu akhir lokal non tengah malam, atau lebih daripada mereka mungkin menganggap mengatakan "per hari" tersirat tengah malam dan dengan demikian mereka mengubah pemasaran menjadi "per 24 jam" dan spesifikasi perangkat lunak untuk mencocokkan

Meskipun saya pikir ini cukup umum untuk melihat "berakhir pada 14:00 GMT" atau serupa hari ini.

Saya akan berpikir tantangan menyimpan tanggal tindakan terakhir untuk setiap pengguna akan lebih sulit daripada menetapkan zona waktu untuk pengguna atau jenis tindakan.

Sunting Saya pikir perlu dicatat perbedaan antara kedua metode

Aturan 24 jam

• Saya akan mendapatkan aliran acara yang konstan, tarif dibatasi hingga kurang dari 1 per 24 jam.
• Ketika saya mengakhiri hal itu, beberapa pengguna akan mendapatkan lebih sedikit acara.
• Saya perlu menyimpan setiap acara terakhir pengguna
• Ketika penghematan siang hari menyebabkan hari yang panjang atau pendek, saya tidak akan memiliki 1 acara per hari
• Manusia tidak dapat mencapai tepat 24 jam pada titik, jadi saya akan mendapatkan rata-rata kurang dari 1 per hari

Aturan 1 per hari kalender

• Saya mendapatkan acara dengan periode lebih dari 50 jam (? UTC + 14 hingga -12?) Yang ditetapkan untuk hari kalender
• secara realistis saya masih harus menyimpan setiap acara terakhir pengguna sebagai 'hari' selama putaran
• Saya memiliki akhir yang pasti di mana saya bisa mengatakan bahwa semua kejadian setelah sekarang bukan di hari itu.
• Saya perlu tahu lokasi pengguna untuk mengetahui hari apa acara mereka berlaku
• Beberapa orang bangun jauh lebih awal di 'hari' daripada yang lain

1 per hari kalender dalam aturan UTC

• Saya mendapatkan seragam yang bagus selama 24 jam
• Saya dapat mengemas acara saya
• Saya tahu kapan awal dan akhir hari adalah
• Tabungan siang hari akan membingungkan orang.
• Manusia dapat memiliki 1 acara per hari
• Manusia yang tidak tinggal di dekat Greenwich akan memiliki awal dan akhir yang lucu
• Mungkin saya bisa melakukan optimasi pintar dan hanya menyimpan daftar pengguna yang telah masuk? (mungkin saya akan berakhir menyimpan setiap acara dan waktu pengguna)

* Memberi acara akan sangat berguna untuk berbagai tujuan pelaporan. misalnya. mengatakan saya memiliki 10 hadiah yang harus dimenangkan setiap periode 24 jam dan mereka berbeda dari waktu ke waktu. Berapa banyak siswa yang masuk pada hari ke 10? dll

Dari atas kepala saya:

• Mungkin lebih mudah untuk mengimplementasikan versi "24 jam sejak aksi terakhir"
• Jika pengguna tidak melakukan tindakan tepat 24 jam setelah terakhir kali, maka pada akhirnya mereka mungkin kehilangan periode 24 jam penuh karena reset harus terjadi ketika mereka tidur, atau bekerja. Mungkin mereka melakukannya jam 7 pagi sebelum berangkat kerja, dan berangkat kerja jam 8 malam. Hari berikutnya mereka melakukannya pada jam 7:15, jam 7:30, jam 7:45, dan pada hari terakhir tinggal sampai jam 8:00 untuk melakukan aksi sesaat sebelum pergi. Hari berikutnya mereka tidak mau tinggal sampai jam 8:15, jadi lewatkan saja pagi itu dan lakukan setelah pulang dari kerja pukul 6 sore, selisih 34 jam. Jika hasil dari tindakan itu mahal bagi perusahaan, tabungan mungkin lebih penting daripada ketidaknyamanan.

Seperti jawaban lain yang disebutkan, metode 24 jam lebih ramah ke beberapa zona waktu, dan mudah untuk kode, karena Anda hanya menyimpan cap waktu terakhir yang berhasil untuk setiap pengguna.

Ini juga memiliki "manfaat" tambahan yang sebenarnya mengharuskan pengguna untuk berinteraksi dengan aplikasi setiap hari untuk mendapatkan semua tindakan harian. Jika ada yang mengatakan reset tengah malam, maka pengguna dapat melakukan tindakan pada pukul 11:59 malam, dan kemudian lagi pada pukul 12:00 pagi. Mereka bisa melakukan ini setiap hari dan masih mendapatkan semua tindakan. Untuk beberapa aplikasi tujuan tindakan harian adalah untuk membuat pengguna berinteraksi dengan aplikasi setiap hari sehingga ini kurang ideal.

Ada alternatif ketiga yang menghindari perangkap UI dari keduanya, tetapi agak sulit untuk dikodekan.

3) Tidak ada garis lebih dari n tindakan dalam (n-0,75) * 24 jam

Itu memang membutuhkan dua variabel untuk disimpan, tetapi memungkinkan seseorang yang tidak mencoba menyalahgunakan sistem untuk menggunakan satu tindakan mereka kapan saja sepanjang hari tanpa harus khawatir tentang zona waktu dan pengaturan ulang.

Itu juga mencegah siapa pun menggunakan lebih dari 1 tindakan "ekstra".

Jadi sebenarnya implementasikan algoritma yang Anda perlukan untuk menyimpan waktu mulai beruntun, waktu bermain terakhir, dan jumlah tindakan dalam beruntun Anda.

Melacak waktu tindakan terakhir memungkinkan Anda untuk menolak dua tindakan yang terlalu berdekatan. Anda dapat membuat batas ini kurang dari 24 jam karena garis goresan mencegah merayap di awal hari.

Coretan terus terjadi selama Anda melakukan tindakan setiap hari. Jika mengambil tindakan berarti Anda akan memiliki lebih banyak tindakan dalam beberapa hari berturut-turut maka ditolak. Ini mencegah perlahan-lahan merayap maju, mengepak dalam tindakan "ekstra" karena waktu mulai beruntun Anda tidak berubah.

beberapa kode semu untuk mengimplementasikan pemeriksaan dan melacak waktu:

//precondition: streakStart and  lastAction are initialized as in the far past
//              streakCount is initialized as 0
graceHours=18;
checkAllowed(currentTime,&streakStart,&streakCount, &lastAction){
    diffhours=hoursDifferent(lastAction,currentTime);
    if(diffhours< 24 - graceHours){
        return false;
    }
    diffhours=hoursDifferent(streakStart,currentTime);
    if(diffhours <= 24*streakCount - graceHours){
        return false;
    }
    if(diffhours > 24*(streakCount+2)-graceHours){
        streakStart=currentTime;
        streakCount=0;
    }
    streakCount++;
    lastActionTime=currentTime;
    return true;
}

Sebagai bonus tambahan, Anda mendapatkan penghitung beruntun, jika Anda menginginkannya.

Tentang masalah Anda dengan durasi 24 jam antara tindakan, beberapa perusahaan malah menggunakan durasi 22 jam, dengan cara ini pengguna mendapatkan sedikit kelonggaran pada saat yang tepat dari hari di mana tindakan diperlukan dan masih bisa mendorong pengguna untuk benar-benar melakukan tindakan sekali per hari -tidak 23:59 - 00:00 celah.

Bukan jawaban tetapi saya tidak punya cukup poin untuk berkomentar.

tl/dr: 24 hour resets are the lazy man's way of minimizing load spikes

Selain jawaban di atas, reset tengah malam mendorong lonjakan lalu lintas. Jika aksi tersedia untuk semua peserta pada waktu tertentu, maka akan ada insentif bagi banyak orang untuk mencoba aksi pada waktu yang sama. Ini adalah alasan yang sama mengapa sebagian besar negara bagian memiliki SIM Anda berakhir pada hari ulang tahun Anda dan bukan pada tanggal yang tetap (AS): DMV tidak akan dapat mengikuti jika semua orang memiliki SIM mereka berakhir pada tanggal 1 Januari.

Small Aside : jika sistem komputer perlu mengambil tindakan sekali sehari untuk sejumlah besar pengguna, Anda dapat mengajukan pertanyaan yang sama, dan saya biasanya mendesainnya sebagai kombinasi keduanya. Anda bisa membayangkan dua tugas cron:

1. Jalankan pada tengah malam, temukan semua catatan, ambil tindakan
2. Jalankan setiap menit (atau frekuensi reguler), temukan semua catatan yang belum mengambil tindakan sejak 00:00 kemarin, ambil tindakan, rekam tindakan yang diambil

Dalam praktiknya saya menemukan yang pertama rapuh. Jika tugas cron rusak saat berjalan maka beberapa nomor mungkin tidak memiliki tindakan diterapkan, dan pekerjaan tambahan mungkin diperlukan untuk sistem untuk mengingat di mana itu dan mengambil di mana ia tinggalkan. Ini juga dapat menyebabkan masalah jika Anda mendapatkan catatan yang cukup sehingga tugas cron Anda tidak dapat memproses semuanya dalam batas waktu yang wajar, dan itu akan dimatikan sebelum selesai.

Yang terakhir menangani kedua masalah tersebut. Itu tidak bertujuan untuk membuat semuanya diproses tepat 24 jam terpisah, tetapi selama tugas cron Anda dapat dengan mudah menjalankan semua tindakan setiap hari, mereka akan sangat dekat dan Anda akan menjamin bahwa semua orang akan dijalankan pada setiap hari yang sebenarnya (yaitu Anda tidak akan memiliki hal-hal yang perlahan-lahan terpisah lebih dari 24 jam). Namun yang paling penting, ia akan dengan mudah menemukan di mana ia tinggalkan jika beberapa hal rusak karena suatu alasan.

https://www.youtube.com/watch?v=hoMO1yYC7pQ

Tiket bus / kereta harian di TfL (Transport for London) berlaku mulai pukul 4:30 pagi hingga 4:30 pagi. Lakukan pergantian ketika orang tertidur. Banyak orang akan ingin menggunakan layanan katakan dari 8:30 hingga satu jam lewat tengah malam

Reset tengah malam memiliki kondisi tertentu yang dapat diinginkan atau merugikan, tergantung pada masalah apa yang Anda coba selesaikan dan itu adalah: Saya dapat melakukan tindakan satu hari di 11:59:58 dan sekali lagi pada pukul 00:00:01. Jika ruang masalahnya adalah kompetisi apa pun, ini bisa memberikan keuntungan yang tidak adil bagi orang yang memilih untuk melakukan tindakan mereka hampir tengah malam. Aturan reset 24 jam adalah satu-satunya cara untuk memastikan distribusi yang adil dari tindakan yang tersedia terlepas dari jam berapa seseorang telah tersedia untuk mereka.

Konsekuensi dari reset 24 jam menjadi nanti dan kemudian dapat dikurangi dengan memberikan toleransi, misalnya menerima permintaan tindakan dalam waktu 15 menit dari reset terjadi selama tindakan tersebut tidak benar-benar direkam (atau tidak mengambil efek) hingga reset terjadi. Ini memperkenalkan sedikit lebih banyak kerumitan ke dalam solusi, tetapi saya tidak bisa memikirkan strategi mitigasi apa pun untuk dapat mengambil dua tindakan setiap hari terpisah seperti dalam kasus reset tengah malam.

Saya belum pernah melihat orang menyebutkan fakta bahwa aturan 24 jam mendorong kunjungan rutin rutin. Banyak game memiliki hadiah login / kemenangan sekali sehari yang di-reset setelah 24 jam karena mereka lebih suka Anda check-in untuk waktu yang singkat setiap 24 jam daripada selama dua kali lebih lama setiap 48 jam. Saya membayangkan itu serupa untuk situs web yang menerima hadiah tiket.