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

ស្វែងយល់អំពី 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 ធំៗផ្ទុកបានលឿនជាងមុន។ បើទិន្នន័យ rollup ខ្វះ ឬការហៅ rollup បរាជ័យ AVA នឹងត្រឡប់ទៅប្រើ live path វិញ។

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

ចន្លោះកាលបរិច្ឆេទធំៗនៅតែអាចចំណាយពេលផ្ទុកយូរ។ អចលនទ្រព្យដែលរវល់ខ្លាំងអាចត្រឡប់ error ទាមទារ date range តូចជាងមុន លឿនជាងការជាប់។ នេះអនុវត្តតែលើ tab Analytics ប៉ុណ្ណោះ។

សម័យសាកល្បង

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

មិនមានការទាញយករបាយការណ៍

តារាង Analytics សំខាន់ៗមិនមានប៊ូតុងទាញយក PDF តាម browser ទេ។ បញ្ជី 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 → Allការកក់ណាមួយដែលមានជំហាន flow នៃ check-in រួមទាំង KEY_ENCODED ប៉ុន្តែមិនរាប់តែ pre-arrivalCHECKIN, KEY_COLLECTION, ឬ GET_DOOR_LOCK_KEY
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_ENCODEDCHECKIN, KEY_COLLECTION, ឬ GET_DOOR_LOCK_KEY ជោគជ័យ
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។

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

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

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 ទេ។ សម្រាប់វា សូមប្រើ 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, Total Logs រាប់គ្រប់ session ដែលមានសកម្មភាពបានកត់ត្រា។ Completion Rate រាប់ session ដែលឈានដល់ PRE_ARRIVAL។ ឧទាហរណ៍ ការប៉ុនប៉ង 3 ដង និងបញ្ចប់ 2 ដង បង្ហាញ completion rate 66.7%។

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)​

កាតរបៀបគណនា
Total Logsចំនួន session ដែលមិនមែន Demo ក្នុង view ដែលបានជ្រើស
Completion Ratesession ដែលបានបញ្ចប់ ÷ logs ដែលមិនមែន Demo សរុប ដោយប្រើច្បាប់បញ្ចប់របស់ view
Avg Completion Timeពេលវេលាពីជំហានជោគជ័យដំបូង (ជាទូទៅ Entry) ដល់សញ្ញាបញ្ចប់ដែលបានកំណត់
Successful Check‑InsSession ខុសគ្នាដែលមាន milestone PMS CHECKIN ជោគជ័យ
Successful Check‑OutsSession checkout ខុសគ្នាដែលមាន terminal event ជោគជ័យ រាប់តាមកាលបរិច្ឆេទបញ្ចប់

ជួរឈរ Completion rule គ្រប់គ្រង Completion Rate និង Avg Completion Time។ វាមិនកំណត់ Successful Check‑Ins ទេ។

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

ឧទាហរណ៍

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

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

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

បំបែក 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 ជោគជ័យនោះ។

Completion Rate និង Avg Completion Time នៅតែប្រើ terminal ឬ room-access signals ដែលបានកំណត់។ វាបំបែកសមិទ្ធផលដំណើរចេញពី milestone របស់ PMS។

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

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

កាត 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 ច្រើនជាងមួយ។

ការកក់ 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។ វាគួរតែនៅតិចជាង ឬស្មើ 100%។

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

បើអ្នក 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 ខុសគ្នា។ 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 ឆ្លងកាត់ពាក់កណ្តាលអធ្រាត្រ ឬបញ្ចប់ក្រោយពេលពន្យារ។

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

ការវិភាគពេលវេលា ដាក់ session ជាក្រុមតាម ជំហានជោគជ័យដំបូង ក្នុង view ដែលបានជ្រើស។

  • ប្លុកម៉ោងប្រើ UTC ហើយ response បញ្ជាក់ timezone: UTC។ ពិនិត្យ timezone របស់សណ្ឋាគារ មុនប្រៀបធៀប peak ជាមួយការរៀបចំបុគ្គលិកមូលដ្ឋាន។
  • 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 ធាតុចុងក្រោយប៉ុណ្ណោះ។

ប្រើបញ្ជីនេះ ដើម្បីបញ្ជាក់ថាជំហានណាខ្លះត្រូវបានបញ្ចប់ថ្មីបំផុត។

ឧទាហរណ៍

អ្នកអាចឃើញ “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។

បើភ្ញៀវមិនបានផ្តល់ព័ត៌មាន device តារាងនេះអាចទទេ។

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

ឧទាហរណ៍

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

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

  • Analytics គ្របដណ្តប់រហូតដល់ 90 days ក្នុងមួយ query។
  • ពេលមាន daily rollups ចន្លោះធំៗនឹងផ្ទុកពីទិន្នន័យ rollup ជាមុន។
  • អចលនទ្រព្យដែលរវល់ខ្លាំងអាចត្រូវការចន្លោះតូចជាងមុន បើលទ្ធផលមានទំហំធំពេក។
  • បើ AVA ស្នើឱ្យអ្នកបង្រួម date range សូមកាត់បន្ថយរយៈពេល ហើយសាកល្បងម្តងទៀត។
  • បញ្ជី session ត្រូវបានកំណត់សម្រាប់ប្រសិទ្ធភាព (ប្រហែល 200 per step និង 2,000 total)។

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

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

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

ដំណោះស្រាយ៖

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

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

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

ពិនិត្យ៖

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

កាត 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 បានបញ្ចប់។

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

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

ហេតុអ្វីកើតឡើង: ចន្លោះធំៗត្រូវការពេលដំណើរការច្រើនជាងមុន។ អចលនទ្រព្យដែលរវល់ខ្លាំងក៏អាចឈានដល់ request limits លឿនជាងមុន។

ដំណោះស្រាយ:

  1. រង់ចាំរហូតដល់ 2 នាទីឱ្យសំណើបញ្ចប់។

  2. សាកល្បង date range តូចជាង ប្រសិនបើទំព័រនៅតែ timeout ឬស្នើឱ្យបង្រួម range។

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

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

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

ការចម្លង 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 ថ្មី។

Browser PDF download នៅតែបាត់​

អ្វីដែលអ្នកឃើញ: អ្នករំពឹងឃើញប៊ូតុង Download report ប៉ុន្តែមិនមាន។

ដំណោះស្រាយ៖

  1. នេះគឺជាអាកប្បកិរិយាដែលរំពឹងទុកនៅក្នុង tab Analytics បច្ចុប្បន្ន។
  2. ប្រើតារាង និងតម្រង date range លើអេក្រង់។
  3. ប្រើរូបតំណាងទាញយកសម្រាប់ STB EVA submissions បើអ្នកត្រូវការព័ត៌មាន submission។
  4. ទាក់ទង support បើអ្នកត្រូវការផ្លូវ export ផ្សេង។

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

ពិនិត្យតម្លៃ timeAnalysis.timezone ក្នុង analytics response។ ចាត់ទុកប្លុក UTC ជា UTC មិនមែនម៉ោងមូលដ្ឋានសណ្ឋាគារទេ ហើយប្រើ merchantTimezone ដើម្បីបម្លែងសម្រាប់ការរៀបចំបុគ្គលិក។

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

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

ដំណោះស្រាយ:

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

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 នៅពេលមិនអាចផ្គូផ្គងចំនួនដែលបង្ហាញទាំងអស់បានដោយសុវត្ថិភាព។

នៅតែជាប់?​

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

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

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

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