រំកិលទៅមាតិកា

ស្វែងយល់អំពី Analytics របស់ Command Center

ការរៀបចំរហ័ស

សណ្ឋាគារភាគច្រើនពិនិត្យ Completion Rate, Biggest Drop‑Off, និង Issues ក្នុងរយៈពេលក្រោម 3 នាទី។

មគ្គុទ្ទេសក៍នេះពន្យល់ពីរបៀបដែល AVA គណនាតារាង Analytics នីមួយៗនៅក្នុង Command Center។ វាក៏ពន្យល់អំពីកាត coverage check-in និង check-out បន្ថែម ព្រមទាំងការនាំចេញ STB EVA ផងដែរ។

ទៅកាន់: Main Menu → Command Center → Analytics

ផ្ទុក Analytics លឿនជាងមុន

AVA ឥឡូវអានផ្ទាំងនេះពី daily rollups ដើម្បីឱ្យ date range ធំៗផ្ទុកបានលឿនជាងមុន។ View Check-In ដែលត្រងតាម mode ប្រើ CCI និង ACI rollup slices ដាច់ដោយឡែក។ ថ្ងៃដែលបានរក្សាទុកឡើងវិញ ប្រើព័ត៌មានលម្អិត event ដែលត្រូវការសម្រាប់ការគណនា dashboard ដដែល។ ថ្ងៃនេះប្រើទិន្នន័យ live ជានិច្ច ដូច្នេះសកម្មភាពថ្មីៗនៅតែទាន់សម័យ។ បើទិន្នន័យដែលបានរក្សាទុកបាត់ មិនត្រូវគ្នា ឬមិនអាចប្រើបាន AVA នឹងត្រឡប់ទៅប្រើ live data វិញ។ View ដែលមិនបានត្រងអាចប្រើ rollup ដែលមានស្រាប់ ទោះគ្មាន mode slices ក៏ដោយ។ AVA ធ្វើ refresh daily rollups ដែលមិនពេញលេញ ឬហួសសម័យដោយស្វ័យប្រវត្តិនៅផ្ទៃខាងក្រោយ។ បន្ទាប់ពីធ្វើបច្ចុប្បន្នភាព Analytics កាលបរិច្ឆេទចាស់ៗអាចផ្ទុកយឺតជាងមុន ខណៈពេល refresh នេះបញ្ចប់។ អ្នកមិនចាំបាច់រត់ manual backfill ទេ។

ពេលផ្ទុកយូរសម្រាប់ date range ធំ

ចន្លោះកាលបរិច្ឆេទធំៗនៅតែអាចចំណាយពេលផ្ទុកយូរ។ អចលនទ្រព្យដែលរវល់ខ្លាំងអាចត្រឡប់ error ទាមទារ date range តូចជាងមុន លឿនជាងការជាប់។ នេះអនុវត្តតែលើ tab Analytics ប៉ុណ្ណោះ។ សំណើ Analytics ត្រូវបានកំណត់ត្រឹម 20,000 sessions។ បើចន្លោះរបស់អ្នកលើសកំណត់នេះ សូមបង្រួមកាលបរិច្ឆេទ ហើយសាកល្បងម្ដងទៀត។ AVA នឹងបដិសេធសំណើ ជំនួសឱ្យកាត់របាយការណ៍ ឬផ្ទុកទិន្នន័យដដែលតាមផ្លូវផ្សេងទៀត។

ចន្លោះកាលបរិច្ឆេទពេញមួយត្រីមាស

ចន្លោះ date-only គាំទ្ររហូតដល់ 92 ថ្ងៃប្រតិទិនជាប់គ្នា។ វារួមបញ្ចូលត្រីមាសពេញ ដូចជា July 1–September 30។ AVA ផ្ទៀងផ្ទាត់ថ្ងៃប្រតិទិនតាមម៉ោងមូលដ្ឋានរបស់សណ្ឋាគារ ដូច្នេះការផ្លាស់ប្តូរ daylight-saving មិនបន្ថយកំណត់នេះទេ។

សម័យសាកល្បង

ការចូលតេស្តនៅតែបង្ហាញក្នុង Status និង reservation details។ វាមិនរាប់ក្នុង Analytics totals, drop-offs, time analysis, issues ឬ recent activity ទេ។

ការទាញយករបាយការណ៍

ប្រើ Download report ដើម្បីរក្សាទុក view Analytics បច្ចុប្បន្នជា PDF។ AVA បង្រួម report PDF ដោយមិនបន្ថយគុណភាពការចាប់យក ដូច្នេះឯកសារទាញយកមានទំហំតូចជាងមុន។ ការទាញយកទូទៅមាន overall ក្នុងឈ្មោះឯកសារ។ បញ្ជី reservation របស់ funnel មានសកម្មភាព Download CSV សម្រាប់ reservation ដែលបង្ហាញ។ ពេលផ្ទាំង STB EVA submissions បង្ហាញ អ្នកអាចប្រើរូបតំណាងទាញយករបស់វា ដើម្បីនាំចេញជា CSV។ ការនាំចេញនោះប្រើប្រភពកំណត់ហេតុ EVA submission ដូចគ្នានឹងចំនួននៅលើ dashboard។

ចម្លង MCP config សម្រាប់ Codex ឬ Claude​

ការរៀបចំរហ័ស

វាចំណាយពេលក្រោម 1 នាទី។ token នេះមានអាយុកាលខ្លី ហើយប្រើ browser session បច្ចុប្បន្នរបស់អ្នក។

ប្រើប៊ូតុងទាំងនេះ នៅពេលអ្នកចង់ផ្ញើទិន្នន័យ Analytics ទៅកាន់ AI client មួយ។ សញ្ញាសម្គាល់ token ដែលបានចម្លងក៏រួមបញ្ចូលវិសាលភាព Streamliner MCP ពេញលេញផងដែរ។ អតិថិជនដែលគាំទ្រអាចប្រើ settings tools បន្ទាប់ពីអ្នកចាប់ផ្តើមវាឡើងវិញ។ បន្ទាប់ពីអ្នកចម្លង AVA នឹងបង្ហាញបង្អួច modal ជាក់លាក់តាម client ជាមួយនឹងសេចក្តីណែនាំសម្រាប់បិទភ្ជាប់។

ប៊ូតុងអ្វីដែលវាចម្លងសមស្របសម្រាប់
Copy Codex MCP Configការកំណត់ MCP ជាទម្រង់ TOML ជាមួយ mcp_servers.streamlinerCodex
Copy Claude MCP Configការកំណត់ MCP ជាទម្រង់ JSON ជាមួយ mcpServers.streamlinerClaude Code ឬ Claude Desktop

  1. ទៅកាន់ Main Menu → Command Center → Analytics។

  2. ចុច Copy Codex MCP Config ឬ Copy Claude MCP Config។

  3. រង់ចាំរហូតដល់ប៊ូតុងប្តូរទៅជា Creating MCP token...។

  4. អានសេចក្តីណែនាំក្នុង modal សម្រាប់ client របស់អ្នក។

  5. បិទភ្ជាប់ config ដែលបានចម្លងទៅក្នុងឯកសារ config របស់ AI client របស់អ្នក។

  6. ចាប់ផ្តើម client របស់អ្នកឡើងវិញ ដើម្បីឱ្យវាផ្ទុក MCP server ថ្មី។

    ✓ Claude config ប្រើ JSON។ ✓ Codex config ប្រើ TOML។ ✓ config ទាំងពីររួមបញ្ចូល STREAMLINER_MCP_TOKEN ដែលមានអាយុកាលខ្លី។

ប្រើ token ថ្មីតែប៉ុណ្ណោះ

បើអ្នកបានចម្លង token មុនការផ្លាស់ប្តូរនេះ សូមចម្លង config ថ្មីម្តងទៀត។ token ចាស់ៗនឹងរក្សាវិសាលភាពមុនរបស់វា រហូតដល់អ្នកបង្កើត token ថ្មី។

កន្លែងបិទភ្ជាប់ config នីមួយៗ

Codex ប្រើ ~/.codex/config.toml។

Claude ប្រើ Claude Desktop Developer config ដែលជាទូទៅគឺ claude_desktop_config.json។

អ្វីដែល modal បង្ហាញ​

បង្អួច modal បញ្ជាក់ថាអ្នកបានចម្លង config ដោយជោគជ័យ។ បន្ទាប់មកវាបង្ហាញ file path ទីតាំងបិទភ្ជាប់ និងជំហានចាប់ផ្តើមឡើងវិញសម្រាប់ client នោះ។

បើអ្នកកំពុងប្រើ Codex

  1. បើក ~/.codex/config.toml នៅលើម៉ាស៊ីនដែលអ្នកដំណើរការ Codex។

  2. បិទភ្ជាប់ TOML block ដែលបានចម្លងនៅកម្រិត top-level នៃឯកសារ។

  3. រក្សាទុកឯកសារ បន្ទាប់មកចាប់ផ្តើម Codex ឡើងវិញ។

    ✓ បើ mcp_servers.streamliner មានរួចហើយ សូមជំនួស section នោះ។

បើអ្នកកំពុងប្រើ Claude Desktop

  1. បើក Claude Desktop។

  2. ទៅកាន់ Settings → Developer → Edit Config។

  3. បិទភ្ជាប់ JSON ដែលបានចម្លងទៅក្នុង claude_desktop_config.json។

  4. រក្សាទុកឯកសារ បន្ទាប់មក quit ហើយបើក Claude Desktop ឡើងវិញទាំងស្រុង។

    ✓ លើ macOS ឯកសារនេះជាទូទៅស្ថិតក្រោម ~/Library/Application Support/Claude/។ ✓ បើ mcpServers មានរួចហើយ សូម merge តែ entry streamliner ប៉ុណ្ណោះ។

សេចក្តីយោងរហ័ស​

ទិដ្ឋភាពអ្វីដែលរាប់ជាសម័យច្បាប់បញ្ចប់
Pre‑Arrivalការកក់ណាមួយដែលមានសកម្មភាព Pre‑Arrival រួមទាំងការបោះបង់ និងដំណើរដែលក្រោយមកបញ្ចប់ check-inPRE_ARRIVAL ជោគជ័យ
Check‑In → Overallការមកដល់ពី PMS ដែលមានសិទ្ធិ រួមទាំង reservation ដែលមិនធ្លាប់ប្រើ AVAចំនួន reservation ពី PMS និង AVA coverage
Check‑In → CCI + ACIសហភាពនៃដំណើរដែលបានកំណត់ថាជា CCI ឬ ACI រួមទាំងការប៉ុនប៉ងមិនទាន់ពេញលេញ និង KEY_ENCODEDPMS CHECKIN ដែលជោគជ័យ
Check‑In → Early Check‑InEARLY_CHECKIN_ATTEMPT ឬ ROOM_ASSIGNMENT_QUEUEDEARLY_CHECKIN_ATTEMPT ឬ ROOM_ASSIGNMENT_QUEUED ជោគជ័យ
Check‑In → Pre‑Registrationការកក់ណាមួយដែលមានជំហាន Pre‑RegistrationPRE_REGISTRATION ជោគជ័យ
Check‑In → Full Check‑InCHECKIN, KEY_COLLECTION, GET_DOOR_LOCK_KEY, ឬ KEY_ENCODEDPMS CHECKIN ដែលជោគជ័យ
Check‑Outការកក់ណាមួយដែលមានជំហាន checkoutCHECKOUT ឬ COMPLETED_CHECKOUT_PAYMENT ជោគជ័យ

បើក Analytics ហើយជ្រើស view​

Check-In/Out Analytics Dashboard

  1. ទៅកាន់ Main Menu → Command Center។

  2. ជ្រើស tab Analytics។

  3. ជ្រើស Pre‑Arrival, Check‑In, ឬ Check‑Out។

  4. បើអ្នកជ្រើស Check‑In សូមប្រើ sub-tabs: All Check‑Ins, Early Check‑In, Pre‑Registration, ឬ Full Check‑In។

  5. នៅក្រោម Report view ជ្រើស Overall, CCI + ACI, Self Check-In (CCI) ឬ Assisted Check-In (ACI)។

    ✓ តារាងទាំងអស់នឹងអាប់ដេតទៅតាម view និង date range នោះ។

ត្រង check-in តាម mode​

ប្រើ Report view នៅខាងក្រោម flow tabs ដើម្បីជ្រើសក្រុម reservation ឬ mode check-in។ តម្រងនេះបង្ហាញតែនៅពេលអ្នកជ្រើស Check-In ប៉ុណ្ណោះ។

តម្រងអ្វីដែលវារួមបញ្ចូល
Overallការមកដល់ពី PMS ដែលមានសិទ្ធិ រួមទាំង reservation ដែលមិនធ្លាប់ប្រើ AVA; មិនរាប់ reservation ដែលបានលុប និងមិនមក
CCI + ACIដំណើរដែលបានកំណត់ថាជា CCI ឬ ACI; មិនរាប់ការបញ្ចប់ដែលមានតែ pre-arrival និងមិនស្គាល់ mode
Self Check-In (CCI)check-in ដែលបានកំណត់ថាមកពី self-service CCI flow
Assisted Check-In (ACI)check-in ដែលបានកំណត់ថាមកពី staff-assisted ACI flow

  1. ជ្រើស Check-In ក្នុង Command Center → Analytics។

  2. ជ្រើស Overall, CCI + ACI, Self Check-In (CCI) ឬ Assisted Check-In (ACI)។

  3. ពិនិត្យ cards, funnel, timing, issues និង device results ដែលបានអាប់ដេត។

    ✓ mode ដែលបានជ្រើសនឹងនៅសកម្ម ខណៈពេលអ្នកប្តូរ date range ឬ check-in sub-tab។

AVA កំណត់ដំណើរតាម mode ដែលបានកត់ត្រាក្នុង event CHECKIN ដែលជោគជ័យរបស់វា។ សម្រាប់ដំណើរដែលមិនទាន់ពេញលេញ AVA ប្រើ mode check-in ចុងក្រោយដែលបានបញ្ជាក់ច្បាស់។ បើដំណើរមួយប្រើ mode ទាំងពីរ event CHECKIN ដែលជោគជ័យមានអាទិភាព។ CCI + ACI ជាក់លាក់ គឺជាសហភាពនៃដំណើរដែលបានកំណត់ថាជា CCI និង ACI។ ការបញ្ចប់ដែលមិនស្គាល់ mode មិនបង្ហាញក្នុង CCI + ACI ជាក់លាក់ទេ។ View Overall អាចរួមមានសកម្មភាព check-in ដែលមិនបានចាត់ថ្នាក់។ នេះធ្វើឱ្យចំនួនដែលបានត្រង ភ្ជាប់ជាមួយ mode ដែល AVA បានកត់ត្រាពិតប្រាកដ។

