စီစဉ်နည်း

လုပ်ငန်းစဉ်

1. Research: provider ၏ ဂိမ်း စာမျက်နှာ၊ rules နှင့် about စာမျက်နှာကို ဖတ်သည်။
2. Evidence: field တစ်ခုစီအတွက် ရင်းမြစ် URL၊ ကိုးကားချက်နှင့် စစ်ဆေးရက် သိမ်းသည်။
3. Structured data: database (games.json) တွင် ထည့်သည်။
4. Validation: provider စာမျက်နှာ ကိုယ်တိုင် ကွဲလွဲမှုနှင့် database အချင်းချင်း ကွဲလွဲမှု စစ်သည်။
5. Draft နှင့် QA: စာသားကို ဒေတာမှ ရေးပြီး ကိန်းဂဏန်းကို ပြန်စစ်သည်။
6. Publish: QA အောင်မှ index ပြုသည်။

Field အလိုက် ယုံကြည်မှု အဆင့်

• A provider တရားဝင် စာမျက်နှာတွင် တိုက်ရိုက် ဖော်ပြ
• B သီးခြား database 2 ခု+ ကိုက်ညီ
• C database 1 ခုသာ (ပြန်စစ်ရန်)
• ! provider ရင်းမြစ် ကိုယ်တိုင် ကွဲလွဲ
• ? ရင်းမြစ် မတွေ့သေး

ကွဲလွဲမှု ကိုင်တွယ်ပုံ

JILI ဂိမ်းဟောင်း အချို့၏ Publish Time သည် ဂိမ်းကို ပြန်တင်သည့် လ ဖြစ်ပြီး ပထမဆုံး ထုတ်ဝေရက်နှင့် မကိုက်ညီနိုင်သဖြင့် "!" ပြပြီး Slot အသစ် စာရင်းမှ ဖယ်သည်။ database အချင်းချင်း RTP မတူလျှင် တန်ဖိုး နှစ်ခုစလုံးကို ရင်းမြစ်နှင့်အတူ မှတ်ပြီး provider အတည်ပြုချက် မရမချင်း C အဆင့်ဖြင့်သာ ပြသည်။

Ranking စည်းမျဉ်း

• ranking တစ်ခု = field တစ်ခု။ ပေါင်းအမှတ် မသုံးပါ။
• A/B/C field များသာ ranking ဝင်သည်။
• တူညီလျှင် ဒုတိယ စည်းမျဉ်း (ဥပမာ volatility၊ အမည်) ကို စာမျက်နှာတွင် ဖော်ပြသည်။

တွက်ချက် ဒေတာ (derived data)

provider median၊ percentile၊ ကျပ်ငွေ ပြောင်းလဲမှုတို့သည် MMK77 database မှ တွက်ချက်ခြင်း ဖြစ်ပြီး provider ကြေညာချက် မဟုတ်ပါ။ median = တန်ဖိုးများကို စီပြီး အလယ် တန်ဖိုး၊ percentile = provider ဂိမ်းများအနက် ဤတန်ဖိုးထက် နိမ့်သော ရာခိုင်နှုန်း။

ပြင်ဆင်ခြင်း

ဂိမ်း အသစ်နှင့် B/C field များကို ဦးစားပေး ပြန်စစ်သည်။ စာမျက်နှာ အကြောင်းအရာ အမှန်တကယ် ပြောင်းမှသာ ပြင်ဆင်ရက် ပြောင်းသည်။