Pre‑Arrival និង Check‑Out នៅតែជាទិដ្ឋភាពរួម។ វាមិនប្រើតម្រង Check-In mode ទេ។ CCI + ACI ជាក់លាក់គួរតែស្របនឹងផលបូកនៃដំណើរ CCI និង ACI។ លទ្ធផល Overall អាចខុសគ្នា ព្រោះវារួមមានការមកដល់ពី PMS និងសកម្មភាពដែលមិនបានចាត់ថ្នាក់។ ដំណើរដែលមាន mode ចម្រុះត្រូវបានរាប់តែម្តង តាម mode ដែលបានកំណត់ឱ្យវា។

សម្រាប់របាយការណ៍ការប្រើប្រាស់ សូមប្រើ Check-in Result → Successful Check-Ins។ ចំនួន Completed របស់ funnel វាស់ conversion របស់ដំណើរជំនួសវិញ។ ចំនួនទាំងនេះអាចខុសគ្នា ទោះបីអ្នកប្រើ mode និង date range ដូចគ្នាក៏ដោយ។

Analytics ដែលបានត្រង

លទ្ធផលដែលត្រងតាម mode ប្រើ timeline របស់ event ដែលបានកត់ត្រាសម្រាប់បង្អួចកាលបរិច្ឆេទដែលបានជ្រើស។ នៅពេល mode rollup slices មាន សំណើ date range វែងៗផ្ទុកពី slices ទាំងនោះជាមុន។ កាលបរិច្ឆេទចាស់ៗអាចផ្ទុកយឺតជាងមុន រហូតដល់ daily rollups ត្រូវបាន refresh។ View ដែលត្រងតាម mode មិនបង្ហាញតួលេខ coverage របស់ reservation PMS រួមបញ្ចូលទេ។

ពិនិត្យចំនួន reservation ពី PMS ក្នុង Overall​

ជ្រើស Overall នៅពេលអ្នកត្រូវការក្រុម reservation ដែលកំពុងមកដល់ពេញលេញ សម្រាប់ KPI ការប្រើប្រាស់។ View នេះប្រើ arrival dates ពី PMS ជំនួសឱ្យប្រើតែកាលបរិច្ឆេទសកម្មភាព AVA ប៉ុណ្ណោះ។

អ្វីដែលអ្នកត្រូវការជ្រើសអ្វីដែលត្រូវរំពឹង
ការមកដល់ដែលមានសិទ្ធិសរុបOverallរួមបញ្ចូល reservation ដែលមិនធ្លាប់ប្រើ AVA
ការប្រើ AVA តាម flow ដែលបានកំណត់CCI + ACIរួមបញ្ចូលតែដំណើរដែលបានកំណត់ថា CCI និង ACI
ការប្រើ self-serviceSelf Check-In (CCI)រួមបញ្ចូលដំណើរដែលបានកំណត់ថា CCI
ការប្រើដោយបុគ្គលិកជួយAssisted Check-In (ACI)រួមបញ្ចូលដំណើរដែលបានកំណត់ថា ACI

Overall មិនរាប់ reservation ដែលបានលុប និងមិនមកទេ។ ចំនួន reservation របស់វាប្រើ PMS arrival dates ដែលបានជ្រើស។ metrics សកម្មភាព check-in របស់វាប្រើ activity dates។ View នេះអាចបង្ហាញសកម្មភាពដែលមិនបានចាត់ថ្នាក់ ដោយគ្មាន mode CCI ឬ ACI ដែលបានកត់ត្រា។

ប្រៀបធៀបអ្វីដែលមានមូលដ្ឋានដូចគ្នា

ប្រើ Overall សម្រាប់ចំនួន reservation ពី PMS និង coverage។ ប្រើ CCI + ACI សម្រាប់ការប្រើ AVA ដែលបានកំណត់ប្រភព។ កុំប្រៀបធៀប view ទាំងនេះ ដូចជាវាប្រើភាគបែងដូចគ្នា។

ពិនិត្យ metrics check-in ទូទាំងអចលនទ្រព្យ​

View CCI + ACI ជាក់លាក់រួមមាន metrics ដែលគណនាទូទាំងអចលនទ្រព្យរបស់អ្នក។ Metrics ទាំងនេះមិនត្រូវបានបែងចែករវាង Self Check-In (CCI) និង Assisted Check-In (ACI) ទេ។

Metricអ្វីដែលវារួមបញ្ចូលកន្លែងបង្ហាញ
Payment analyticsសកម្មភាពបង់ប្រាក់សម្រាប់អចលនទ្រព្យ និង date range ដែលបានជ្រើសView CCI + ACI
STB EVA submissionsការប៉ុនប៉ងបញ្ជូន EVA សម្រាប់អចលនទ្រព្យ និង date range ដែលបានជ្រើសView CCI + ACI នៅពេល EVA ត្រូវបានបើក
Lost-key activityសកម្មភាព lost-key សម្រាប់អចលនទ្រព្យ និង date range ដែលបានជ្រើសView CCI + ACI

ជ្រើស CCI + ACI នៅពេលអ្នកត្រូវការ metrics ទូទាំងអចលនទ្រព្យទាំងនេះ។ ជ្រើស Self Check-In (CCI) ឬ Assisted Check-In (ACI) សម្រាប់ផ្នែកដំណើរដែលបានកំណត់ប្រភព។

ហេតុអ្វីចំនួនសរុបអាចខុសគ្នា

Funnel CCI + ACI រាប់ដំណើរដែលបានកំណត់ថាជា CCI ឬ ACI។ ផ្ទាំងទូទាំងអចលនទ្រព្យក៏អាចរួមមានសកម្មភាពក្រៅពីដំណើរដែលបានកំណត់ប្រភពទាំងនេះផងដែរ។ ឧទាហរណ៍ សកម្មភាពបង់ប្រាក់អាចរួមមានការបង់ប្រាក់មុនពេលមកដល់។ ចំនួនទាំងនេះអាចមិនស្របគ្នា ហើយវាជារឿងដែលរំពឹងទុក។

ពិនិត្យរបាយការណ៍សញ្ជាតិភ្ញៀវ​

ផ្នែក Guest Nationality ជាជម្រើស បង្ហាញក្រុមភ្ញៀវដែលបានបញ្ចប់ ដោយបែងចែកតាមសញ្ជាតិ។ វាអាចបង្ហាញក្នុង Analytics ផ្ទាល់ និងក្នុងលទ្ធផល Analytics ដែលមានការគាំទ្រដោយ rollup។

លំហូរភ្ញៀវដែលរួមបញ្ចូលច្បាប់បញ្ចប់
Pre-Arrivalភ្ញៀវដែលបញ្ចប់សកម្មភាព Pre-Arrivalសកម្មភាព PRE_ARRIVAL ដែលជោគជ័យ
Check-Inភ្ញៀវដែលបញ្ចប់ view Check-In ដែលបានជ្រើសសកម្មភាព PMS CHECKIN ដែលជោគជ័យ
Check-Outភ្ញៀវដែលភ្ជាប់នឹង reservation checkout របស់ AVA ដែលបានបញ្ចប់ការបញ្ចប់ checkout របស់ AVA ដែលជោគជ័យ

  1. បើក Main Menu → Command Center → Analytics។

  2. ជ្រើស Pre-Arrival, Check-In, ឬ Check-Out។

  3. ជ្រើស date range តាម timezone មូលដ្ឋានរបស់សណ្ឋាគារ។

  4. ជ្រើស All, Completed, ឬ In Progress នៅពេល filter បង្ហាញ។

  5. ពិនិត្យចំនួន និងភាគរយសញ្ជាតិក្នុង Guest Nationality។

    ✓ ភ្ញៀវដែលសម្គាល់បានម្នាក់ៗ ត្រូវបានរាប់ម្តងក្នុងមួយការស្នាក់នៅ និងមួយលំហូរ។

ត្រងភ្ញៀវដែលបានបញ្ចប់ និងមិនទាន់បញ្ចប់​

ប្រើ filter នៅក្នុង Guest Nationality ដើម្បីប្តូរក្រុមភ្ញៀវ។

Filterអ្វីដែលវាបង្ហាញ
Allភ្ញៀវទាំងក្នុងក្រុមដែលបានបញ្ចប់ និងមិនទាន់បញ្ចប់
Completedភ្ញៀវដែលបានបញ្ចប់លំហូរដែលបានជ្រើស
In Progressភ្ញៀវដែលមានសកម្មភាពលំហូរបានកត់ត្រា ប៉ុន្តែមិនទាន់បញ្ចប់មុនថ្ងៃបញ្ចប់របាយការណ៍

Filter ទាំងនេះអនុវត្តតែលើ Guest Nationality ប៉ុណ្ណោះ។ វារក្សាលំហូរ date range និង view របាយការណ៍ Check-In ដែលបានជ្រើស។ វាមិន reload dashboard Analytics ឬប្តូរកាតផ្សេងទៀតទេ។

នៅពេលមានទិន្នន័យ CCI ដែលមិនទាន់បញ្ចប់ All ត្រូវបានជ្រើសជាលំនាំដើម។ Response ចាស់ៗដែលគ្មានទិន្នន័យមិនទាន់បញ្ចប់ នឹងរក្សាឥរិយាបថបង្ហាញតែអ្នកដែលបានបញ្ចប់។ ក្នុង response ទាំងនោះ Completed នៅតែជាក្រុមដែលអាចជ្រើសបាន។

✓ ប្តូរ filter ដើម្បីប្រៀបធៀបសញ្ជាតិដែលបានកត់ត្រា មុន និងក្រោយការបញ្ចប់លំហូរ។

ស្វែងយល់អំពីសកម្មភាពសញ្ជាតិដែលមិនទាន់បញ្ចប់​

In Progress រួមបញ្ចូលភ្ញៀវដែលសម្គាល់បាន និងមានសកម្មភាពចុះឈ្មោះ ឯកសារ ឬហត្ថលេខាដែលបានកត់ត្រា។ ភ្ញៀវមិនចាំបាច់បញ្ចប់គ្រប់ជំហានក្នុងលំហូរដែលបានជ្រើសទេ។ ភ្ញៀវត្រូវតែមិនមានការបញ្ចប់ដែលជោគជ័យមុនថ្ងៃបញ្ចប់របាយការណ៍។

AVA វាយតម្លៃសកម្មភាពដែលមិនទាន់បញ្ចប់តាមថ្ងៃបញ្ចប់របាយការណ៍។ ការបញ្ចប់នៅពេលក្រោយ ឬការធ្វើបច្ចុប្បន្នភាពព័ត៌មានលម្អិតភ្ញៀវ មិនលុបសកម្មភាពប្រវត្តិសាស្ត្រនោះទេ។ វាជួយឱ្យរបាយការណ៍ចាស់នៅមានស្ថិរភាព នៅពេលអ្នកប្រៀបធៀបអំឡុងពេលប្រតិបត្តិការផ្សេងៗ។

All បញ្ចូលក្រុមដែលបានបញ្ចប់ និង In Progress ដោយមិនរាប់ភ្ញៀវម្នាក់ពីរដង។ ចំនួនសរុបសំខាន់ៗរបស់ Analytics នៅតែផ្អែកលើការបញ្ចប់។ មានតែផ្នែក Guest Nationality ប៉ុណ្ណោះដែលបន្ថែមភ្ញៀវមិនទាន់បញ្ចប់។

សញ្ជាតិមិនស្គាល់

ភ្ញៀវដែលមិនទាន់បញ្ចប់អាចបង្ហាញក្រោម Unknown នៅពេល AVA គ្មានសញ្ជាតិដែលអាចប្រើបាន។ AVA អាចបំពេញតម្លៃ Unknown ខ្លះនៅពេលក្រោយ ប្រសិនបើភស្តុតាងពីការស្នាក់នៅដូចគ្នាមិនមានភាពមិនច្បាស់។ ការផ្គូផ្គងភ្ញៀវដែលមិនច្បាស់ នឹងនៅតែមិនរាប់ក្នុងការកំណត់សញ្ជាតិ។

ក្រាហ្វចំណែកបង្ហាញសញ្ជាតិដែលមានឈ្មោះចំនួនប្រាំធំបំផុត។ វាប្រមូលសញ្ជាតិដែលមានឈ្មោះនៅសល់ជា Other nationalities។ វារក្សាភ្ញៀវដែលគ្មានសញ្ជាតិអាចប្រើបានក្នុងក្រុម Unknown ដាច់ដោយឡែក។ របារក្រាហ្វប្រើភ្ញៀវដែលបានរាប់ទាំងអស់ជាមាត្រដ្ឋាន 100%។

បើមានសញ្ជាតិដែលមានឈ្មោះលើសពីប្រាំ សូមជ្រើស Show all នៅខាងក្រោមក្រាហ្វ។ ក្រាហ្វដែលបានពង្រីកនឹងរាយសញ្ជាតិដែលមានឈ្មោះទាំងអស់ និងដក Other nationalities ចេញ។ ជ្រើស Show less ដើម្បីត្រឡប់ទៅសេចក្តីសង្ខេបសញ្ជាតិប្រាំ។ ការប្តូរ report ឬ filter ស្ថានភាពបញ្ចប់ នឹងកំណត់ការពង្រីកឡើងវិញ។

Pre-Arrival នៅតែដាច់ដោយឡែកពីសកម្មភាព CCI ឬ ACI នៅពេលក្រោយ។ សកម្មភាព CCI ឬ ACI ដោយផ្ទាល់ មិនបន្ថែមភ្ញៀវទៅក្នុងក្រុម Pre-Arrival ទេ។ លទ្ធផល Check-In អនុវត្តតាម view Overall, CCI + ACI, Self Check-In (CCI) ឬ Assisted Check-In (ACI) ដែលបានជ្រើស។ ការស្នាក់នៅម្តងហើយម្តងទៀតនៅតែដាច់ដោយឡែក នៅពេលកាលបរិច្ឆេទស្នាក់នៅ ឬកំណត់ត្រាលេខបញ្ជាក់ខុសគ្នា។ កំណត់ត្រាបន្ទប់ដែលពាក់ព័ន្ធ ត្រូវបានបញ្ចូលជាមួយគ្នា នៅពេលវាជារបស់ការស្នាក់នៅដូចគ្នា។

AVA ផ្តល់អាទិភាពដល់សញ្ជាតិដែលបានរក្សាទុកក្នុង completion snapshot ឬកំណត់ត្រាភ្ញៀវ។ វាធ្វើឱ្យកូដសញ្ជាតិដែលគាំទ្រមានទម្រង់ស្របគ្នា មុនពេលប្រមូលលទ្ធផលជាក្រុម។ AVA មិនសន្និដ្ឋានសញ្ជាតិពីប្រទេសដែលចេញឯកសារទេ។ ភ្ញៀវដែលគ្មានសញ្ជាតិអាចប្រើបាន នឹងបង្ហាញក្រោម Unknown។ ការបញ្ចប់ចាស់ៗដែលមានភ្ញៀវច្រើន និងមិនច្បាស់ នឹងបង្ហាញក្នុងចំនួន ambiguous-participation ដាច់ដោយឡែក។

នៅពេលការធ្វើ refresh checkout មិនមានព័ត៌មានសញ្ជាតិ AVA រក្សាតម្លៃដែលបានកត់ត្រាសម្រាប់ភ្ញៀវដែលផ្គូផ្គងបានតែម្នាក់។ សម្រាប់ Analytics checkout AVA ពិនិត្យ completion snapshot ដែលផ្គូផ្គង និងកើតឡើងមុនគេបំផុតជាមុន។ បន្ទាប់មក វាពិនិត្យភស្តុតាងសញ្ជាតិតែមួយគត់ពីកំណត់ត្រាបច្ចុប្បន្ន។ ការផ្គូផ្គងប្រើសណ្ឋាគារ បន្ទប់ parent confirmation កាលបរិច្ឆេទមកដល់ និងកាលបរិច្ឆេទចាកចេញ។ Reservation IDs តែឯង មិនអាចកំណត់សញ្ជាតិឱ្យភ្ញៀវដៃគូបានទេ។ ឈ្មោះ អ៊ីមែល ទីតាំងក្នុងបញ្ជី និងភស្តុតាងមិនច្បាស់ ក៏មិនអាចកំណត់សញ្ជាតិបានដែរ។

បច្ចុប្បន្នភាពសញ្ជាតិពីផ្ទៃខាងក្រោយ

លទ្ធផល checkout អាចបង្ហាញ Unknown ដំបូង ខណៈពេល daily rollup កំពុងត្រូវបានផ្ទៀងផ្ទាត់។ AVA អាចបំពេញសញ្ជាតិនៅពេលក្រោយ នៅពេលភស្តុតាងពីការស្នាក់នៅដូចគ្នាផ្គូផ្គងបានដោយមិនច្រឡំ។ ភស្តុតាងដែលផ្ទុយគ្នា មិនពាក់ព័ន្ធ ឬសម្រាប់ពេលអនាគត នឹងនៅជា Unknown។ Refresh Analytics បន្ទាប់ពីការធ្វើ refresh rollup បញ្ចប់ ដើម្បីមើលចំនួនដែលបានធ្វើបច្ចុប្បន្នភាព។

ការទាញយក PDF រួមបញ្ចូលជួរសញ្ជាតិទាំងអស់ ទោះបីតារាងផ្ទាល់ត្រូវបានបង្រួមក៏ដោយ។ វាមិនរួមបញ្ចូលចំនួនសរុប Other nationalities ទេ ដើម្បីការពារការរាប់ប្រទេសស្ទួន។ សេចក្តីសង្ខេប Analytics និងការឆ្លើយតប MCP រក្សាទុកការបែងចែកសញ្ជាតិពេញលេញ។

អានទិន្នន័យដែលបាត់ឱ្យបានត្រឹមត្រូវ

ផ្នែកដែលមិនអាចប្រើបាន មានន័យថាសំណួរសញ្ជាតិបានបរាជ័យ ឬលើសកម្រិតសុវត្ថិភាពរបស់វា។ វាមិនដូចគ្នានឹងរបាយការណ៍ដែលមានភ្ញៀវសូន្យទេ។ របាយការណ៍នេះគ្របដណ្តប់សកម្មភាព AVA ដែលបានបញ្ចប់ មិនមែនចំនួនអ្នកស្នាក់នៅពេញលេញពី PMS ទេ។

ចំនួនសញ្ជាតិភ្ញៀវមើលទៅទាបជាងការរំពឹងទុក​

អ្វីដែលអ្នកឃើញ: របាយការណ៍សញ្ជាតិមានចំនួនភ្ញៀវតិចជាងរបាយការណ៍ចំនួនអ្នកស្នាក់នៅពី PMS របស់អ្នក។

វិធីដោះស្រាយ:

  1. បញ្ជាក់ flow និង date range ដែលបានជ្រើស។
  2. ពិនិត្យថាភ្ញៀវបានបញ្ចប់សកម្មភាព AVA ដែលត្រូវការឬអត់។
  3. ពិនិត្យចំនួន Unknown និងចំនួនដែលមិនបានកំណត់ប្រភព។
  4. ចងចាំថា AVA រាប់អ្នកចូលរួមដែលបានបញ្ចប់ មិនមែនអ្នកស្នាក់នៅ PMS ទាំងអស់ទេ។
  5. ទាក់ទង support ប្រសិនបើភ្ញៀវដែលបានបញ្ចប់នៅតែបាត់។

របាយការណ៍សញ្ជាតិភ្ញៀវមិនអាចប្រើបាន​

អ្វីដែលអ្នកឃើញ: ផ្នែក Guest Nationality បង្ហាញ Unavailable។

វិធីដោះស្រាយ:

  1. Refresh Command Center → Analytics ម្តង។

  2. បង្រួម date range ប្រសិនបើវាគ្របដណ្តប់ session ច្រើន។

  3. បញ្ជាក់ថា flow ដែលបានជ្រើសមានសកម្មភាព AVA ដែលបានបញ្ចប់។

  4. សាកល្បងម្តងទៀត បន្ទាប់ពី refresh rollup បានបញ្ចប់។

  5. ទាក់ទង support ប្រសិនបើផ្នែកនេះនៅតែមិនអាចប្រើបាន។

    ✓ កុំចាត់ទុករបាយការណ៍ដែលមិនអាចប្រើបានថាជាលទ្ធផលសូន្យ។

ប្រើបង្អួចកាលបរិច្ឆេទតាមម៉ោងមូលដ្ឋានរបស់សណ្ឋាគារ​

Analytics ប្រើ timezone ដែលបានកំណត់សម្រាប់សណ្ឋាគាររបស់អ្នក នៅពេលអាន date range ដែលបានជ្រើស។ វាត្រង session តាម timestamp នៃសកម្មភាព check-in និង check-out មិនមែនតាមពេលធ្វើបច្ចុប្បន្នភាព reservation ទេ។ មានតែជំហានក្នុងបង្អួចម៉ោងមូលដ្ឋាននោះប៉ុណ្ណោះ ដែលចូលរួមក្នុងតារាង និងលទ្ធផលបញ្ចប់របស់ថ្ងៃដែលបានជ្រើស។ ការធ្វើបច្ចុប្បន្នភាព reservation នៅពេលក្រោយ មិនអាចបន្ថែមជំហានបញ្ចប់ពីអតីតកាល ឬអនាគតទៅក្នុង Analytics របស់ថ្ងៃនោះបានទេ។ កាត Successful Check‑Outs គឺជាករណីលើកលែង ព្រោះវាប្រើកាលបរិច្ឆេទបញ្ចប់របស់ terminal event។

ប្រៀបធៀបថ្ងៃប្រតិបត្តិការមូលដ្ឋាន

ជ្រើសកាលបរិច្ឆេទតាមថ្ងៃប្រតិទិនរបស់សណ្ឋាគារ ទោះបីអ្នកពិនិត្យ Analytics ពី timezone ផ្សេងក៏ដោយ។

របៀប AVA បង្កើត session​

  • Session មួយ គឺកំណត់ត្រា check-in មួយសម្រាប់ការកក់ មិនមែនសម្រាប់ភ្ញៀវនីមួយៗទេ។
  • Session ត្រូវបានរាប់នៅពេលយ៉ាងហោចណាស់មានមួយជំហានពី view នោះត្រូវបានកត់ត្រា។
  • Session ដែលមានស្លាក Demo ត្រូវបានដកចេញពីតារាង Analytics ទាំងនេះ។
  • ជំហានបរាជ័យនៅតែរាប់ក្នុងចំនួនសរុប ដើម្បីឱ្យអ្នកមើលឃើញ drop-offs និងបញ្ហា។
Pre‑Arrival គឺដាច់ដោយឡែក

Session ដែលឈានដល់តែ Pre‑Arrival ប៉ុណ្ណោះ មិនត្រូវបានរាប់ក្នុង All Check‑Ins ទេ។ សម្រាប់ session ទាំងនោះ សូមប្រើ view Pre‑Arrival។ បើភ្ញៀវបញ្ចប់ pre-arrival ហើយបន្ទាប់មកបញ្ចប់ check-in លើឧបករណ៍ AVA នឹងរាប់ session នោះក្នុង view ទាំងពីរ។ ការប៉ុនប៉ង Pre‑Arrival ដែលត្រូវបានបោះបង់ នៅតែបង្ហាញក្នុង view Pre‑Arrival បន្ទាប់ពីភ្ញៀវចាប់ផ្តើម flow។

នៅពេលភ្ញៀវបន្តបន្ទាប់ពី pre-arrival​

View Pre‑Arrival គឺជាក្រុម session តាមលក្ខខណ្ឌ មិនមែនជាប្រភេទដែលផ្តាច់មុខទេ។ Session មួយអាចស្ថិតក្នុងក្រុម Pre‑Arrival និងក្រុម Check‑In បាន។ Session មានសិទ្ធិចូលក្រុម នៅពេលសកម្មភាព Pre‑Arrival ចាប់ផ្តើម ទោះភ្ញៀវបោះបង់ flow ក៏ដោយ។ ការឈានដល់ PRE_ARRIVAL មានន័យថា session បានបញ្ចប់។ ការបើកតំណ pre-arrival ដោយគ្មានសកម្មភាព flow ដែលបានកត់ត្រា មិនធ្វើឱ្យ session មានសិទ្ធិទេ។ Milestone check-in ពេញលេញដែលបានសង្កេតឃើញ នៅតែធ្វើឱ្យ session នោះត្រូវបានរាប់ក្នុង Check‑In ត្រឹមត្រូវ។

សកម្មភាពរបស់ភ្ញៀវView Analytics
ភ្ញៀវបើកតំណ ដោយគ្មានសកម្មភាព flow ដែលបានកត់ត្រាមិនរាប់ក្នុង Pre‑Arrival
ភ្ញៀវចាប់ផ្តើម Pre‑Arrival ប៉ុន្តែបោះបង់Pre‑Arrival, មិនទាន់បញ្ចប់
ភ្ញៀវបញ្ចប់ pre-arrival តែប៉ុណ្ណោះPre‑Arrival, បានបញ្ចប់
ភ្ញៀវបញ្ចប់ pre-arrival ហើយបន្ទាប់មកបញ្ចប់ check-in លើឧបករណ៍Pre‑Arrival និង Check‑In

វាធ្វើឱ្យដំណើរចម្រុះនៅតែអាចមើលឃើញក្នុងក្រុមដែលពាក់ព័ន្ធទាំងពីរ។ ដំណើរ pre-arrival សុទ្ធ នៅតែមិនរាប់ក្នុង All Check‑Ins។ សម្រាប់ Pre‑Arrival, Total Logs រាប់គ្រប់ session ដែលមានសកម្មភាពបានកត់ត្រា។ Completion Rate រាប់ session ដែលឈានដល់ PRE_ARRIVAL។ ឧទាហរណ៍ ការប៉ុនប៉ង 3 ដង និងបញ្ចប់ 2 ដង បង្ហាញ completion rate 66.7%។ ដូច្នេះ ការប៉ុនប៉ងដែលបោះបង់នឹងបន្ថយអត្រា ហើយបង្ហាញការធ្លាក់ចុះក្នុង flow។

នៅពេលភ្ញៀវបញ្ចប់ Pre‑Arrival ហើយចាប់ផ្តើមដំណើរ CCI ឬ ACI ដែលមិនទាន់ពេញលេញ ការប៉ុនប៉ង check-in នោះនៅតែរាប់ក្នុងចំនួន check-in តាម mode ដែលបានកំណត់។ សកម្មភាព Pre‑Arrival សុទ្ធនៅតែមិនរាប់ក្នុង All Check‑Ins ទេ។ វារក្សាចំនួនការប្រើប្រាស់ Check-In ឱ្យផ្តោតលើភ្ញៀវដែលបានចាប់ផ្តើមដំណើរ check-in។

បើ reservation មួយមានសកម្មភាព checkout នៅពេលក្រោយ ដោយគ្មានសកម្មភាព Check-In AVA រក្សាប្រវត្តិ Pre‑Arrival របស់វាក្នុង Pre‑Arrival ហើយរាយការណ៍សកម្មភាព checkout ក្នុង Check‑Out។ វាមិនបង្កើតការប៉ុនប៉ង Check-In ពីប្រវត្តិ checkout តែឯងទេ។

សកម្មភាពដែលមិនមែន PRE ពិតប្រាកដ ប៉ុន្តែគ្មាន mode CCI ឬ ACI ដែលបានកត់ត្រា អាចនៅតែបង្ហាញក្នុង Overall។ CCI + ACI រួមបញ្ចូលតែដំណើរដែលមានការកំណត់ថាជា CCI ឬ ACI ដែលបានកត់ត្រា។

Rollup ប្រវត្តិសាស្ត្រ

Daily rollup ដែលបានរក្សាទុកពីមុន អាចនៅតែរក្សាចំនួន Pre‑Arrival តាមការបញ្ចប់ រហូតដល់ AVA គណនាឡើងវិញ។ Rollup ដែលគណនាថ្មី នឹងរាប់ការប៉ុនប៉ងដែលបោះបង់ក្នុង denominator។

នៅពេល key encoding ជាជំហានចុងក្រោយដែលបានកត់ត្រា​

AVA ចាត់ KEY_ENCODED ជាសញ្ញាកំណត់ប្រភេទ Full Check-In។ វាអនុវត្ត ទោះ session មិនមានជំហាន KEY_COLLECTION ឬ KEY_RETRIEVED ក៏ដោយ។ Session នោះបង្ហាញក្នុង Full Check‑In និង All Check‑Ins។ KEY_ENCODED មិនត្រូវបានរាប់ជាសញ្ញាបញ្ចប់សម្រាប់ Completion Rate ទេ។ ដូច្នេះ session អាចបង្កើនចំនួន Full Check-In ប៉ុន្តែមិនបង្កើន session ដែលបានបញ្ចប់ឡើយ។

Completion rate អាចផ្លាស់ប្តូរ

អចលនទ្រព្យដែលប្រើ keycard encoding អាចឃើញ Full Check-In completion rate ទាបជាងបន្តិច។ វាកើតឡើងនៅពេល session បញ្ចប់ត្រឹម KEY_ENCODED ដោយគ្មានសញ្ញាបញ្ចប់ផ្សេងទៀត។

កាតសង្ខេប (ផ្នែកខាងលើនៃ tab)​

នៅលើ Check-In, AVA រៀបចំ AVA Reservation Coverage, Check-in Result, និង Room Access Delivered ឱ្យស្របគ្នា។ កាតទាំងនេះឆ្លើយសំណួរប្រតិបត្តិការខុសៗគ្នា។

នៅលើ Pre-Arrival, AVA បង្ហាញកាត Pre-Arrival Result មួយនៅខាងលើ funnel។ វារាយការណ៍សកម្មភាពដែលបានកត់ត្រាក្នុងរយៈពេលដែលបានជ្រើស។

កាតអ្វីដែលវាប្រាប់អ្នករបៀបគណនា
AVA Reservation Coverageចំនួន reservation ដែលមានសិទ្ធិមកដល់ ហើយបានចាប់ផ្តើម check-in ជាមួយ AVAឯកតាមកដល់ដែល AVA ដំណើរការ ÷ ឯកតាមកដល់ដែលមានសិទ្ធិ
Check-in Resultតើប្រព័ន្ធសណ្ឋាគារបានបញ្ជាក់ check-in របស់ភ្ញៀវឬអត់PMS CHECKIN ដែលជោគជ័យ ÷ ការប៉ុនប៉ង check-in របស់ AVA
Room Access Deliveredតើ AVA បានកត់ត្រាការបញ្ជូនសិទ្ធិចូលបន្ទប់បន្ទាប់ពី check-in ឬអត់ការបញ្ជូនសិទ្ធិចូលដែលបានកត់ត្រា ÷ ការប៉ុនប៉ង check-in ដែលមានសិទ្ធិ

កាតទាំងនេះធ្វើឱ្យ coverage, check-in របស់សណ្ឋាគារ និងការបញ្ជូនសិទ្ធិចូលបន្ទប់ អាចមើលឃើញជាលទ្ធផលដាច់ដោយឡែក។ Check-in Result ដែលជោគជ័យ មិនបញ្ជាក់ថាបានបញ្ជូនសិទ្ធិចូលបន្ទប់រួចហើយទេ។

កាត Check-in Result សួរថា “តើ AVA បានកត់ត្រាថាភ្ញៀវបានបញ្ចប់ check-in របស់សណ្ឋាគារឬទេ?” កាត Room Access Delivered សួរថា “តើ AVA បានកត់ត្រាថាបានបញ្ជូនសិទ្ធិចូលបន្ទប់ឬទេ?” ឧទាហរណ៍ event កូដកាតបន្ទប់អាចផ្តល់ភស្តុតាងអំពីសិទ្ធិចូលបន្ទប់។

ជ្រើសប៊ូតុងព័ត៌មាននៅជាប់ metric ដើម្បីបើកសេចក្តីពន្យល់លម្អិត។ អ្នកអាចផ្តោត និងបើកសេចក្តីពន្យល់ទាំងនេះដោយប្រើក្តារចុច។ សេចក្តីពន្យល់នៅតែបង្ហាញ នៅពេលកាត coverage កាត់បន្ថយមាតិកាដែលវាបង្ហាញ។ នៅលើអេក្រង់តូច AVA រក្សាសេចក្តីពន្យល់ឱ្យស្ថិតនៅក្នុងគែមអេក្រង់។ វានឹងរៀបទីតាំងឡើងវិញ នៅពេលអ្នក scroll ឬប្តូរទំហំ window។ ចុច Escape ដើម្បីបិទសេចក្តីពន្យល់ដែលកំពុងបើក។

អានកាតទាំងបីជាមួយគ្នា

ប្រើ AVA Reservation Coverage ដើម្បីវាស់ការប្រើប្រាស់ AVA ក្នុងចំណោមអ្នកមកដល់។ ប្រើ Check-in Result ដើម្បីបញ្ជាក់លទ្ធផល check-in ពី PMS។ ប្រើ Room Access Delivered ដើម្បីស្វែងរកការបញ្ជូនសិទ្ធិចូលដែលត្រូវតាមដានបន្ថែម។

អានកាត Pre-Arrival Result​

កាតនេះបញ្ចូល completion rate, reservation ដែលបានបញ្ចប់, ការប៉ុនប៉ង និងពេលវេលាបញ្ចប់ជាមធ្យម។

Metricអ្វីដែលវាបង្ហាញរបៀបអាន
Completion Rateភាគរយបញ្ចប់ Pre-ArrivalReservation ដែលបានបញ្ចប់ ÷ ការប៉ុនប៉ង Pre-Arrival
CompletedReservation ដែលឈានដល់ជំហាន PRE_ARRIVALការបញ្ចប់ Pre-Arrival ដែលជោគជ័យក្នុងរយៈពេលសកម្មភាពដែលបានជ្រើស
Avg Completion Timeពេលវេលាជាមធ្យមពីជំហានជោគជ័យដំបូងដល់ PRE_ARRIVALរយៈពេលដែលដំណើរ Pre-Arrival ដែលបានបញ្ចប់ត្រូវការ

Pre-Arrival ប្រើការប៉ុនប៉ង និងការបញ្ចប់របស់ AVA ពីរយៈពេលសកម្មភាពដែលបានជ្រើស។ វាមិនប្រើចំនួន coverage នៃការមកដល់ ឬការចាកចេញពី PMS ទេ។ Arrival dates អាចស្ថិតក្រៅរយៈពេលដែលបានជ្រើស។ ភ្ញៀវដែលក្រោយមកបញ្ចប់ CCI ឬ ACI នៅតែស្ថិតក្នុងក្រុម Pre-Arrival។

ប្រៀបធៀបក្រុមដែលត្រឹមត្រូវ

ប្រើ Pre-Arrival Result ដើម្បីវាស់សកម្មភាពត្រៀមខ្លួនរបស់ភ្ញៀវ។ ប្រើ AVA Reservation Coverage សម្រាប់ coverage នៃការមកដល់ពី PMS ក្នុង view Check-In។ ប្រើ AVA Departure Coverage សម្រាប់ coverage នៃការចាកចេញពី PMS ក្នុង view Check-Out។

កាតរបៀបគណនា
Total Logsចំនួន session ដែលមិនមែន Demo ក្នុង view ដែលបានជ្រើស
Completion Ratesession ដែលបានបញ្ចប់ ÷ logs ដែលមិនមែន Demo សរុប ដោយប្រើច្បាប់បញ្ចប់របស់ view
Avg Completion Timeពេលវេលាពីជំហានជោគជ័យដំបូង (ជាទូទៅ Entry) ដល់សញ្ញាបញ្ចប់ដែលបានកំណត់
Successful Check‑InsSession ខុសគ្នាដែលមាន milestone PMS CHECKIN ជោគជ័យ។ វាគាំទ្រលទ្ធផល Check-in Result។
Room Access Delivery Rateការបញ្ជូន room-access ដែលជោគជ័យបន្ទាប់ពី PMS CHECKIN ÷ ការប៉ុនប៉ង check-in ដែលមានសិទ្ធិទាំងអស់។ នេះគាំទ្រលទ្ធផល Room Access Delivered។
Successful Check‑OutsSession checkout ដាច់ដោយឡែកដែលមាន terminal event ជោគជ័យ ដោយកំណត់តាមកាលបរិច្ឆេទបញ្ចប់

Room Access Delivered បង្ហាញនៅពេល AVA មានទិន្នន័យការបញ្ជូនសិទ្ធិចូលបន្ទប់សម្រាប់ view check-in ដែលបានជ្រើស។ កាតនេះបង្ហាញនៅពេលសណ្ឋាគាររបស់អ្នកប្រើការបញ្ជូនសិទ្ធិចូលបន្ទប់ដែលគ្រប់គ្រងដោយ AVA។ វារួមមាន smart locks, lockers និង keycards ដែលបានកំណត់រចនាសម្ព័ន្ធ ហើយមិនមែនជាវិធីដោយដៃ។ កាតនេះរាប់តែ event បញ្ជូនសិទ្ធិចូលដែល AVA បានកត់ត្រា បន្ទាប់ពី PMS CHECKIN ជោគជ័យ។ ការបញ្ជូនដោយដៃ ឬពីប្រព័ន្ធខាងក្រៅ មិនត្រូវបានរាប់ទេ លុះត្រាតែ AVA កត់ត្រា event ដែលមានសិទ្ធិ។

លក្ខខណ្ឌមានសិទ្ធិបញ្ជូន

AVA ប្រើការកំណត់ Room Access ដើម្បីសម្រេចថាតើការបញ្ជូនសិទ្ធិចូលអនុវត្តឬអត់។ Analytics មិនតម្រូវឱ្យអ្នកចាត់ថ្នាក់ lock, locker ឬវិធី keycard នីមួយៗទេ។ បើការបញ្ជូនមិនមាន ឬជាការបញ្ជូនដោយដៃ AVA នឹងលាក់កាតជាជម្រើសនេះ។

សម្រាប់ view Check-In, Completion Rate ប្រើ PMS CHECKIN ដែលជោគជ័យជាដំណាក់កាលបញ្ចប់សំខាន់។ ជួរឈរ Completion rule ក៏គ្រប់គ្រង Avg Completion Time ផងដែរ។ វាមិនកំណត់ Successful Check‑Ins ឬ Room Access Delivery Rate ទេ។

ប្រើតារាងនេះដើម្បីបញ្ជាក់ថា session ណាខ្លះគួររាប់ជាបញ្ចប់ មុនអ្នកប្រៀបធៀបរវាងរយៈពេល។

Successful Check-Outs ប្រើកាលបរិច្ឆេទបញ្ចប់​

កាត Successful Check‑Outs រាប់ checkout នីមួយៗដែលឈានដល់ terminal event ជោគជ័យ។ AVA ដាក់ចំនួននេះទៅតាមថ្ងៃប្រតិទិនមូលដ្ឋានរបស់សណ្ឋាគារ នៅពេល checkout ជោគជ័យ។ ការប៉ុនប៉ង checkout, funnel stages, Completion Rate, និង Avg Completion Time នៅតែប្រើការកំណត់តាមកាលបរិច្ឆេទចាប់ផ្តើម។

ឧទាហរណ៍ checkout ដែលចាប់ផ្តើមថ្ងៃចន្ទ ហើយជោគជ័យថ្ងៃអង្គារ នឹងបង្ហាញក្នុង Successful Check‑Outs របស់ថ្ងៃអង្គារ។ សកម្មភាព attempt និង funnel របស់វានៅតែស្ថិតក្នុង analytics checkout របស់ថ្ងៃចន្ទ។

នេះធ្វើឱ្យការចាកចេញដែលជោគជ័យ ស្របតាមថ្ងៃដែលវាបានបញ្ចប់។

ឧទាហរណ៍

បើ Total Logs ស្មើ 40 ហើយមាន 28 session ឈានដល់សញ្ញាបញ្ចប់ដែលបានកំណត់ នោះ completion rate គឺ 70%។ Successful Check‑Ins អាចបង្ហាញចំនួនផ្សេង ព្រោះវារាប់ milestone check-in ពី PMS ដែលជោគជ័យ។

បំបែក PMS check-in ពីការបញ្ចប់ដំណើរ​

Successful Check‑Ins បញ្ជាក់ថា AVA បានបញ្ចប់សំណើ PMS CHECKIN។ សម្រាប់ OPERA, នេះជាពេល AVA ផ្ញើកូដ SCI ទៅ PMS។ AVA រាប់ milestone នេះតែពេលភស្តុតាង Check-In ដែលបានកត់ត្រាមាន SUCCESS ឬ PARTIAL ប៉ុណ្ណោះ។ ទិន្នន័យ milestone ចាស់ដែលកំពុងរង់ចាំ ឬបរាជ័យ មិនរាប់ជា PMS check-in ជោគជ័យទេ។ AVA ដកចេញដំណើរដែលមានតែ checkout នៅពេលភស្តុតាង event បង្ហាញថាគ្មានសកម្មភាព Check-In។ វាទប់ស្កាត់មិនឱ្យសញ្ញា CHECKIN ចាស់លើ checkout ដែលបានបញ្ចប់ បំប៉ោងចំនួន។ បើភ្ញៀវបានបញ្ចប់ Check-In មុន Checkout AVA នឹងរក្សាចំនួន Check-In ជោគជ័យនោះ។

សម្រាប់ view Check-In, Completion Rate ប្រើ PMS CHECKIN ដែលជោគជ័យជាដំណាក់កាលបញ្ចប់សំខាន់។ វាធ្វើឱ្យការបញ្ចប់ check-in ស្របតាមលទ្ធផលពី PMS។ Room Access Delivery Rate វាស់ការចូលបន្ទប់ដាច់ដោយឡែកពីការបញ្ចប់ check-in។

អ្វីដែលកើតឡើងSuccessful Check‑InsMetrics នៃការបញ្ចប់
PMS CHECKIN ជោគជ័យ បន្ទាប់មក keycard encoding បរាជ័យរាប់ PMS check-inរាប់ជាបានបញ្ចប់; room access delivery អាចនៅតែមិនជោគជ័យ
មានតែសញ្ញា CHECKIN ចាស់ដែលកំពុងរង់ចាំ ឬបរាជ័យមិនរាប់អនុវត្តតាមច្បាប់បញ្ចប់ដែលមានស្រាប់របស់ view ដែលបានជ្រើស
Room assignment ចូលជួរ ដោយគ្មាន PMS CHECKIN ជោគជ័យមិនរាប់អនុវត្តតាមច្បាប់បញ្ចប់របស់ view
PMS CHECKIN និង room access ជោគជ័យទាំងពីររាប់ PMS check-inរាប់ជាបញ្ចប់ នៅពេល terminal signal ជោគជ័យ

កាតនេះលែងបញ្ចូល queued, early និង key-collection categories ជាមួយគ្នាទៅក្នុង Successful Check‑Ins ទៀតហើយ។

Room Access Delivery Rate ប្រើ event បន្ទាប់ពី check-in​

Room Access Delivery Rate រាប់ room access តែបន្ទាប់ពី PMS CHECKIN ជោគជ័យប៉ុណ្ណោះ។ Event ដែលមានសិទ្ធិរាប់ គឺ KEY_COLLECTION, GET_DOOR_LOCK_KEY, KEY_ENCODED ឬ KEY_RETRIEVED ដែលជោគជ័យ។ សំណុំការប៉ុនប៉ងដែលមានសិទ្ធិ ប្រើសមត្ថភាពបញ្ជូនរបស់ room-access service។ វារួមមាន smart locks, lockers និងការបញ្ជូន keycard ដែលបានកំណត់រចនាសម្ព័ន្ធ និងមិនមែនជាវិធីដោយដៃ។ វាមិនរាប់ការបញ្ជូនដោយដៃ និងការកំណត់ room-access ដែលមិនមានទេ។ Event ពីការប៉ុនប៉ងមុន ឬការប៉ុនប៉ងដែលបរាជ័យ មិនអាចរាប់សម្រាប់ check-in ជោគជ័យនៅពេលក្រោយបានទេ។

ភាគបែងរួមមានការប៉ុនប៉ង check-in ដែលមានសិទ្ធិទាំងអស់។ ការងារ room-access ដោយដៃ ឬតាម external មិនរាប់ទេ លុះត្រាតែ AVA បានកត់ត្រា event ដែលមានសិទ្ធិ។ Analytics ផ្ទាល់ និង daily rollups ប្រើការគណនាដូចគ្នា។

Room access delivery មើលទៅទាបជាងការរំពឹងទុក​

អ្វីដែលអ្នកឃើញ: Room Access Delivery Rate ទាបជាងចំនួនភ្ញៀវដែលបាន check-in។

វិធីដោះស្រាយ:

  1. បញ្ជាក់ថាភ្ញៀវមាន event PMS CHECKIN ដែលជោគជ័យ។

  2. ពិនិត្យថាមាន event room-access ដែលជោគជ័យបន្ទាប់ពី check-in នោះ។

  3. ចងចាំថា encoding ដោយដៃ ឬ external មិនត្រូវបានរាប់ទេ។

  4. Refresh Command Center → Analytics បន្ទាប់ពី event ត្រូវបានកត់ត្រា។

    ✓ Event access ដែលកើតមុន បរាជ័យ ឬកំពុងរង់ចាំ មិនបង្កើន rate នេះទេ។

Room Access Delivered បាត់​

អ្វីដែលអ្នកឃើញ: កាត Room Access Delivered មិនបង្ហាញ។

វិធីដោះស្រាយ:

  1. បើក Settings → Room Access។

  2. បញ្ជាក់ថាមានវិធីដែលគ្រប់គ្រងដោយ AVA បានកំណត់រចនាសម្ព័ន្ធ។

  3. ប្រើ smart locks, lockers ឬការបញ្ជូន keycard ដែលបានកំណត់រចនាសម្ព័ន្ធ និងមិនមែនជាវិធីដោយដៃ។

  4. Refresh Command Center → Analytics។

    ✓ ការបញ្ជូនដោយដៃ ឬការបញ្ជូនដែលមិនមាន មិនបង្ហាញកាតជាជម្រើសនេះទេ។

កាត coverage check-in​

ពេល AVA ទទួលទិន្នន័យ coverage ពី PMS របស់អ្នក អ្នកអាចឃើញកាតបន្ថែមពីរបន្ទាប់ពី Completion Rate។ វាដំណើរការសម្រាប់ AVA PMS, Cloudbeds, Opera, Mews, និង eZee។

កាតអ្វីដែលវាបង្ហាញមូលហេតុដែលវាសំខាន់
Eligible Check-In Unitsconfirmation units ឬ sub-reservation units ដាច់ដោយឡែកក្នុងរយៈពេលដែលបានជ្រើសនេះជាខ្នាតគណនាសម្រាប់ coverage
AVA Check-In Shareភាគរយនៃ units ដែលមានសិទ្ធិ ដែល AVA បានដំណើរការយ៉ាងហោចណាស់ម្តងនេះបង្ហាញការទទួលយក AVA សម្រាប់រយៈពេលនោះ
Coverage ប្រើកាលបរិច្ឆេទមកដល់

Coverage ប្រើ arrival date របស់ reservation នីមួយៗ តាម timezone របស់សណ្ឋាគារ។ ភ្ញៀវដែលបញ្ចប់ pre-arrival check-in មុនពេលកំណត់ នៅតែរាប់នៅពេលពួកគេមកដល់ក្នុងចន្លោះ។ Funnel ប្រើកាលបរិច្ឆេទសកម្មភាព ដូច្នេះវិធានការទាំងនេះឆ្លើយសំណួរខុសគ្នា។

ឯកតា ប្រៀបធៀបនឹងការកក់

កាតទាំងនេះរាប់ units មិនមែន reservations ទាំងមូលទេ។ ការកក់បន្ទប់ច្រើនអាចបន្ថែម eligible unit ច្រើនជាងមួយ។

របៀបដែល AVA សម្រេចថាមានសិទ្ធិ

AVA រាប់តែ reservation ដែលមានសកម្មភាព AVA មាន arrival date ត្រឹមត្រូវតាមម៉ោងក្នុងតំបន់របស់ merchant និងមាន status ដែលមានសិទ្ធិប៉ុណ្ណោះ។ សម្រាប់សកម្មភាព AVA, status ដែលមានសិទ្ធិគឺ RESERVED, CHECKED_IN, CHECKED_OUT, និង DUE_OUT។ DUE_OUT ត្រូវបានរាប់ ព្រោះ reservation បានឈានដល់ check-in មុនពេលចាកចេញរួចហើយ។ សម្រាប់ OPERA, AVA ក៏បញ្ចូល DueOut ទៅក្នុង bucket coverage PMS CHECKED_IN ផងដែរ។ វាធ្វើឱ្យការមកដល់នៅថ្ងៃចាកចេញ និងការមកដល់សម្រាប់ប្រើក្នុងថ្ងៃ ត្រូវបានរាប់ក្នុងភាគបែង coverage។ បើ AVA មិនអាចផ្ទៀងផ្ទាត់ fields ដែលត្រូវការបានទេ វានឹងលាក់កាត coverage ជំនួសឱ្យបង្ហាញភាគរយដែលអាចបំភាន់។

ការកក់ OPERA

បើ PMS របស់អ្នកគឺ OPERA, AVA នឹងមិនរាប់ PM, PF, និង PX pseudo rooms ក្នុង eligible unit count ទេ។ វាក៏ប្រើ top-level room type fields នៅពេល room rows ស្ដើង ដូច្នេះបន្ទប់ភ្ញៀវពិតប្រាកដនៅតែរាប់បានត្រឹមត្រូវ។

គ្រួសារការកក់ OPERA

AVA ក៏ដកស្ទួន linked OPERA reservation families ដោយ parent confirmation ផងដែរ។ វាជួយមិនឱ្យ sibling rows ចុងក្រោយបំប៉ោង Eligible Check-In Units។

Coverage OPERA ដែលបាន checkout

បើ date range ដែលបានជ្រើសរួមបញ្ចូលថ្ងៃនេះមុន night audit, ជើង Checked Out ដែលមានការមកដល់នៅពេលអនាគត នឹងរាប់ជា 0។ AVA ប្រើ business date របស់អចលនទ្រព្យសម្រាប់ការបញ្ឈប់ខ្លីនេះ ដើម្បីឱ្យការអាន coverage លឿន និងមានភាពស្របគ្នា។

នៅពេល arrival cohort មិនមាន

AVA ប្រើ coverage result តូចចង្អៀតសម្រាប់ arrival ក្នុង date range ដែលបានជ្រើសជាមុន។ បើ result នោះមិនមាន មិនពេញលេញ ឬកំពុងដាក់ឱ្យប្រើ AVA នឹងប្រើ logs ដែលបានត្រងតាម arrival។ បើ logs ទាំងនោះមិនមាន AVA អាចប្រើ session map ផ្អែកលើ activity។ fallback នេះអាចធ្វើឱ្យ coverage ទាបជាងពិតសម្រាប់ date range តូច។ Result ទទេគឺសូន្យដែលត្រឹមត្រូវ មិនមែនទិន្នន័យបាត់ទេ។ បើគ្មានប្រភពណាមួយ កាត coverage នឹងត្រូវលាក់។

AVA រាប់ reservation ដែលបានដំណើរការម្តងនីមួយៗ។ វាប្រើ arrival-keyed cohort សម្រាប់ coverage result ធម្មតា។ Date range ដែលបានជ្រើសប្រើ timezone របស់សណ្ឋាគារសម្រាប់ការប្រៀបធៀប arrival date។ ការស្វែងរក reservation តែប៉ុណ្ណោះ និងជំហាន sync ពី PMS ឬ front desk មិនផ្តល់ពិន្ទុដល់ AVA numerator ទេ។ បើ numerator លើស denominator AVA នឹងមិនបង្ហាញ share card ជំនួសឱ្យការកាត់តម្លៃឱ្យជាប់ទេ។ នេះធ្វើឱ្យ AVA Check-In Share ស្របគ្នាជាមួយ reservation coverage។

លទ្ធផលថ្មីអាចយឺតបន្តិច

បើអ្នក refresh date range ដដែលម្ដងទៀត AVA អាចប្រើលទ្ធផល coverage ចុងក្រោយមួយរយៈខ្លី។ នេះជួយឱ្យ tab Analytics ដំណើរការលឿននៅពេលពិនិត្យម្ដងហើយម្ដងទៀត។

កែតម្រូវ coverage ប្រវត្តិសាស្ត្រ

បន្ទាប់ពីមានការកែប្រែច្បាប់ coverage AVA នឹងធ្វើឱ្យ coverage result ចាស់ដែលបានរក្សាទុកថ្មី មុនពេលប្រើវាឡើងវិញ។ Date range ខ្លីអាចបង្ហាញកាតដែលបានកែតម្រូវមុន។ Range វែងអាចប្រើ coverage ផ្ទាល់ រហូតដល់ការធ្វើ refresh តាមកាលវិភាគបញ្ចប់។

ភាគរយចែករំលែក check-in មើលទៅមិនត្រឹមត្រូវ​

អ្វីដែលអ្នកឃើញ: AVA Check-In Share បាត់ ឬមើលទៅខ្ពស់ជាងការរំពឹងទុក។

វិធីដោះស្រាយ:

  1. Refresh tab Analytics។
  2. បញ្ជាក់ថា date range ស្របគ្នាជាមួយរបាយការណ៍ PMS របស់អ្នក។
  3. ពិនិត្យថា range ប្រើ timezone របស់សណ្ឋាគារ។
  4. បញ្ជាក់ថា PMS របស់អ្នកកំពុងផ្ញើ arrival dates និង reservation statuses។
  5. បើវានៅតែមើលទៅមិនត្រឹមត្រូវ សូមទាក់ទង support ជាមួយ screenshot។

បើអ្នកមិនឃើញកាតទាំងនេះទេ ទិន្នន័យ PMS បច្ចុប្បន្នរបស់អ្នកអាចមិនរួមបញ្ចូល metrics coverage នៃ units ទេ។ អ្នកផ្តល់ PMS ដែលមិនគាំទ្រ នឹងមិនបង្ហាញកាតទាំងនេះឡើយ។

កាត coverage check-out​

AVA បង្ហាញ coverage checkout តែពេល PMS ផ្តល់ក្រុមទិន្នន័យ departure ពេញលេញប៉ុណ្ណោះ។ អ្នកអាចឃើញកាតពីរក្នុង view Check-Out។ កាតទាំងនេះវាស់សកម្មភាព checkout របស់ AVA ដោយឡែកពីសកម្មភាព check-in។

កាតអ្វីដែលវាបង្ហាញមូលហេតុដែលវាសំខាន់
Eligible Check-Out Unitsconfirmation ឬ sub-reservation units ដាច់ដោយឡែកដែលចាកចេញក្នុងរយៈពេលដែលបានជ្រើសនេះជាភាគបែង coverage checkout
AVA Check-Out Shareភាគរយ units ដែលមានសកម្មភាព checkout របស់ AVA ដែលអាចផ្ទៀងផ្ទាត់បានបង្ហាញការប្រើប្រាស់ AVA សម្រាប់ការចាកចេញក្នុងរយៈពេលនោះ
Coverage ប្រើកាលបរិច្ឆេទចាកចេញ

Checkout coverage ប្រើ departure date របស់ reservation នីមួយៗតាម timezone របស់សណ្ឋាគារ។ Check-in coverage ប្រើ arrival date ដូច្នេះកាតទាំងពីរអាចគ្របដណ្តប់ units ខុសគ្នា។ Numerator checkout រាប់តែសកម្មភាព checkout របស់ AVA ដែលអាចរក្សាទុកបាន។ Search-only lookup និងជំហាន sync ពី PMS ឬ front desk មិនត្រូវបានរាប់ទេ។

Coverage check-out តាម PMS​

Cloudbeds, Mews និង OPERA ផ្តល់ native departure cohorts សម្រាប់ checkout coverage។ AVA មិនប្តូរ arrival coverage ទៅជ checkout coverage ទេ។ PMS adapter ដែលមិនគាំទ្រ អាចបង្ហាញ Unavailable ជំនួសភាគរយ។ សម្រាប់ OPERA ការទាញ reservation ជាទំព័រមិនពេញលេញ ក៏បង្ហាញ Unavailable ដែរ។ AVA មិនគណនាភាគរយពីទិន្នន័យ departure មិនពេញលេញទេ។

Coverage check-out មិនអាចប្រើបាន​

អ្វីដែលអ្នកឃើញ: កាត checkout coverage បង្ហាញ Unavailable ជំនួសភាគរយ។

មូលហេតុ: AVA មិនអាចផ្ទៀងផ្ទាត់ទិន្នន័យ coverage ដែលពេញលេញ និងកំណត់តាម departure បាន។ PMS អាចមិនគាំទ្រ departure cohorts ឬទំព័រ reservation របស់ OPERA អាចមិនពេញលេញ។ វាលាក់ rate ដើម្បីកុំឱ្យបង្ហាញលទ្ធផលបំភាន់។

ដំណោះស្រាយ:

  1. បញ្ជាក់ថាអ្នកបានជ្រើស Check-Out និង date range ត្រឹមត្រូវ។

  2. Refresh tab Analytics បន្ទាប់ពី PMS sync បញ្ចប់។

  3. សាកល្បង range ដដែលម្ដងទៀតបន្ទាប់ពីពីរបីនាទី។

  4. ទាក់ទង support ប្រសិនបើកាតនៅតែបង្ហាញ unavailable។

    ✓ កាត unavailable មានន័យថាលទ្ធផលមិនទាន់អាចទុកចិត្តបាន។ វាមិនមែនជាសូន្យទេ។

នាំចេញ STB EVA submissions CSV​

ការរៀបចំរហ័ស

វាចំណាយពេលក្រោម 1 នាទី។ ការនាំចេញបង្ហាញតែក្នុង Check-In នៅពេល EVA ត្រូវបានបើក។

ប្រើរូបតំណាងទាញយកតូចនៅលើផ្ទាំង STB EVA submissions ដើម្បីនាំចេញ date range ដែលបានជ្រើស។

ធាតុអ្វីដែលវាបង្ហាញអ្វីដែលអ្នកអាចធ្វើបាន
STB EVA submissionsការបញ្ជូន EVA ដែលបានព្យាយាម ជោគជ័យ និងបរាជ័យ ក្នុងរយៈពេលដែលបានជ្រើសចុចរូបតំណាងទាញយក ដើម្បីទាញយក CSV
មាតិកា CSVចំនួនសង្ខេប និងមួយជួរដេកសម្រាប់ការប៉ុនប៉ង EVA API នីមួយៗពី eva_submission_logsប្រើសម្រាប់របាយការណ៍ STB ឬការត្រួតពិនិត្យ audit

  1. បើក Main Menu → Command Center។

  2. ជ្រើស tab Analytics។

  3. ទុក view Check-In ឱ្យបានជ្រើស។

  4. រំកិលទៅ STB EVA submissions។

  5. ចុចរូបតំណាងទាញយក។

  6. រក្សាទុកឯកសារ stb-eva-submissions.csv ដែលបានទាញយក។

    ✓ ឯកសាររួមមាន transaction IDs, result codes, reservation និង check-in IDs, error metadata និងព័ត៌មាន request ដែលបានសម្អាត។ ✓ លេខ passport និង document ត្រូវបានបិទបាំង។ MRZ និង base64 fields ត្រូវបានដកចេញ។ ✓ ការនាំចេញលែងរួមបញ្ចូល legacy reservation rows ពី EVA reports ចាស់ៗទៀតហើយ។ ✓ បើការទាញយកបរាជ័យ AVA នឹងបង្ហាញសារកំហុសក្នុង panel នៅលើម៉ាស៊ីននេះ។

តារាង Funnel (ការធ្លាក់ចុះ និងពេលវេលាជំហាន)​

តារាង funnel បង្ហាញភាគរយនៃ session ដែលឈានដល់ជំហាននីមួយៗ។

  • Drop‑off ប្រៀបធៀបជំហាននីមួយៗទៅនឹងជំហានមុនវា។
  • Avg Stage Duration វាស់ពេលវេលាដែលចំណាយនៅក្នុង stage ចាប់ពី stage ចាប់ផ្តើមដល់ stage ជោគជ័យ។
  • Avg Time to Next Step វាស់ពេលវេលាពីជំហានជោគជ័យមួយទៅជំហានជោគជ័យបន្ទាប់។
  • កាត Slowest Step ប្រើ stage duration ជាមុន។
  • បើ AVA មិនមាន stage timing វានឹងប្តូរទៅប្រើ next-step duration។
  • បើជំហានក្រោយកើតឡើងមុនជំហានមុន នោះ duration ត្រូវបង្ហាញជា 0។

ប្រើកាត Biggest Drop‑Off ដើម្បីជ្រើសជំហានដែលត្រូវ coaching ជាមុនសិន។

ឧទាហរណ៍

បើ Document Upload មាន 60 session ហើយជំហានមុនមាន 100 នោះ drop‑off គឺ 40%។ បើ Document Upload ខ្លួនវាចំណាយ 20 វិនាទី Avg Stage Duration គឺ 20 វិនាទី។ បើ Document Upload បញ្ចប់នៅ 10:05 ហើយ Validation នៅ 10:07 នោះ Avg Time to Next Step គឺ 2 នាទី។

Checkout conversion ប្រើ milestones ដែលត្រូវការ​

ក្នុង Check‑Out, AVA គណនា conversion ពី checkout milestones ដែលត្រូវការ។

ដំណាក់កាលរបៀបដែល AVA ចាត់ទុក
Checkout StartedMilestone ចាប់ផ្តើមដែលត្រូវការពី FETCH_CHECKOUT
Bill Reviewedសកម្មភាពជាជម្រើស នៅពេលភ្ញៀវមើលវិក្កយបត្រ
Charges Confirmedសកម្មភាពជាជម្រើស នៅពេលភ្ញៀវបញ្ជាក់ charges
Checkout Paymentសកម្មភាពជាជម្រើស នៅពេលប្រមូល payment
Checkout CompleteMilestone ចុងក្រោយដែលត្រូវការពី CHECKOUT

ភ្ញៀវអាចទៅដោយផ្ទាល់ពី Checkout Started ទៅ Checkout Complete។ AVA រាប់ផ្លូវនេះថាបានបញ្ចប់ ជំនួសឱ្យបង្ហាញ drop-off មិនពិត។

ដំណាក់កាលជាជម្រើសដែលបានសង្កេតឃើញ បង្ហាញក្នុង Optional checkout activity។ វាមិនបន្ថយ conversion ឬបង្កើត transition បាត់បង់ពណ៌ក្រហមទេ។ Dashboard និងរបាយការណ៍ analytics ដែលអាចទាញយកបាន ប្រើច្បាប់ដំណាក់កាលដូចគ្នា។

AVA បង្ហាញ Checkout Payment នៅពេលសង្កេតឃើញសកម្មភាព checkout payment។ វារក្សា payment នៅក្រៅ funnel ដែលត្រូវការ ទោះ setting ដែលបានរក្សាទុកចាស់ក៏ដោយ។ វាមិនដាក់ស្លាក payment ដែលបាត់ថា not required ឬចាត់ទុកវាជាបរាជ័យទេ។

Direct PMS checkouts មើលទៅដូចការធ្លាក់ចុះ​

អ្វីដែលអ្នកឃើញ: ភ្ញៀវបានបញ្ចប់ checkout ក្នុង PMS ប៉ុន្តែរំលង bill ឬ payment stages។

ដំណោះស្រាយ:

  1. ជ្រើស Check‑Out ក្នុង Command Center → Analytics។

  2. ស្វែងរក Checkout Complete ជា required stage ចុងក្រោយ។

  3. ពិនិត្យ Optional checkout activity សម្រាប់ event របស់ bill, charge ឬ payment។

  4. ប្រៀបធៀប dashboard ជាមួយរបាយការណ៍ដែលអាចទាញយកបាន បើអ្នកត្រូវការច្បាប់ចម្លងដែលបានរក្សាទុក។

    ✓ Direct PMS checkouts ត្រូវបានរាប់ក្នុង final conversion។

មើល reservation ពី required-step drop-offs​

Required checkout drop-offs អាចមានសកម្មភាព View list។

  1. ជ្រើស Check‑Out ក្នុង Command Center → Analytics។
  2. ស្វែងរក transition របស់ required stage ដែលមានចំនួន drop-off។
  3. ចុច View list។
  4. ពិនិត្យ confirmation number, ឈ្មោះភ្ញៀវ, បន្ទប់ និងព័ត៌មាន failure ចុងក្រោយ។
  5. ចុច Download CSV ដើម្បីរក្សាទុក reservation ដែលបង្ហាញ។

AVA បង្ហាញ View list តែពេល session ដែលត្រូវគ្នាទាំងអស់ស្មើនឹងចំនួន drop-off ដែលបង្ហាញ។ បើ reservation mapping មិនពេញលេញ AVA នឹងលាក់សកម្មភាពនេះសម្រាប់ transition នោះ។

ពិនិត្យ checkout payments ដែលបរាជ័យ​

Payment បង្ហាញក្រោម Optional checkout activity នៅពេល AVA សង្កេតឃើញសកម្មភាព checkout payment។ វាអាចបង្ហាញ ទោះ setting payment ដែលបានរក្សាទុកចាស់ក៏ដោយ។ សកម្មភាព payment មិនដែលផ្លាស់ប្តូរការបញ្ចប់ checkout ឬ conversion របស់ required stage ទេ។

  1. ជ្រើស Check‑Out ក្នុង Command Center → Analytics។
  2. ស្វែងរក Payment ក្រោម Optional checkout activity។
  3. ចុច View failed reservations នៅពេលមាន payment បរាជ័យ។
  4. ពិនិត្យព័ត៌មាន reservation និង failure message។
  5. ចុច Download CSV ដើម្បីរក្សាទុក failure ដែលបង្ហាញ។

CSV មាន Confirmation number, Guest name, Room, Failure step និង Failure message។ AVA បង្ហាញ View failed reservations តែពេល payment ដែលបរាជ័យទាំងអស់អាចផ្គូផ្គងទៅ session បាន។

Successful Check-Outs បង្ហាញនៅថ្ងៃផ្សេង​

អ្វីដែលអ្នកឃើញ: Checkout ចាប់ផ្តើមនៅថ្ងៃមួយ ប៉ុន្តែ Successful Check‑Outs កើននៅថ្ងៃមួយទៀត។

ដំណោះស្រាយ:

  1. ពិនិត្យពេលដែល terminal checkout event ជោគជ័យ។

  2. ប្រៀបធៀប timestamp នោះជាមួយថ្ងៃប្រតិទិនមូលដ្ឋានរបស់សណ្ឋាគារ។

  3. ពិនិត្យ start date របស់ checkout នៅពេលប្រៀបធៀបការប៉ុនប៉ង ឬ funnel stages។

  4. Refresh tab Analytics បើ checkout ទើបបញ្ចប់។

    ✓ នេះជារឿងរំពឹងទុក នៅពេល checkout ឆ្លងកាត់ពាក់កណ្តាលអធ្រាត្រ ឬបញ្ចប់ក្រោយពេលពន្យារ។

ការវិភាគពេលវេលា (បរិមាណតាមម៉ោង)​

ការវិភាគពេលវេលាបង្ហាញការប៉ុនប៉ងដំណើរតាមម៉ោងក្នុង flow ដែលបានជ្រើស។ Reservation នីមួយៗរួមចំណែកសកម្មភាពជោគជ័យដំបូងរបស់វាក្នុង flow នោះ។

  • ប្លុកម៉ោងប្រើ timezone ដែលបានកំណត់សម្រាប់សណ្ឋាគាររបស់អ្នក។
  • Analytics response បញ្ជាក់វាដោយ timeAnalysis.timezone។
  • Offset timezone របស់ថ្ងៃដែលបានជ្រើសត្រូវបានអនុវត្ត រួមទាំងការផ្លាស់ប្តូរ daylight-saving។
  • ការប៉ុនប៉ង Pre‑Arrival ដែលមិនទាន់បញ្ចប់ ប៉ុន្តែបានកត់ត្រា ត្រូវបានរាប់ក្នុងចំនួនការប៉ុនប៉ងតាមម៉ោង។
  • ចំណងជើងក្រាហ្វ peak hours និង tooltips បង្ហាញពាក្យ attempts។
  • ការប៉ុនប៉ង checkout ប្រើសកម្មភាព checkout នៅពេល flow នោះមានសកម្មភាពផ្ទាល់ខ្លួន។
  • Metrics បញ្ចប់ Pre‑Arrival នៅតែត្រូវការ PRE_ARRIVAL ដែលជោគជ័យ។
  • បង្ហាញ Peak Hours និង Rush Periods ដើម្បីជួយក្នុងការរៀបចំបុគ្គលិក។

ប្រើ Peak Hours ដើម្បីរៀបចំ coverage សម្រាប់ប្លុកពេលដែលរវល់បំផុតរបស់អ្នក។

ឧទាហរណ៍

សម័យដែលជោគជ័យដំបូងនៅម៉ោង 7:10 តាម local time នឹងរាប់ក្នុងម៉ោង 07:00។

បញ្ហា (កំហុសថ្មីៗ)​

ផ្នែក Issues រាយ session ដែលមានជំហានបរាជ័យថ្មីបំផុត។

  • AVA ពិនិត្យ 10 events ចុងក្រោយសម្រាប់កំហុស។
  • បើគ្មានកំហុសថ្មីៗ វានឹងប្រើកំហុសថ្មីបំផុតដែលបានកត់ត្រាទុក។

ប្រើ View Details ដើម្បីមើលប្រវត្តិជំហានពេញលេញ។

ឧទាហរណ៍

បើការទូទាត់បរាជ័យនៅ 3:12 បន្ទាប់ពីជោគជ័យមុន នោះ issue នឹងបង្ហាញ Payment នៅ 3:12។ បើ 10 events ចុងក្រោយជោគជ័យទាំងអស់ AVA នឹងបង្ហាញកំហុសថ្មីបំផុតដែលបានកត់ត្រាទុក។

សកម្មភាពថ្មីៗ​

សកម្មភាពថ្មីៗ បង្ហាញជំហានសំខាន់ៗដែលបាន ជោគជ័យ ឬបរាជ័យ ដូចជា៖

  • Check‑In, Check‑Out
  • Room Assignment
  • Pre‑Registration
  • Identity Verification
  • Payment

បញ្ជីនេះកំណត់ត្រឹម 30 ធាតុចុងក្រោយប៉ុណ្ណោះ។

ប្រើបញ្ជីនេះ ដើម្បីបញ្ជាក់ថាជំហានណាខ្លះត្រូវបានបញ្ចប់ថ្មីបំផុត។ កាលបរិច្ឆេទ និងម៉ោងប្រើ timezone របស់សណ្ឋាគារដូចគ្នានឹងស្លាកកាលបរិច្ឆេទដែលបានជ្រើស។

ឧទាហរណ៍

អ្នកអាចឃើញ “Check‑In completed successfully” ឬសារ​បរាជ័យសម្រាប់ Identity Verification។

ការបែងចែកជំហានចុងក្រោយ (កន្លែងដែល session បញ្ចប់)​

តារាងនេះដាក់ជាក្រុមនូវជំហានចុងក្រោយរបស់ session នីមួយៗទៅតាមប្រភេទ៖

  • Success — ជំហានបញ្ចប់ពេញលេញ
  • Timing — ជំហាន early check-in (រួមទាំង Room Queued)
  • Partial — ការចុះឈ្មោះជាមុន
  • Room — ជំហានចាត់តាំងបន្ទប់ (Room Assignment)
  • Documentation — ការផ្ទៀងផ្ទាត់ឯកសារ ឬអត្តសញ្ញាណ
  • Payment — ជំហានទូទាត់
  • Early — ជំហាន Entry / Fetch

បើមានកំហុសកើតឡើង បន្ទាប់ ពីជោគជ័យចុងក្រោយ ជំហានបរាជ័យនោះនឹងក្លាយជាជំហានចុងក្រោយ។

ប្រើតារាងនេះ ដើម្បីមើលចំណុចដែលជាញឹកញាប់បញ្ឈប់ដំណើរការ។

ឧទាហរណ៍

ក្នុងចំណោម 50 session, 20 បញ្ចប់នៅ Check‑In (success), 10 នៅ Early Check‑In (timing), 8 នៅ Document Upload (documentation), និង 12 នៅ Payment (payment)។

បើក session ពីការបែងចែកជំហានចុងក្រោយ​

  1. ជ្រើស bar segment មួយក្នុង Final Step Distribution។

  2. ពិនិត្យបញ្ជី session ដែលបើកឡើង។

    ✓ បញ្ជីបង្ហាញលេខ confirmation, ភ្ញៀវ, បន្ទប់, និង failure ថ្មីបំផុត។

  3. ជ្រើស Open details លើ session ណាមួយ។

    ✓ ផ្ទាំង Reservation Details នឹងបើកសម្រាប់ session នោះ។

បញ្ជី session ប្រៀបធៀបនឹងការកក់

បញ្ជីនេះបង្ហាញ sessions មិនមែន reservations ដែលបានដាក់ជាក្រុមទេ។ ប្រើវាដើម្បីស្វែងរក failure កើតឡើងជាប់ៗយ៉ាងលឿន។

ការវិភាគឧបករណ៍ (ជាជម្រើស)​

ការវិភាគឧបករណ៍ ប្រើព័ត៌មាន device ពី session check‑in/out។

បើ session kiosk មិនមាន physical kiosk ID AVA នឹងបង្ហាញវាជា Unidentified kiosk។ វាធ្វើឱ្យ session នោះដាច់ដោយឡែកពីសកម្មភាព Guest device។

ស្លាក Unidentified kiosk មានន័យថាប្រភព session ត្រូវបានស្គាល់ ប៉ុន្តែបាត់ព័ត៌មាន metadata របស់ឧបករណ៍។ វាមិនមានន័យថាជាទូរសព្ទ ឬ tablet របស់ភ្ញៀវទេ។

Live analytics និង rollup analytics ប្រើការចាត់ថ្នាក់ kiosk ដូចគ្នា។

សម្គាល់ប្រភពបុគ្គលិកសម្រាប់ check-in ជំនួយ​

Session check-in ជំនួយតាម virtual បង្ហាញជាមួយ alias បច្ចុប្បន្នរបស់បុគ្គលិកក្នុងបញ្ជីប្រភព។ វាជួយឱ្យអ្នកសម្គាល់ថាបុគ្គលិកណាជាអ្នកគ្រប់គ្រង check-in ជំនួយនីមួយៗ។ Session ថ្មីៗពី kiosk បុគ្គលិក virtual របស់ Streamliner ត្រូវបានរាប់ជា Kiosk journeys។ វាលែងបង្ហាញជាប្រភព front-desk ឬ desktop ទៀតហើយ។

បើបុគ្គលិកប្តូរឈ្មោះ Analytics នឹងប្រើ alias ដែលបានកែប្រែ នៅពេលអ្នក refresh view។ ដំណើរចាស់ៗនៅតែរក្សាអត្តសញ្ញាណប្រភពដើមរបស់វា ហើយមិនចាំបាច់សរសេរឡើងវិញទេ។

បើប្រភពបង្ហាញ ID

AVA រក្សាទុក virtual-master ID ដើម នៅពេលសេវា alias មិនអាចប្រើបាន។ កំណត់ត្រា staff master ចាស់ដែលគ្មាន alias ក៏បង្ហាញ ID ដើមរបស់វាផងដែរ។

សម្គាល់ប្រភព kiosk ដែលបានរក្សាទុកក្នុងបណ្ណសារ​

Kiosk ដោយដៃ ឬ kiosk ដែលគ្រប់គ្រង ដែលត្រូវបានដកចេញ លែងបង្ហាញក្នុងបញ្ជីឧបករណ៍ CCI សកម្មទៀតហើយ។ ជួរ Analytics ប្រវត្តិសាស្ត្ររបស់វា នៅតែអាចបង្ហាញ alias របស់ kiosk ដែលបានរក្សាទុកក្នុងបណ្ណសារ។

Raw kiosk ID បង្ហាញនៅខាងក្រោម alias ដើម្បីឱ្យការផ្គូផ្គងឧបករណ៍មានភាពជឿជាក់។ ប្រសិនបើ kiosk ID មួយបង្ហាញក្នុងបញ្ជីទាំងពីរ AVA ប្រើ alias របស់ឧបករណ៍សកម្ម។ Alias ដែលបានរក្សាទុកក្នុងបណ្ណសារ បញ្ជាក់តែសកម្មភាពប្រវត្តិសាស្ត្រប៉ុណ្ណោះ វាមិនស្តារ kiosk ឡើងវិញទេ។ បណ្ណសារនេះមានតួនាទីសម្រាប់បង្ហាញតែប៉ុណ្ណោះ ដូច្នេះការកំណត់ kiosk សកម្មមិនអាចកែ alias ប្រវត្តិសាស្ត្របានទេ។

អានចំនួនសរុបនៃដំណើរតាមប្រភព​

ការវិភាគឧបករណ៍ចាត់ក្រុម session ជា Kiosk journeys និង Guest device journeys។ ប្រភពនីមួយៗបង្ហាញចំនួនដំណើរសរុប ដំណើរដែលជោគជ័យ និង completion rate របស់វា។

សារផ្ទៀងផ្ទាត់ប្រៀបធៀបប្រភពទាំងនេះជាមួយដំណើរ reservation តែមួយគត់របស់ dashboard។ ចំនួនត្រូវបានដកស្ទួនតាម reservation ដូច្នេះ session ដែលកើតឡើងម្តងហើយម្តងទៀតមិនបំប៉ោងចំនួនទេ។

សម្រាប់ check-in មានតែ event PMS CHECKIN ដែលជោគជ័យប៉ុណ្ណោះដែលរាប់ជាដំណើរជោគជ័យ។ Room assignment, key retrieval និង key encoding បង្ហាញវឌ្ឍនភាព មិនមែន check-in ដែលបានបញ្ចប់ទេ។

អ្វីដែលអ្នកឃើញអត្ថន័យ
Successful journeys out of total journeysការបញ្ចប់របស់ប្រភព និងភាគបែងរបស់វា
Unidentified kioskដំណើរដែលមានប្រភពពី kiosk ប៉ុន្តែគ្មាន metadata របស់ physical kiosk
ចំនួនសរុបតាមប្រភពត្រូវនឹង dashboardទិដ្ឋភាពទាំងពីរប្រើក្រុមដំណើរ reservation ដូចគ្នា

ប្រើទិដ្ឋភាពនេះ ដើម្បីប្រៀបធៀបការប្រើ kiosk និង mobile តាម OS។

ឧទាហរណ៍

បើ session ភាគច្រើនជា iOS អ្នកប្រហែលជាចង់បង្កើនប្រសិទ្ធភាពលំហូរ mobile check-in។

ដែនកំណត់ និងភាពទាន់សម័យនៃទិន្នន័យ​

  • Analytics គ្របដណ្តប់រហូតដល់ 92 ថ្ងៃប្រតិទិនជាប់គ្នា ក្នុងសំណើ date-only នីមួយៗ។
  • ត្រីមាសពេញត្រូវបានគាំទ្រ រួមទាំង July 1–September 30។
  • AVA ផ្ទៀងផ្ទាត់ date-only ranges តាមថ្ងៃប្រតិទិនមូលដ្ឋានរបស់សណ្ឋាគារ ដោយមិនពឹងលើការផ្លាស់ប្តូរ daylight-saving។
  • ពេលមាន daily rollups ចន្លោះធំៗនឹងផ្ទុកពីទិន្នន័យ rollup ជាមុន។
  • តម្រង CCI និង ACI ប្រើ daily rollup slices ដែលត្រូវគ្នា នៅពេលមាន។
  • Rollup ដែលបានរក្សាទុក រក្សាទុកភស្តុតាង event ដែល dashboard ប្រើ មិនមែនតែចំនួនសង្ខេបទេ។
  • លទ្ធផលរបស់ថ្ងៃនេះប្រើទិន្នន័យ live ជានិច្ច។
  • ទិន្នន័យដែលបានរក្សាទុកបាត់ មិនត្រូវគ្នា ឬមិនអាចប្រើបាន នឹងប្រើទិន្នន័យ live សម្រាប់អំឡុងពេលដែលពាក់ព័ន្ធ។
  • Date range ចាស់ៗដែលត្រងតាម mode អាចប្រើការគណនាផ្ទាល់ជាបណ្តោះអាសន្ន ខណៈ slices កំពុង refresh។
  • View Overall ដែលមិនត្រងអាចប្រើ rollup ចាស់ៗ ទោះគ្មាន mode slices ក៏ដោយ។
  • អចលនទ្រព្យដែលរវល់ខ្លាំងអាចត្រូវការចន្លោះតូចជាងមុន បើលទ្ធផលមានទំហំធំពេក។
  • បើ AVA ស្នើឱ្យអ្នកបង្រួម date range សូមកាត់បន្ថយរយៈពេល ហើយសាកល្បងម្តងទៀត។
  • សំណើដែលមានទំហំលើស នឹងត្រឡប់កំហុស ដោយគ្មានរបាយការណ៍មួយផ្នែក ឬ fallback ទិន្នន័យច្រើន។
  • បញ្ជី session ត្រូវបានកំណត់សម្រាប់ប្រសិទ្ធភាព (ប្រហែល 200 per step និង 2,000 total)។

ជ្រើស date range ដែលត្រឹមត្រូវសម្រាប់ Analytics​

ប៊ូតុង Date បង្ហាញកំណត់ Analytics មុនពេល AVA ផ្ទុកទិន្នន័យ។ ជ្រើសមិនលើស 92 ថ្ងៃប្រតិទិន ដោយរាប់ទាំងថ្ងៃចាប់ផ្តើម និងថ្ងៃបញ្ចប់។ វាអនុញ្ញាតឱ្យប្រើត្រីមាសប្រតិទិនពេញ រួមទាំង July 1–September 30។

អ្វីដែលអ្នកឃើញអត្ថន័យវិធីដោះស្រាយ
Analytics: up to 92 days, including full quartersRange របស់អ្នកត្រឹមត្រូវ។បន្តពិនិត្យរបាយការណ៍។
Select up to 92 calendar days...Range របស់អ្នកវែងជាងកំណត់ Analytics។បង្រួម range ឬពិនិត្យម្តងមួយត្រីមាស។

នៅពេល range មិនត្រឹមត្រូវ AVA មិនផ្ញើសំណើ Analytics ឬ missing-reservation ទេ។ កាលបរិច្ឆេទដែលបានជ្រើសនៅតែរក្សាទុក ដូច្នេះអ្នកអាចកែ range ដោយខ្លួនឯង។ Analytics នឹងដំណើរការឡើងវិញ បន្ទាប់ពី range ត្រឹមត្រូវ។ តម្រង Status ផ្សេងទៀតនៅតែប្រើឥរិយាបថ date-range ដដែល។

ដោះស្រាយបញ្ហា​

តារាងទាំងអស់បង្ហាញសូន្យ​

អ្វីដែលអ្នកឃើញ: Summary cards បង្ហាញ 0 ហើយតារាងទទេ។

ដំណោះស្រាយ៖

  1. ពង្រីក date range។
  2. បញ្ជាក់ថាមាន logs នៅក្នុង Status។
  3. ពិនិត្យថា plan របស់អ្នករួមបញ្ចូល Analytics។

Completion rate មើលទៅទាបជាងការរំពឹងទុក​

អ្វីដែលអ្នកឃើញ: Completion rate ទាប ទោះបីភ្ញៀវជាច្រើនបាន check in ក៏ដោយ។

ពិនិត្យ៖

  • Demo check-ins ត្រូវបានដកចេញ ដូច្នេះ sessions សាកល្បងមិនធ្វើឱ្យ Total Logs កើនឡើងទេ។
  • ការប៉ុនប៉ង PRE-only ដែលមិនទាន់បញ្ចប់ មិនរាប់ទៅ All Check‑Ins ទេ។
  • Session ដែលបញ្ចប់ pre-arrival ហើយបន្ទាប់មកបញ្ចប់ check-in នឹងបង្ហាញក្នុង view ពាក់ព័ន្ធទាំងពីរ។
  • Session ដែលចាប់ផ្តើម Pre‑Arrival ហើយបោះបង់ នឹងមានសិទ្ធិចូល Pre‑Arrival និងបន្ថយ completion rate របស់វា។
  • Session ដែលគ្រាន់តែបើកតំណ pre-arrival មិនមានសិទ្ធិទេ ប្រសិនបើគ្មានសកម្មភាព flow ដែលបានកត់ត្រា។
  • សម្រាប់ Check-In, ការបញ្ចប់ប្រើ PMS CHECKIN ដែលជោគជ័យ។
  • KEY_ENCODED ដាក់ session ក្នុង Full Check‑In ប៉ុន្តែមិនបញ្ចប់វាទេ។
  • Early Check‑In និង Pre‑Registration ត្រូវបានតាមដាននៅក្នុង sub-tabs ផ្ទាល់ខ្លួន។
  • Successful Check‑Ins រាប់ milestone PMS CHECKIN ដែលជោគជ័យ។
  • កំណត់ត្រាដែលមានតែ checkout និងសញ្ញា CHECKIN ចាស់ មិនរាប់ទេ បើគ្មានភស្តុតាងសកម្មភាព Check-In។
  • Room Access Delivery Rate អាចទាបជាង នៅពេល AVA មិនបានកត់ត្រា event access បន្ទាប់ពី check-in។

ចំនួនសរុបតាមប្រភពខុសពីរបាយការណ៍ចាស់​

អ្វីដែលអ្នកឃើញ: ចំនួនសរុប ឬ completion rate ក្នុងការវិភាគឧបករណ៍បានផ្លាស់ប្តូរបន្ទាប់ពីដាក់ឱ្យប្រើ។

ដំណោះស្រាយ:

  1. ប្រៀបធៀប date range ដូចគ្នានៅក្នុង Command Center → Analytics។

  2. អានសារផ្ទៀងផ្ទាត់នៅខាងក្រោមសេចក្តីសង្ខេបតាមប្រភព។

  3. ចាត់ទុក CHECKIN ជា event check-in ជោគជ័យតែមួយគត់។

  4. ទុកពេលឱ្យ analytics ចាស់ដែលបាន cache ធ្វើ refresh បន្ទាប់ពីដាក់ឱ្យប្រើ។

    ✓ ជួរដេកតាមប្រភពបច្ចុប្បន្ន ត្រូវបានផ្ទៀងផ្ទាត់ជាមួយដំណើរ reservation ស្តង់ដាររបស់ dashboard។

កាត coverage បាត់​

អ្វីដែលអ្នកឃើញ: អ្នកឃើញតែកាតសង្ខេបធម្មតា។

ដំណោះស្រាយ៖

  1. ស្នាក់នៅលើ Check-In។

  2. បញ្ជាក់ថាការភ្ជាប់ PMS សកម្ម។

  3. Refresh ទំព័របន្ទាប់ពី sync បញ្ចប់។

  4. បើ date range រវល់ សូម refresh ម្តងទៀតបន្ទាប់ពីពីរបីនាទី។

    ✓ បើ PMS របស់អ្នកគាំទ្រ reservation coverage, Eligible Check-In Units និង AVA Check-In Share នឹងបង្ហាញបន្ទាប់ពី Completion Rate។

កាត coverage នៅតែមិនផ្លាស់ប្តូរ​

អ្វីដែលអ្នកឃើញ: Eligible Check-In Units ឬ AVA Check-In Share នៅតែមើលទៅដូចដើមបន្ទាប់ពី refresh។

ដំណោះស្រាយ៖

  1. រង់ចាំមួយនាទី។
  2. Refresh tab Analytics ម្តងទៀត។
  3. បញ្ជាក់ថា date range ស្របនឹង PMS update ដែលអ្នករំពឹងទុក។
  4. បើនៅតែមិនត្រឹមត្រូវ សូមពិនិត្យថា PMS sync បានបញ្ចប់។

Time Analysis ប្រើម៉ោងមូលដ្ឋានខុស​

អ្វីដែលអ្នកឃើញ: Peak hours មិនត្រូវនឹងម៉ោងមូលដ្ឋានរបស់សណ្ឋាគារ។

ដំណោះស្រាយ៖

  1. ពិនិត្យតម្លៃ timeAnalysis.timezone ក្នុង analytics response។

  2. ប្រៀបធៀបប្លុកម៉ោងជាមួយ timezone ដែលបានកំណត់សម្រាប់សណ្ឋាគាររបស់អ្នក។

  3. ផ្ទៀងផ្ទាត់ timezone របស់សណ្ឋាគារនៅ Settings → Essentials → Hotel Basic Details។

  4. Refresh tab Analytics បន្ទាប់ពីប្តូរ timezone។

    ✓ ចំណងជើងក្រាហ្វ និងប្លុកម៉ោងគួរបង្ហាញ timezone របស់សណ្ឋាគារ។

Analytics នៅតែផ្ទុក ឬស្នើឱ្យបង្រួម range​

អ្វីដែលអ្នកឃើញ: tab Analytics បង្វិលយូរ បង្ហាញ timeout ឬស្នើឱ្យបង្រួម date range។

ហេតុអ្វីកើតឡើង: ចន្លោះដែលបានជ្រើសអាចមាន session លើសពី 20,000។ AVA បដិសេធសំណើដែលមានទំហំលើស មុនពេលបង្ហាញរបាយការណ៍។

ដំណោះស្រាយ:

  1. ជ្រើស date range តូចជាងមុន។

  2. Refresh tab Analytics ហើយសាកល្បងម្តងទៀត។

  3. បំបែករយៈពេលវែងទៅជារបាយការណ៍ដាច់ដោយឡែក។

  4. បើ date range តូចៗនៅតែបរាជ័យ សូមទាក់ទង support ជាមួយកាលបរិច្ឆេទដែលបានជ្រើស។

    ✓ ចន្លោះតូចៗគួរបញ្ចប់លឿនជាងមុន និងជួយបញ្ជាក់ថាបញ្ហាមកពីទំហំ range ឬភាពមានទិន្នន័យ។

បើមានតែ view ដែលត្រងតាម mode ផ្ទុកយឺត នោះ mode rollup slices ប្រវត្តិសាស្ត្ររបស់វាអាចកំពុង refresh។ សាកល្បង view Overall ដែលមិនបានត្រង ឬសាកល្បង view តាម mode ម្តងទៀតនៅពេលក្រោយ។

Analytics date range បង្ហាញ error​

អ្វីដែលអ្នកឃើញ: ប៊ូតុង Date ត្រូវបានសម្គាល់ថាមិនត្រឹមត្រូវ ហើយបង្ហាញសារអំពី 92 ថ្ងៃ។

វិធីដោះស្រាយ:

  1. រក្សាទុកថ្ងៃចាប់ផ្តើម ប្រសិនបើវាត្រឹមត្រូវ។

  2. ប្តូរថ្ងៃបញ្ចប់ រហូតដល់ range មាន 92 ថ្ងៃ ឬតិចជាងនេះ។

  3. សម្រាប់របាយការណ៍វែងជាងនេះ សូមបំបែករយៈពេលទៅជា range ទំហំមួយត្រីមាសៗ។

    ✓ AVA រក្សាទុកកាលបរិច្ឆេទដែលអ្នកបានជ្រើស រហូតដល់អ្នកកែវា។ ✓ Analytics ផ្ទុកដោយស្វ័យប្រវត្តិ បន្ទាប់ពី range ត្រឹមត្រូវ។

Analytics បង្ហាញជំហានពីថ្ងៃផ្សេង​

អ្វីដែលអ្នកឃើញ: ថ្ងៃដែលបានជ្រើសហាក់ដូចជារួមបញ្ចូលការបញ្ចប់ពីថ្ងៃប្រតិទិនផ្សេង។

ដំណោះស្រាយ:

  1. បញ្ជាក់ timezone របស់សណ្ឋាគារនៅ Settings → Essentials → Hotel Basic Details។
  2. ជ្រើស date range ឡើងវិញតាមថ្ងៃប្រតិទិនមូលដ្ឋានរបស់សណ្ឋាគារ។
  3. Refresh tab Analytics។
  4. បើលទ្ធផលនៅតែមិនត្រឹមត្រូវ សូមទាក់ទង support ជាមួយកាលបរិច្ឆេទដែលបានជ្រើស និង reservation number។

ការចម្លង MCP config បរាជ័យ​

អ្វីដែលអ្នកឃើញ: ប៊ូតុងបង្ហាញកំហុសបន្ទាប់ពីចុច Copy Codex MCP Config ឬ Copy Claude MCP Config។

ដំណោះស្រាយ៖

  1. ស្នាក់នៅលើ tab Analytics។
  2. សាកល្បងប៊ូតុង copy ម្តងទៀត។
  3. Refresh ទំព័រ ហើយសាកល្បងឡើងវិញ បើ token request អស់ពេល។
  4. បើកំហុសនៅតែមាន សូមទាក់ទង support ជាមួយសារពិតប្រាកដ។

ចម្លង config បាន ប៉ុន្តែ client មិនអាចភ្ជាប់​

អ្វីដែលអ្នកឃើញ: modal បើក ប៉ុន្តែ Codex ឬ Claude មិនផ្ទុក Streamliner server។

ដំណោះស្រាយ៖

  1. ពិនិត្យថាអ្នកបានបិទភ្ជាប់ config ទៅក្នុងឯកសារត្រឹមត្រូវ។
  2. បញ្ជាក់ថាតម្លៃ STREAMLINER_MCP_TOKEN នៅតែមាន។
  3. ចាប់ផ្តើម client ឡើងវិញទាំងស្រុង។
  4. ចម្លង config ថ្មី បើការរៀបចំចំណាយពេលយូរពេក។

ឧបករណ៍ Settings បាត់​

អ្វីដែលអ្នកឃើញ: client ភ្ជាប់បាន ប៉ុន្តែសកម្មភាព settings មិនបង្ហាញ។

ដំណោះស្រាយ៖

  1. ចម្លង config ថ្មីពី Analytics។
  2. ចាប់ផ្តើម client ឡើងវិញទាំងស្រុង។
  3. បញ្ជាក់ថា STREAMLINER_MCP_TOKEN ដែលបិទភ្ជាប់គឺជាថ្មីបំផុត។
  4. ដក Streamliner config block ចាស់ចេញ បើវានៅតែមាន។

ការសរសេរ Settings ផុតពេល​

អ្វីដែលអ្នកឃើញ: ការរក្សាទុក settings មើលទៅជាប់ ហើយត្រឡប់សារផុតពេល ឬ cancel។

ដំណោះស្រាយ៖

  1. ចម្លង config ថ្មីពី Analytics។

  2. ចាប់ផ្តើម client ឡើងវិញទាំងស្រុង។

  3. សាកល្បងការផ្លាស់ប្តូរ settings ម្តងទៀត។

  4. បើបរាជ័យម្តងទៀត សូមពិនិត្យថា token ឬ session អស់សុពលភាពឬអត់។

    ✓ ការអាប់ដេត settings ដែលត្រឹមត្រូវគួរបញ្ចប់ជំនួសឲ្យការជាប់។

ការផ្ទៀងផ្ទាត់បរាជ័យលើការសរសេរ Settings​

អ្វីដែលអ្នកឃើញ: អ្នកទទួលបាន authentication error ពេលរក្សាទុក merchant settings។

ដំណោះស្រាយ៖

  1. ចម្លង config ថ្មីពី Analytics។

  2. ចាប់ផ្តើម client ឡើងវិញទាំងស្រុង។

  3. សាកល្បងការផ្លាស់ប្តូរ settings ក្នុងសណ្ឋាគារដដែល។

  4. បើអ្នកបានប្ដូរសណ្ឋាគារ សូម refresh config បន្ទាប់ពីប្ដូរ។

    ✓ កំហុសថ្មីគួរតែប្រាប់ឲ្យអ្នកបង្កើត MCP config/token ថ្មី។

ការទាញយក PDF មិនចាប់ផ្តើម​

អ្វីដែលអ្នកឃើញ: អ្នកចុច Download report ប៉ុន្តែគ្មាន PDF ត្រូវបានទាញយក។

វិធីដោះស្រាយ:

  1. រង់ចាំរហូតដល់សេចក្តីសង្ខេប Analytics ផ្ទុករួច។
  2. សាកល្បង Download report ម្តងទៀត។
  3. បង្រួម date range បើរបាយការណ៍នៅតែផ្ទុកយឺត។
  4. ពិនិត្យថា browser របស់អ្នកអនុញ្ញាតការទាញយក។
  5. ទាក់ទង support បើ PDF នៅតែមិនអាចទាញយកបាន។

STB EVA export បាត់​

អ្វីដែលអ្នកឃើញ: អ្នកមិនឃើញរូបតំណាងទាញយកនៅក្រោម STB EVA submissions ទេ។

ដំណោះស្រាយ:

  1. ប្តូរទៅ Check-In។
  2. បញ្ជាក់ថា EVA ត្រូវបានបើកសម្រាប់ Singapore នៅ Settings → Check-in → Government Integration។
  3. Refresh ទំព័រ បន្ទាប់ពីទិន្នន័យ analytics ផ្ទុករួច។
  4. បើ panel នៅតែលាក់ date range ដែលបានជ្រើស អាចមិនរួមបញ្ចូល EVA submissions។

CSV export បរាជ័យ​

អ្វីដែលអ្នកឃើញ: អ្នកចុចរូបតំណាងទាញយក ប៉ុន្តែគ្មានឯកសារត្រូវបានទាញយក។

ដំណោះស្រាយ:

  1. សាកល្បងម្ដងទៀត បន្ទាប់ពី analytics summary ផ្ទុករួច។
  2. បង្រួម date range។
  3. ពិនិត្យថា browser របស់អ្នកអនុញ្ញាតការទាញយក។
  4. សាកល្បងម្ដងទៀត បន្ទាប់ពី local error បាត់។
  5. ទាក់ទង support បើការនាំចេញនៅតែបរាជ័យ។

Funnel reservation list បាត់​

អ្វីដែលអ្នកឃើញ: Required drop-off ឬ payment ដែលបរាជ័យ មិនមានសកម្មភាព list ទេ។

ដំណោះស្រាយ:

  1. បញ្ជាក់ថាបានជ្រើស Check‑Out និង date range ត្រឹមត្រូវ។
  2. ពិនិត្យថា transition មាន drop-off ឬ failed-payment count ដែលមិនមែនសូន្យ។
  3. Refresh tab Analytics បន្ទាប់ពីទិន្នន័យផ្ទុករួច។
  4. បើ mapping នៅតែមិនពេញលេញ សូមប្រើ Status ដើម្បីស្វែងរក reservation។

AVA លាក់សកម្មភាព list នៅពេលមិនអាចផ្គូផ្គងចំនួនដែលបង្ហាញទាំងអស់បានដោយសុវត្ថិភាព។

ចំនួនតាម mode មិនបូកស្មើគ្នា​

អ្វីដែលអ្នកឃើញ: ចំនួន Overall ខ្ពស់ជាងចំនួន CCI + ACI ជាក់លាក់។

ដំណោះស្រាយ:

  1. បញ្ជាក់ថាអ្នកបានជ្រើស date range និង metric ដូចគ្នានៅក្នុង view នីមួយៗ។

  2. ប្រើ Check-in Result → Successful Check-Ins សម្រាប់របាយការណ៍ការប្រើប្រាស់។

  3. ពិនិត្យថាអ្នកកំពុងប្រៀបធៀប Overall ជាមួយ CCI + ACI ឬអត់។

  4. ចងចាំថា ដំណើរដែលមាន mode ចម្រុះត្រូវបានរាប់តែម្តងក្រោម mode ដែលបានកំណត់ឱ្យវា។

  5. ប្រើ Funnel → Completed តែនៅពេលវាស់ conversion របស់ដំណើរប៉ុណ្ណោះ។

    ✓ CCI + ACI ជាក់លាក់ស្របនឹងដំណើរ CCI និង ACI ដែលបានកំណត់ mode។

ផ្ទាំងទូទាំងអចលនទ្រព្យបាត់​

អ្វីដែលអ្នកឃើញ: Metrics payment, EVA ឬ lost-key បាត់ពី Check-In → Analytics។

វិធីដោះស្រាយ:

  1. ជ្រើស view របាយការណ៍ CCI + ACI។

  2. បញ្ជាក់ថា date range ដែលបានជ្រើសរួមមានសកម្មភាពនោះ។

  3. Refresh tab Analytics បន្ទាប់ពីទិន្នន័យផ្ទុករួច។

  4. សម្រាប់ metrics EVA សូមបញ្ជាក់ថា EVA ត្រូវបានបើកសម្រាប់អចលនទ្រព្យរបស់អ្នក។

    ✓ CCI និង ACI mode slices លាក់ផ្ទាំងទូទាំងអចលនទ្រព្យដោយចេតនា។

នៅតែជាប់?​

ទាក់ទង success@vouch-technologies.com ប្រសិនបើ៖

  • ❌ Analytics បង្ហាញទិន្នន័យក្នុង Status ប៉ុន្តែ Analytics ទទេ
  • ❌ តារាងមិនអាប់ដេតក្រោយប្ដូរ date range
  • ❌ Issues បង្ហាញពេលវេលាមិនត្រឹមត្រូវ

ព័ត៌មានមានប្រយោជន៍ក្នុងការផ្ដល់៖

  • Date range ដែលអ្នកជ្រើស
  • រូបថតអេក្រង់ tab Analytics
  • លេខបញ្ជាក់នៃ reservation គំរូ