ข้ามไปยังเนื้อหาหลัก

ทำความเข้าใจ Analytics ของ Command Center

ตั้งค่าแบบรวดเร็ว

โรงแรมส่วนใหญ่ตรวจสอบ Completion Rate, Biggest Drop‑Off และ Issues ได้ภายใน 3 นาที

คู่มือนี้อธิบายวิธีที่ AVA คำนวณกราฟ Analytics แต่ละรายการใน Command Center รวมถึงการ์ดความครอบคลุมของ check-in และ check-out ตลอดจนการส่งออก STB EVA

ไปที่: Main Menu → Command Center → Analytics

โหลด Analytics ได้เร็วขึ้น

ขณะนี้ AVA อ่านแท็บนี้จาก daily rollups เพื่อให้ช่วงวันที่กว้างโหลดได้เร็วขึ้น มุมมอง Check-In ที่กรองตามโหมดใช้ส่วนข้อมูล rollup ของ CCI และ ACI แยกกัน หากไม่มีส่วนข้อมูลที่จำเป็นหรือการเรียก rollup ล้มเหลว AVA จะย้อนกลับไปใช้เส้นทางข้อมูลสด มุมมองที่ไม่กรองยังใช้ rollup ที่มีอยู่โดยไม่มีส่วนข้อมูลโหมดได้ AVA จะรีเฟรช daily rollup ที่ไม่สมบูรณ์หรือล้าสมัยโดยอัตโนมัติในเบื้องหลัง หลังการอัปเดต Analytics วันที่เก่าอาจโหลดช้าลงระหว่างที่การรีเฟรชนี้ทำงาน คุณไม่จำเป็นต้องทำ backfill ด้วยตนเอง

ช่วงวันที่ขนาดใหญ่ใช้เวลาโหลดนานขึ้น

ช่วงวันที่ขนาดใหญ่ยังอาจใช้เวลาโหลดนานกว่าเดิม ที่พักที่มีการใช้งานสูงอาจได้รับ error ช่วงวันที่แคบเร็วขึ้นแทนที่จะค้าง การทำงานนี้ใช้เฉพาะแท็บ Analytics คำขอ Analytics จำกัดไว้ที่ 20,000 session หากช่วงวันที่ของคุณเกินขีดจำกัดนี้ ให้ลดช่วงวันที่แล้วลองอีกครั้ง AVA จะปฏิเสธคำขอแทนการตัดทอนรายงานหรือโหลดข้อมูลเดิมผ่านเส้นทางอื่น

ช่วงวันที่เต็มไตรมาส

ช่วงวันที่ที่ระบุเฉพาะวันรองรับได้สูงสุด 92 วันปฏิทินแบบนับรวมวันเริ่มต้นและวันสิ้นสุด ซึ่งรวมไตรมาสเต็ม เช่น July 1–September 30 AVA ตรวจสอบตามวันปฏิทินท้องถิ่นของโรงแรม ดังนั้นการเปลี่ยนแปลงเวลาออมแสงจะไม่ลดขีดจำกัดนี้

เซสชันเดโม

เช็กอินเดโมยังแสดงใน Status และรายละเอียดการจอง แต่จะไม่นับในยอดรวม Analytics, จุดหลุด, การวิเคราะห์เวลา, ปัญหา หรือกิจกรรมล่าสุด

การดาวน์โหลดรายงาน

ใช้ Download report เพื่อบันทึกมุมมอง Analytics ปัจจุบันเป็น PDF AVA จะบีบอัด PDF ของรายงานโดยไม่ลดคุณภาพของภาพ ทำให้ไฟล์ดาวน์โหลดมีขนาดเล็กลง ไฟล์ที่ดาวน์โหลดจาก Overall จะมีคำว่า overall อยู่ในชื่อไฟล์ รายการการจองใน Funnel มีคำสั่ง Download CSV สำหรับการจองที่แสดงอยู่ เมื่อแผง STB EVA submissions ปรากฏ คุณสามารถใช้ไอคอนดาวน์โหลดเพื่อส่งออก CSV การส่งออกนี้ใช้แหล่งบันทึกการส่ง EVA เดียวกับยอดบนแดชบอร์ด

คัดลอก MCP config สำหรับ Codex หรือ Claude​

ตั้งค่าแบบรวดเร็ว

ใช้เวลาไม่ถึง 1 นาที โทเคนมีอายุสั้นและใช้เซสชันเบราว์เซอร์ปัจจุบันของคุณ

ใช้ปุ่มเหล่านี้เมื่อต้องการส่งข้อมูล Analytics ไปยังไคลเอนต์ AI โทเคนที่คัดลอกจะรวมขอบเขต Streamliner MCP แบบเต็มด้วย ไคลเอนต์ที่รองรับจะใช้เครื่องมือการตั้งค่าได้หลังจากรีสตาร์ต หลังจากคัดลอกแล้ว AVA จะแสดงโมดัลเฉพาะไคลเอนต์พร้อมคำแนะนำในการวาง

ปุ่มสิ่งที่คัดลอกเหมาะกับ
Copy Codex MCP ConfigMCP config แบบ TOML ที่มี mcp_servers.streamlinerCodex
Copy Claude MCP ConfigMCP config แบบ 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. อ่านคำแนะนำในโมดัลสำหรับไคลเอนต์ของคุณ

  5. วาง config ที่คัดลอกลงในไฟล์ config ของไคลเอนต์ AI

  6. รีสตาร์ตไคลเอนต์เพื่อให้โหลด MCP server ใหม่

    ✓ Claude config ใช้ JSON ✓ Codex config ใช้ TOML ✓ ทั้งสอง config มี STREAMLINER_MCP_TOKEN ที่มีอายุสั้น

Fresh tokens เท่านั้น

หากคุณคัดลอกโทเคนก่อนการเปลี่ยนแปลงนี้ ให้คัดลอก config ใหม่ โทเคนเก่าจะคงขอบเขตเดิมไว้จนกว่าคุณจะต่ออายุ

ตำแหน่งวางของแต่ละ config

Codex ใช้ ~/.codex/config.toml

Claude ใช้ config ของ Claude Desktop Developer ซึ่งโดยทั่วไปคือ claude_desktop_config.json

สิ่งที่โมดัลแสดง​

โมดัลยืนยันว่าคุณคัดลอก config สำเร็จ จากนั้นจะแสดงพาธไฟล์ ตำแหน่งวาง และขั้นตอนรีสตาร์ตสำหรับไคลเอนต์นั้น

หากใช้ Codex

  1. เปิด ~/.codex/config.toml บนเครื่องที่คุณใช้เรียกใช้ Codex

  2. วางบล็อก TOML ที่คัดลอกไว้ไว้ที่ระดับบนสุดของไฟล์

  3. บันทึกไฟล์ แล้วรีสตาร์ต Codex

    ✓ หากมี mcp_servers.streamliner อยู่แล้ว ให้แทนที่ส่วนนั้น

หากใช้ Claude Desktop

  1. เปิด Claude Desktop

  2. ไปที่ Settings → Developer → Edit Config

  3. วาง JSON ที่คัดลอกไว้ลงใน claude_desktop_config.json

  4. บันทึกไฟล์ ออกจาก Claude Desktop โดยสมบูรณ์ แล้วเปิดใหม่

    ✓ บน macOS โดยทั่วไปไฟล์อยู่ที่ ~/Library/Application Support/Claude/ ✓ หากมี mcpServers อยู่แล้ว ให้ผสานเฉพาะรายการ streamliner

สรุปอ้างอิง​

มุมมองสิ่งที่นับเป็นเซสชันกฎการเสร็จสมบูรณ์
Pre‑Arrivalการจองที่มีกิจกรรม Pre‑Arrival รวมถึงความพยายามที่ยกเลิกกลางคันและเส้นทางที่เช็กอินภายหลังPRE_ARRIVAL สำเร็จ
Check‑In → Overallการมาถึงที่เข้าเกณฑ์ใน PMS รวมถึงการจองที่ไม่เคยใช้ AVAยอดรวมการจองใน PMS และความครอบคลุมของ AVA
Check‑In → CCI + ACIการรวมเส้นทางที่ระบุว่าเป็น CCI หรือ ACI รวมความพยายามที่ยังไม่เสร็จและ KEY_ENCODED แต่ไม่รวมความพยายามแบบ PRE อย่างเดียวCHECKIN ของ PMS สำเร็จ
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 ของ PMS สำเร็จ
Check‑Outการจองใด ๆ ที่มีขั้นตอนเช็กเอาต์CHECKOUT หรือ COMPLETED_CHECKOUT_PAYMENT สำเร็จ

เปิด Analytics และเลือกมุมมอง​

Check-In/Out Analytics Dashboard

  1. ไปที่ Main Menu → Command Center

  2. เลือกแท็บ Analytics

  3. เลือก Pre‑Arrival, Check‑In หรือ Check‑Out

  4. หากเลือก Check‑In ให้ใช้แท็บย่อย 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)

    ✓ กราฟทั้งหมดจะอัปเดตตามมุมมองและช่วงวันที่นั้น

เลือกมุมมองรายงาน Check-In​

ใช้ Report view ใต้แท็บโฟลว์เพื่อเลือกกลุ่มการจองหรือโหมด check-in ตัวเลือกนี้จะแสดงเฉพาะเมื่อเลือก Check-In

ตัวกรองสิ่งที่รวมอยู่
Overallการมาถึงใน PMS ที่เข้าเกณฑ์ รวมการจองที่ไม่เคยใช้ AVA แต่ไม่รวมการจองที่ยกเลิกหรือไม่มาเข้าพัก
CCI + ACIเส้นทางที่ระบุว่าเป็น CCI หรือ ACI ไม่รวมความพยายามที่มีเฉพาะ Pre-Arrival และการเสร็จสมบูรณ์ที่ไม่ทราบโหมด
Self Check-In (CCI)การเช็กอินที่ระบุว่าเป็นโฟลว์บริการตนเองของ CCI
Assisted Check-In (ACI)การเช็กอินที่ระบุว่าเป็นโฟลว์ ACI ที่พนักงานช่วยดำเนินการ

  1. เลือก Check-In ใน Command Center → Analytics

  2. เลือก Overall, CCI + ACI, Self Check-In (CCI) หรือ Assisted Check-In (ACI)

  3. ตรวจสอบการ์ด funnel เวลา ปัญหา และผลลัพธ์ของอุปกรณ์ที่อัปเดตแล้ว

    ✓ โหมดที่เลือกจะยังคงใช้งานอยู่ขณะเปลี่ยนช่วงวันที่หรือแท็บย่อยของ check-in

AVA ระบุโหมดของ journey จากโหมดที่บันทึกไว้ในเหตุการณ์ CHECKIN ที่สำเร็จ สำหรับ journey ที่ยังไม่เสร็จสมบูรณ์ AVA ใช้โหมด check-in ที่ระบุไว้อย่างชัดเจนล่าสุด หาก journey เดียวใช้ทั้งสองโหมด เหตุการณ์ CHECKIN ที่สำเร็จจะมีลำดับความสำคัญสูงกว่า CCI + ACI ที่ระบุชัดเจนคือการรวม journey ที่ระบุว่าเป็น CCI และ ACI การเสร็จสมบูรณ์ที่ไม่ทราบโหมดจะไม่ปรากฏใน CCI + ACI ที่ระบุชัดเจน มุมมอง Overall อาจรวมกิจกรรม check-in ที่ไม่ถูกจัดประเภท วิธีนี้ทำให้ยอดที่กรองแล้วผูกกับโหมดที่ AVA บันทึกไว้จริง

Pre‑Arrival และ Check‑Out ยังคงเป็นมุมมองรวม ทั้งสองมุมมองไม่ใช้ตัวกรองโหมด Check-In ยอด CCI + ACI ที่ระบุชัดเจนควรสอดคล้องกับผลรวมของ journey CCI และ ACI ผลลัพธ์ Overall อาจแตกต่างกันเพราะรวมการมาถึงใน PMS และกิจกรรมที่ไม่ถูกจัดประเภท journey ที่ใช้หลายโหมดจะนับครั้งเดียวตามโหมดที่ระบุให้ journey นั้น

สำหรับรายงานการใช้งาน ให้ใช้ Check-in Result → Successful Check-Ins จำนวน Completed ใน Funnel ใช้วัดการเปลี่ยนผู้ใช้จากขั้นตอนหนึ่งไปยังอีกขั้นตอนหนึ่งของเส้นทางแทน จำนวนทั้งสองอาจแตกต่างกัน แม้ใช้โหมดและช่วงวันที่เดียวกัน

Analytics ที่กรองแล้ว

ผลลัพธ์ที่กรองตามโหมดใช้ไทม์ไลน์เหตุการณ์ที่บันทึกไว้สำหรับช่วงวันที่เลือก เมื่อมีส่วนข้อมูล rollup ของโหมด ช่วงวันที่กว้างจะโหลดจากส่วนข้อมูลเหล่านั้นก่อน วันที่เก่าอาจโหลดช้าลงจนกว่า daily rollup จะได้รับการรีเฟรช มุมมองที่กรองตามโหมดจะไม่แสดงตัวเลขความครอบคลุมการจอง PMS แบบรวม

ตรวจสอบยอดรวมการจอง PMS ใน Overall​

เลือก Overall เมื่อคุณต้องการประชากรการจองที่มาถึงทั้งหมดสำหรับ KPI การใช้งาน มุมมองนี้ใช้วันที่มาถึงใน PMS ไม่ใช่เฉพาะวันที่มีกิจกรรม AVA

สิ่งที่ต้องการเลือกสิ่งที่คาดว่าจะเห็น
การมาถึงที่เข้าเกณฑ์ทั้งหมดOverallรวมการจองที่ไม่เคยใช้ AVA
การใช้ AVA ตามโฟลว์ที่ระบุCCI + ACIรวมเฉพาะเส้นทางที่ระบุว่าเป็น CCI หรือ ACI
การใช้บริการตนเองSelf Check-In (CCI)รวมเส้นทางที่ระบุว่าเป็น CCI
การใช้บริการที่พนักงานช่วยAssisted Check-In (ACI)รวมเส้นทางที่ระบุว่าเป็น ACI

Overall ไม่รวมการจองที่ยกเลิกและการจองที่ไม่มาเข้าพัก ยอดรวมการจองใช้วันที่มาถึงใน PMS ที่เลือก เมตริกกิจกรรม check-in ใช้วันที่ของกิจกรรม มุมมองนี้อาจแสดงกิจกรรมที่ไม่ได้จัดประเภทและไม่มีการบันทึกโหมด CCI หรือ ACI

Compare like ด้วย like

ใช้ Overall สำหรับยอดรวมการจองและความครอบคลุมของ PMS ใช้ CCI + ACI สำหรับการใช้งาน AVA ตามเส้นทางที่ระบุโหมด อย่าเปรียบเทียบมุมมองเหล่านี้ราวกับใช้ตัวหารเดียวกัน

ตรวจสอบเมตริก Check-In ทั้งโรงแรม​

มุมมอง CCI + ACI แบบระบุโหมดจะรวมเมตริกที่คำนวณจาก journey ของ CCI และ ACI เมตริกเหล่านี้ไม่ได้แยกระหว่าง Self Check-In (CCI) และ Assisted Check-In (ACI)

เมตริกสิ่งที่รวมอยู่ปรากฏที่ใด
Analytics การชำระเงินกิจกรรมการชำระเงินของที่พักในช่วงวันที่เลือกมุมมอง CCI + ACI
การส่ง STB EVAความพยายามส่ง EVA ของที่พักในช่วงวันที่เลือกมุมมอง CCI + ACI เมื่อเปิดใช้ EVA
กิจกรรมกุญแจหายกิจกรรมกุญแจหายของที่พักในช่วงวันที่เลือกมุมมอง CCI + ACI

เลือก CCI + ACI เมื่อต้องการเมตริกของที่พักที่อิงเส้นทางซึ่งระบุโหมดเหล่านี้ เลือก Self Check-In (CCI) หรือ Assisted Check-In (ACI) เพื่อดูเฉพาะส่วนของ journey ที่ระบุโหมดนั้น

Why totals สามารถ differ

Funnel CCI + ACI นับ journey ที่ระบุว่าเป็น CCI หรือ ACI แผงข้อมูลระดับที่พักอาจรวมกิจกรรมนอกเหนือจาก journey ที่ระบุโหมดเหล่านั้นด้วย เช่น กิจกรรมการชำระเงินอาจรวมการชำระเงินระหว่าง Pre-Arrival ยอดเหล่านี้อาจไม่ตรงกัน และเป็นพฤติกรรมที่คาดไว้

ตรวจสอบรายงานสัญชาติผู้เข้าพัก​

ส่วน Guest Nationality ซึ่งเป็นตัวเลือกจะแสดงกลุ่มผู้เข้าพักที่ดำเนินการเสร็จสมบูรณ์ แยกตามสัญชาติ ส่วนนี้อาจปรากฏทั้งใน Analytics แบบสดและผลลัพธ์ Analytics ที่อ้างอิง rollup

Flowผู้เข้าพักที่รวมอยู่กฎการจบ
Pre-Arrivalผู้เข้าพักที่ทำกิจกรรม Pre-Arrival เสร็จกิจกรรม PRE_ARRIVAL สำเร็จ
Check-Inผู้เข้าพักที่ทำมุมมอง Check-In ที่เลือกเสร็จกิจกรรม PMS CHECKIN สำเร็จ
Check-Outผู้เข้าพักที่ผูกกับการจอง Check-Out ของ AVA ที่เสร็จสมบูรณ์การดำเนินการ Check-Out ของ AVA เสร็จสมบูรณ์

  1. เปิด Main Menu → Command Center → Analytics

  2. เลือก Pre-Arrival, Check-In หรือ Check-Out

  3. เลือกช่วงวันที่ตามเขตเวลาท้องถิ่นของโรงแรม

  4. เลือก All, Completed หรือ In Progress เมื่อมีตัวกรองแสดงขึ้น

  5. ตรวจสอบจำนวนและเปอร์เซ็นต์สัญชาติใน Guest Nationality

    ✓ ผู้เข้าพักที่ระบุสัญชาติได้จะถูกนับหนึ่งครั้งต่อการเข้าพักและ flow

กรองผู้เข้าพักที่เสร็จสมบูรณ์และยังไม่เสร็จสมบูรณ์​

ใช้ตัวกรองภายใน Guest Nationality เพื่อเปลี่ยนกลุ่มผู้เข้าพัก

ตัวกรองสิ่งที่แสดง
Allผู้เข้าพักทั้งในกลุ่มที่เสร็จสมบูรณ์และยังไม่เสร็จสมบูรณ์
Completedผู้เข้าพักที่ดำเนินโฟลว์ที่เลือกเสร็จสมบูรณ์
In Progressผู้เข้าพักที่มีกิจกรรมของโฟลว์บันทึกไว้ แต่ยังไม่เสร็จสมบูรณ์ภายในวันสิ้นสุดรายงาน

ตัวกรองมีผลเฉพาะกับ Guest Nationality ตัวกรองจะคงโฟลว์ ช่วงวันที่ และมุมมองรายงาน Check-In ที่เลือกไว้ ตัวกรองจะไม่โหลดแดชบอร์ด Analytics ใหม่หรือเปลี่ยนการ์ดอื่น

เมื่อมีข้อมูล CCI ที่ยังไม่เสร็จสมบูรณ์ ระบบจะเลือก All เป็นค่าเริ่มต้น การตอบกลับแบบเก่าที่ไม่มีข้อมูลดังกล่าวจะยังใช้พฤติกรรมเฉพาะผู้เข้าพักที่เสร็จสมบูรณ์ ในการตอบกลับเหล่านั้น Completed จะเป็นกลุ่มที่เลือกได้

✓ สลับตัวกรองเพื่อเปรียบเทียบสัญชาติที่บันทึกไว้ก่อนและหลังโฟลว์เสร็จสมบูรณ์

ทำความเข้าใจกิจกรรมสัญชาติที่ยังไม่เสร็จสมบูรณ์​

In Progress รวมผู้เข้าพักที่ระบุได้และมีกิจกรรมการลงทะเบียน เอกสาร หรือลายเซ็นที่บันทึกไว้ ผู้เข้าพักไม่จำเป็นต้องทำทุกขั้นตอนในโฟลว์ที่เลือกให้เสร็จ ผู้เข้าพักต้องไม่มีการเสร็จสมบูรณ์ที่สำเร็จภายในวันสิ้นสุดรายงาน

AVA ประเมินกิจกรรมที่ยังไม่เสร็จสมบูรณ์ ณ วันสิ้นสุดรายงาน การเสร็จสมบูรณ์หรือการอัปเดตรายละเอียดผู้เข้าพักในภายหลังจะไม่ลบกิจกรรมในอดีตนั้น วิธีนี้ทำให้รายงานในอดีตคงที่เมื่อเปรียบเทียบช่วงการดำเนินงานต่างกัน

All รวมกลุ่มที่เสร็จสมบูรณ์และ In Progress โดยไม่นับผู้เข้าพักคนเดิมซ้ำ ยอดรวมหลักของ Analytics ยังคงอิงการเสร็จสมบูรณ์ เฉพาะส่วน Guest Nationality เท่านั้นที่เพิ่มผู้เข้าพักซึ่งยังไม่เสร็จสมบูรณ์

สัญชาติไม่ทราบ

ผู้เข้าพักที่ยังไม่เสร็จสมบูรณ์อาจอยู่ภายใต้ Unknown เมื่อ AVA ไม่มีข้อมูลสัญชาติที่ใช้งานได้ AVA อาจเติมค่าที่เป็น Unknown ในภายหลังเมื่อหลักฐานจากการเข้าพักเดียวกันชัดเจนและไม่กำกวม การจับคู่ผู้เข้าพักที่กำกวมจะยังไม่ถูกนำไปกำหนดสัญชาติ

กราฟสัดส่วนแสดงสัญชาติที่ระบุชื่อได้ห้าอันดับแรก สัญชาติที่ระบุชื่อได้ที่เหลือจะถูกรวมเป็น Other nationalities ผู้เข้าพักที่ไม่มีสัญชาติที่ใช้งานได้จะแยกอยู่ในกลุ่ม Unknown แท่งกราฟใช้ผู้เข้าพักที่นับได้ทั้งหมดเป็นสเกล 100%

ตารางจะแสดงห้าแถวในตอนแรก เลือก Show all เพื่อแสดงสัญชาติทั้งหมด และเลือก Show less เพื่อย่อกลับ ปุ่มสลับนี้มีผลเฉพาะมุมมองรายงานที่เลือก

Pre-Arrival ยังคงแยกจากกิจกรรม CCI หรือ ACI ที่เกิดภายหลัง กิจกรรม CCI หรือ ACI โดยตรงจะไม่เพิ่มผู้เข้าพักเข้า cohort ของ Pre-Arrival ผลลัพธ์ Check-In จะเป็นไปตามมุมมอง Overall, CCI + ACI, Self Check-In (CCI) หรือ Assisted Check-In (ACI) ที่เลือก การเข้าพักซ้ำยังคงแยกกันเมื่อวันที่เข้าพักหรือระเบียนยืนยันแตกต่างกัน ระเบียนห้องที่เกี่ยวข้องจะถูกรวมเมื่อเป็นการเข้าพักเดียวกัน

AVA จะให้ความสำคัญกับสัญชาติที่บันทึกไว้ใน snapshot ตอนเสร็จสมบูรณ์หรือในระเบียนผู้เข้าพัก ระบบปรับรหัสสัญชาติที่รองรับให้อยู่ในรูปแบบมาตรฐานก่อนจัดกลุ่มผลลัพธ์ AVA จะไม่อนุมานสัญชาติจากประเทศผู้ออกเอกสาร ผู้เข้าพักที่ไม่มีสัญชาติที่ใช้งานได้จะแสดงอยู่ภายใต้ Unknown การเสร็จสมบูรณ์แบบหลายผู้เข้าพักจากข้อมูลเดิมที่กำกวมจะแสดงในจำนวนการมีส่วนร่วมที่กำกวมแยกต่างหาก

การดาวน์โหลด PDF จะรวมทุกแถวสัญชาติ แม้ตารางแบบสดจะถูกย่ออยู่ ข้อมูลสรุป Analytics และการตอบกลับ MCP จะคงรายละเอียดสัญชาติทั้งหมดไว้

อ่านข้อมูลที่หายไปให้ถูกต้อง

ส่วนที่ไม่พร้อมใช้งานหมายความว่าการค้นหาสัญชาติล้มเหลวหรือเกินขีดจำกัดที่ปลอดภัย ไม่ใช่รายงานที่มีผู้เข้าพักเป็นศูนย์ รายงานนี้ครอบคลุมกิจกรรม AVA ที่เสร็จสมบูรณ์ ไม่ใช่จำนวนผู้เข้าพักทั้งหมดใน PMS

จำนวนสัญชาติผู้เข้าพักต่ำกว่าที่คาด​

สิ่งที่เห็น: รายงานสัญชาติมีผู้เข้าพักน้อยกว่ารายงานจำนวนผู้เข้าพักใน PMS

วิธีแก้:

  1. ยืนยัน flow และช่วงวันที่ที่เลือก
  2. ตรวจสอบว่าผู้เข้าพักทำกิจกรรม AVA ที่จำเป็นเสร็จแล้ว
  3. ตรวจสอบจำนวนในกลุ่ม Unknown และจำนวนที่ไม่ได้ระบุแหล่งที่มา
  4. โปรดจำไว้ว่า AVA นับผู้เข้าร่วมที่ทำเสร็จ ไม่ใช่ผู้เข้าพักใน PMS ทุกคน
  5. ติดต่อฝ่ายสนับสนุนหากยังมีผู้เข้าพักที่ทำเสร็จแล้วหายไป

รายงานสัญชาติผู้เข้าพักไม่พร้อมใช้งาน​

สิ่งที่เห็น: ส่วน Guest Nationality แสดง Unavailable

วิธีแก้:

  1. รีเฟรช Command Center → Analytics หนึ่งครั้ง

  2. ลดช่วงวันที่หากครอบคลุมหลายเซสชัน

  3. ยืนยันว่า flow ที่เลือกมีกิจกรรม AVA ที่เสร็จสมบูรณ์

  4. ลองอีกครั้งหลังการรีเฟรช rollup เสร็จสิ้น

  5. ติดต่อฝ่ายสนับสนุนหากส่วนนี้ยังไม่พร้อมใช้งาน

    ✓ อย่าถือว่ารายงานที่ไม่พร้อมใช้งานมีผลลัพธ์เป็นศูนย์

ใช้ช่วงวันที่ตามเวลาท้องถิ่นของโรงแรม​

Analytics ใช้เขตเวลาที่กำหนดไว้ของโรงแรมเมื่ออ่านช่วงวันที่เลือก ระบบกรอง session ตามเวลาประทับของกิจกรรม check-in และ check-out ไม่ใช่เวลาที่อัปเดตการจอง เฉพาะขั้นตอนที่อยู่ในช่วงเวลาท้องถิ่นนั้นเท่านั้นที่นำไปคำนวณกราฟและผลการเสร็จสมบูรณ์ของวันนั้น การอัปเดตการจองภายหลังไม่สามารถเพิ่มขั้นตอนการเสร็จสมบูรณ์ในอดีตหรืออนาคตให้กับ Analytics ของวันนั้น การ์ด Successful Check‑Outs เป็นข้อยกเว้น โดยใช้วันที่เสร็จสมบูรณ์ของเหตุการณ์ปลายทาง

เปรียบเทียบตามวันทำการท้องถิ่น

เลือกวันที่ตามวันปฏิทินของโรงแรม แม้คุณจะตรวจสอบ Analytics จากเขตเวลาอื่น

AVA สร้าง session อย่างไร​

  • session คือระเบียน check-in ของการจองหนึ่งรายการ ไม่ใช่แขกแต่ละคน
  • session จะถูกนับเมื่อมีอย่างน้อยหนึ่งขั้นตอนจากมุมมองนั้นถูกบันทึก
  • Demo-tagged เซสชัน คือ excluded จาก these Analytics charts.
  • ขั้นตอนที่ล้มเหลวยังถูกนับรวมในยอด เพื่อให้เห็นจุดหลุดและปัญหา
Pre‑Arrival แยกต่างหาก

session ที่ไปถึงเพียง Pre‑Arrival จะ ไม่รวมอยู่ใน All Check‑Ins ใช้ ของ Pre‑Arrival มุมมอง สำหรับ those เซสชัน. หากแขกทำ pre-arrival เสร็จ แล้วทำ check-in บนอุปกรณ์ต่อ AVA จะรวม session นั้นในทั้งสองมุมมอง ความพยายาม Pre‑Arrival ที่ถูกละทิ้งยังปรากฏในมุมมอง Pre‑Arrival หลังจากแขกเริ่ม flow แล้ว

เมื่อแขกดำเนินการต่อหลัง pre-arrival​

มุมมอง Pre‑Arrival เป็นกลุ่มตามการเข้าร่วม ไม่ใช่หมวดหมู่เฉพาะ session หนึ่งรายการสามารถอยู่ทั้งในกลุ่ม Pre‑Arrival และ Check‑In session มีคุณสมบัติทันทีที่เริ่มมีกิจกรรม Pre‑Arrival แม้แขกจะละทิ้ง flow การไปถึง PRE_ARRIVAL ถือว่า session เสร็จสมบูรณ์ การเปิดลิงก์ pre-arrival โดยไม่มีการบันทึกกิจกรรมของ flow จะไม่ทำให้ session มีคุณสมบัติ การตรวจพบ milestone ของ full check-in ยังคงทำให้ session นั้นอยู่ในยอด Check‑In ที่ถูกต้อง

กิจกรรมของผู้เข้าพักมุมมอง Analytics
ผู้เข้าพักเปิดลิงก์โดยไม่มีกิจกรรมโฟลว์ที่บันทึกไว้ไม่รวมใน Pre‑Arrival
ผู้เข้าพักเริ่ม Pre‑Arrival แต่ละทิ้งไว้Pre‑Arrival ไม่สมบูรณ์
ผู้เข้าพักทำ pre-arrival เสร็จเท่านั้นPre‑Arrival เสร็จสมบูรณ์
ผู้เข้าพักทำ pre-arrival เสร็จ แล้วทำ check-in บนอุปกรณ์เสร็จPre‑Arrival และ Check‑In

วิธีนี้ทำให้ mixed การเดินทาง visible ใน both relevant cohorts. Pure pre-arrival การเดินทาง remain excluded จาก All Check‑Ins.

สำหรับ Pre‑Arrival, Total Logs นับทุก session ที่มีกิจกรรมบันทึกไว้ Completion Rate นับ session ที่ไปถึง PRE_ARRIVAL ตัวอย่างเช่น ความพยายามสามครั้งและเสร็จสมบูรณ์สองครั้งจะแสดงอัตรา 66.7% ดังนั้นความพยายามที่ถูกละทิ้งจะลดอัตราและทำให้เห็นจุดหลุดของ flow

เมื่อแขกทำ Pre‑Arrival เสร็จ แล้วเริ่ม journey CCI หรือ ACI ที่ยังไม่เสร็จสมบูรณ์ ความพยายาม check-in นั้นยังคงอยู่ในยอด check-in ตามโหมดที่ระบุ กิจกรรม Pre‑Arrival ล้วนยังคงไม่รวมใน All Check‑Ins

Rollup ย้อนหลัง

Previously saved daily rollups สามารถ retain การเสร็จสมบูรณ์-based Pre‑Arrival นับ until AVA recomputes them. รายการใหม่ computed rollups รวม abandoned attempts ใน ของ denominator.

เมื่อการเข้ารหัสกุญแจเป็นขั้นตอนสุดท้ายที่บันทึก​

AVA ถือว่า KEY_ENCODED เป็นสัญญาณจัดประเภท Full Check-In ใช้แม้ session จะไม่มีขั้นตอน KEY_COLLECTION หรือ KEY_RETRIEVED session จะแสดงใน Full Check-In และ All Check-Ins

KEY_ENCODED ไม่นับเป็น milestone การเสร็จสมบูรณ์สำหรับ Completion Rate ดังนั้น session อาจเพิ่มยอด Full Check-In โดยไม่เพิ่มจำนวน session ที่เสร็จสมบูรณ์

อัตราการเสร็จสมบูรณ์อาจเปลี่ยนแปลง

ที่พักที่ใช้การเข้ารหัสคีย์การ์ดอาจเห็นอัตราการเสร็จสมบูรณ์ของ Full Check-In ต่ำลงเล็กน้อย กรณีนี้เกิดขึ้นเมื่อ session จบที่ KEY_ENCODED โดยไม่มี milestone การเสร็จสมบูรณ์อื่น

การ์ดสรุป (ด้านบนของแท็บ)​

ในมุมมอง Check-In AVA จะแสดง AVA Reservation Coverage, Check-in Result และ Room Access Delivered ให้สอดคล้องกัน การ์ดเหล่านี้ตอบคำถามด้านการปฏิบัติงานที่แตกต่างกัน

ในมุมมอง Pre-Arrival AVA จะแสดงการ์ด Pre-Arrival Result เหนือ funnel การ์ดนี้รายงานกิจกรรมที่บันทึกไว้ในช่วงเวลาที่เลือก

การ์ดสิ่งที่บอกคุณวิธีคำนวณ
AVA Reservation Coverageจำนวนการจองที่มาถึงและเข้าเกณฑ์ซึ่งเริ่ม check-in กับ AVAยูนิตที่ AVA ประมวลผล ÷ ยูนิตที่มาถึงและเข้าเกณฑ์
Check-in Resultระบบโรงแรมยืนยันการ check-in ของผู้เข้าพักหรือไม่PMS CHECKIN ที่สำเร็จ ÷ ความพยายาม check-in ของ AVA
Pre-Arrival Resultผู้เข้าพักทำ Pre-Arrival เสร็จหลังเริ่มต้นหรือไม่การจอง Pre-Arrival ที่เสร็จ ÷ ความพยายาม Pre-Arrival
Room Access DeliveredAVA บันทึกการส่งมอบสิทธิ์เข้าห้องหลัง check-in หรือไม่การส่งมอบที่บันทึกไว้ ÷ ความพยายาม check-in ที่เข้าเกณฑ์

The การ์ด make ความครอบคลุม, โรงแรม check-ใน, และ room access visible as separate outcomes. A สำเร็จ Check-ใน Result does ไม่ confirm room access delivery.

The Check-ใน Result การ์ด asks, “Did AVA record that ของ แขก completed โรงแรม check-ใน?” The Room Access Delivered การ์ด asks, “Did AVA record room access being delivered?” สำหรับ example, a keycard encoding เหตุการณ์ สามารถ provide room access evidence.

เลือก ของ information button beside a metric ไปยัง open its detailed explanation. คุณสามารถ focus และ open these explanations ด้วย a keyboard. The explanation stays visible เมื่อ ของ ความครอบคลุม การ์ด clips its contents. บนหน้าจอแคบ AVA keeps ของ explanation within ของ screen edges. It repositions while you scroll หรือ resize ของ window. กด Escape to close an open explanation.

อ่านการ์ดทั้งสามร่วมกัน

ใช้ AVA Reservation Coverage ไปยัง measure AVA adoption among arrivals. ใช้ Check-ใน Result ไปยัง confirm ของ PMS check-ใน outcome. ใช้ Room Access Delivered ไปยัง find access deliveries needing follow-up.

อ่านการ์ด Pre-Arrival Result​

การ์ด combines ของ การเสร็จสมบูรณ์ อัตรา, completed การจอง, attempts, และ average การเสร็จสมบูรณ์ เวลา.

เมตริกสิ่งที่แสดงวิธีอ่าน
Completion Rateเปอร์เซ็นต์การเสร็จของ Pre-Arrivalการจองที่เสร็จ ÷ ความพยายาม Pre-Arrival
Completedการจองที่ถึงขั้นตอน PRE_ARRIVALการทำ Pre-Arrival สำเร็จในช่วงกิจกรรมที่เลือก
Avg Completion Timeเวลาเฉลี่ยตั้งแต่ขั้นตอนแรกที่สำเร็จถึง PRE_ARRIVALระยะเวลาที่ journey ของ Pre-Arrival ที่เสร็จใช้

Pre-Arrival uses AVA attempts และ completions จาก ของ ที่เลือก กิจกรรม period. It does ไม่ use PMS arrival หรือ departure ความครอบคลุม totals. Arrival dates may fall outside ของ ที่เลือก period. A แขก who later completes CCI หรือ ACI remains ใน ของ Pre-Arrival cohort.

เปรียบเทียบ cohort ที่ถูกต้อง

ใช้ Pre-Arrival Result ไปยัง measure แขก preparation กิจกรรม. ใช้ AVA Reservation Coverage สำหรับ PMS arrival ความครอบคลุม ใน ของ Check-In มุมมอง. ใช้ AVA Departure Coverage สำหรับ PMS departure ความครอบคลุม ใน ของ Check-Out มุมมอง.

CardHow it is calculated
Total LogsNumber of non-demo sessions in the selected view
Completion RateCompleted sessions ÷ total non-demo logs, using the selected view's completion rule
Avg Completion TimeTime from the first successful step (usually Entry) to the configured completion signal
Successful Check‑InsDistinct sessions with a successful PMS CHECKIN milestone. This supports the Check-in Result outcome.
Room Access Delivery RateSuccessful room-access deliveries after PMS CHECKIN ÷ all eligible check-in attempts. This supports Room Access Delivered.
Successful Check‑OutsDistinct checkout sessions with a successful terminal event, attributed to the completion date

Room Access Delivered ปรากฏ เมื่อ AVA has room-access delivery ข้อมูล สำหรับ ของ ที่เลือก check-ใน มุมมอง. การ์ด ปรากฏ เมื่อ your โรงแรม uses AVA-managed room-access delivery. รายการนี้ รวม smart locks, lockers, และ configured non-manual keycards. การ์ด เท่านั้น นับ delivery เหตุการณ์ recorded by AVA after สำเร็จ PMS CHECKIN. Manual หรือ external delivery remains excluded จาก this metric.

เงื่อนไขการส่งมอบ

AVA uses ของ Room Access configuration ไปยัง decide whether delivery applies. Analytics does ไม่ require you ไปยัง classify each lock, locker, หรือ keycard method. หาก delivery คือ unavailable หรือ manual, AVA hides ของ optional การ์ด.

สำหรับ Check-In มุมมอง, Completion Rate uses สำเร็จ PMS CHECKIN as ของ primary การเสร็จสมบูรณ์ stage. คอลัมน์ Completion rule ยังใช้ควบคุม Avg Completion Time ด้วย It does ไม่ define Successful Check‑Ins หรือ Room Access Delivery Rate.

ใช้ this table ไปยัง confirm which เซสชัน count as เสร็จสมบูรณ์ before you compare periods.

Successful Check-Outs ใช้วันที่เสร็จสมบูรณ์​

The Successful Check‑Outs การ์ด นับ each unique checkout that reaches a สำเร็จ terminal เหตุการณ์. AVA attributes ของ count ไปยัง ของ โรงแรม's local calendar วันที่ เมื่อ checkout succeeds. Checkout attempts, funnel stages, Completion Rate, และ Avg Completion Time keep their start-วันที่ attribution.

สำหรับ example, a checkout that starts Monday และ succeeds Tuesday ปรากฏ ใน Tuesday's Successful Check‑Outs. Its attempt และ funnel กิจกรรม remains ใน Monday's checkout analytics.

วิธีนี้ทำให้ สำเร็จ departures aligned ด้วย ของ day they completed.

ตัวอย่าง

หาก Total Logs คือ 40 และ 28 เซสชัน reach ของ configured การเสร็จสมบูรณ์ signal, ของ การเสร็จสมบูรณ์ อัตรา คือ 70%. Successful Check‑Ins may แสดง a แตกต่าง จำนวน because it นับ สำเร็จ PMS check-ใน milestones.

แยก PMS check-ใน ออกจากการเสร็จสิ้นของ journey​

Successful Check‑Ins confirms that AVA completed ของ PMS CHECKIN request. สำหรับ OPERA, this คือ เมื่อ AVA sends ของ SCI code ไปยัง ของ PMS. AVA นับ ของ milestone เท่านั้น เมื่อ recorded Check-In evidence คือ SUCCESS หรือ PARTIAL. Pending หรือ ล้มเหลว legacy milestone ข้อมูล does ไม่ count as a สำเร็จ PMS check-ใน. AVA excludes checkout-เท่านั้น การเดินทาง เมื่อ เหตุการณ์ evidence แสดง no Check-In กิจกรรม. รายการนี้ prevents a legacy CHECKIN marker on a completed checkout จาก inflating ของ count. หาก a แขก completed Check-In before Checkout, AVA keeps that สำเร็จ Check-In count.

สำหรับ Check-In มุมมอง, Completion Rate uses สำเร็จ PMS CHECKIN as ของ primary การเสร็จสมบูรณ์ stage. วิธีนี้ทำให้ check-ใน การเสร็จสมบูรณ์ aligned ด้วย ของ PMS outcome. Room Access Delivery Rate measures room access separately จาก check-ใน การเสร็จสมบูรณ์.

What happenedSuccessful Check‑InsCompletion metrics
PMS CHECKIN succeeds, then keycard encoding failsCounts the PMS check-inCounts as completed; room access delivery may remain unsuccessful
Only a pending or failed legacy CHECKIN marker remainsDoes not countFollows the selected view's existing completion rule
Room assignment enters a queue without successful PMS CHECKINDoes not countFollows the selected view's existing completion rule
PMS CHECKIN and room access both succeedCounts the PMS check-inCounts as completed when the terminal signal succeeds

การ์ด no longer combines queued, early, และ key-collection categories into Successful Check‑Ins.

Room Access Delivery Rate ใช้เหตุการณ์หลัง check-ใน​

Room Access Delivery Rate นับ room access เท่านั้น after a สำเร็จ PMS CHECKIN. Eligible delivery เหตุการณ์ คือ สำเร็จ KEY_COLLECTION, GET_DOOR_LOCK_KEY, KEY_ENCODED, หรือ KEY_RETRIEVED เหตุการณ์. The eligible attempt set uses ของ room-access service's delivery capability. It รวม smart locks, lockers, และ configured non-manual keycard delivery. It excludes manual delivery และ unavailable room-access configurations. รายการ เหตุการณ์ จาก an earlier หรือ ล้มเหลว attempt cannot count toward a later สำเร็จ check-ใน.

The denominator รวม all eligible check-ใน attempts. Manual หรือ external room-access work does ไม่ count unless AVA records an eligible เหตุการณ์. Live Analytics และ daily rollups use ของ เดียวกัน calculation.

อัตราการส่งมอบสิทธิ์เข้าห้องต่ำกว่าที่คาด​

What you see: Room Access Delivery Rate คือ lower than ของ จำนวน ของ แขก who checked ใน.

Fix:

  1. Confirm ของ แขก has a สำเร็จ PMS CHECKIN เหตุการณ์.

  2. Check สำหรับ a สำเร็จ room-access เหตุการณ์ after that check-ใน.

  3. Remember that manual หรือ external encoding คือ ไม่ included.

  4. Refresh Command Center → Analytics after ของ เหตุการณ์ คือ recorded.

    ✓ Earlier, ล้มเหลว, หรือ pending access เหตุการณ์ do ไม่ increase this อัตรา.

ไม่พบ Room Access Delivered​

What you see: The Room Access Delivered การ์ด does ไม่ appear.

Fix:

  1. เปิด Settings → Room Access.

  2. Confirm that an AVA-managed method คือ configured.

  3. ใช้ smart locks, lockers, หรือ configured non-manual keycard delivery.

  4. Refresh Command Center → Analytics.

    ✓ Manual หรือ unavailable delivery does ไม่ display this optional การ์ด.

การ์ดความครอบคลุมของ Check-In​

เมื่อ AVA receives ความครอบคลุม ข้อมูล จาก your PMS, you may see two extra การ์ด after Completion Rate. รายการนี้ works สำหรับ AVA PMS, Cloudbeds, Opera, Mews, และ eZee.

CardWhat it showsWhy it matters
Eligible Check-In UnitsDistinct confirmation or sub-reservation units in the selected periodThis is the coverage denominator
AVA Check-In SharePercentage of eligible units with durable AVA check-in activityThis shows AVA adoption for arrivals in that period
ความครอบคลุมใช้วันที่เข้าพัก

Coverage uses each reservation's arrival วันที่ ใน your โรงแรม's timezone. Guests who finish pre-arrival check-ใน early still count เมื่อ they arrive ใน range. The funnel uses กิจกรรม dates, so these measures answer แตกต่าง questions.

Units vs การจอง

การ์ดเหล่านี้ count units, ไม่ whole การจอง. A multi-room booking สามารถ add more than one eligible unit.

How AVA decides eligibility

AVA นับ เท่านั้น การจอง ด้วย AVA กิจกรรม, a valid merchant-local arrival วันที่, และ an eligible status. สำหรับ AVA กิจกรรม, eligible statuses คือ RESERVED, CHECKED_IN, CHECKED_OUT, และ DUE_OUT. DUE_OUT นับ because ของ reservation already reached check-ใน before departure. สำหรับ OPERA, AVA also folds DueOut into ของ CHECKED_IN PMS ความครอบคลุม bucket. วิธีนี้ทำให้ departure-day และ day-use arrivals ใน ของ ความครอบคลุม denominator. หาก AVA cannot verify ของ ที่จำเป็น fields, it hides ของ ความครอบคลุม การ์ด instead ของ showing a misleading percentage.

OPERA การจอง

หาก your PMS คือ OPERA, AVA ignores PM, PF, และ PX pseudo rooms ใน ของ eligible unit count. It also uses top-level room type fields เมื่อ room rows คือ sparse, so real แขก rooms still count correctly.

OPERA reservation families

AVA ยังตัดรายการซ้ำของกลุ่มการจอง OPERA ที่เชื่อมโยงกัน โดยใช้หมายเลขยืนยันของรายการหลัก That keeps terminal sibling rows จาก inflating Eligible Check-In Units.

OPERA checked-out ความครอบคลุม

หาก your ที่เลือก วันที่ range รวม today before night audit, future-arrival Checked Out legs count as zero. AVA uses ของ ที่พัก's business วันที่ สำหรับ that short-circuit, so ของ ความครอบคลุม read stays fast และ consistent.

When ของ arrival cohort คือ unavailable

AVA first uses a narrow ความครอบคลุม result สำหรับ arrivals ใน your ที่เลือก วันที่ range. หาก that result คือ unavailable, incomplete, หรือ still rolling out, AVA uses arrival-filtered logs. หาก those logs คือ unavailable, AVA may use an กิจกรรม-based session map. That fallback สามารถ understate ความครอบคลุม สำหรับ narrow วันที่ ranges. รายการ empty result คือ a valid zero, ไม่ missing ข้อมูล. หาก no แหล่งข้อมูล คือ ที่มีอยู่, ของ ความครอบคลุม การ์ด stay hidden.

AVA นับ each processed reservation once. It uses ของ arrival-keyed cohort สำหรับ normal ความครอบคลุม ผลลัพธ์. The ที่เลือก range uses your โรงแรม timezone สำหรับ arrival-วันที่ comparisons. Search-เท่านั้น reservation lookups และ PMS หรือ front-desk sync ขั้นตอน do ไม่ credit ของ AVA numerator. หาก ของ numerator would exceed ของ denominator, AVA withholds ของ share การ์ด instead ของ clamping it. วิธีนี้ทำให้ AVA Check-In Share aligned ด้วย reservation ความครอบคลุม.

Fresh ผลลัพธ์ may lag briefly

หากคุณ refresh ของ เดียวกัน วันที่ range again, AVA may reuse ของ last ความครอบคลุม result สำหรับ a short เวลา. วิธีนี้ทำให้ ของ Analytics tab fast during repeated checks.

Corrected historical ความครอบคลุม

After a ความครอบคลุม rule update, AVA refreshes เก่ากว่า saved ความครอบคลุม ผลลัพธ์ before reusing them. Short วันที่ ranges สามารถ แสดง corrected การ์ด first. Longer ranges may use live ความครอบคลุม until ของ scheduled refresh finishes.

สัดส่วน Check-In ของ AVA ไม่ถูกต้อง​

What you see: AVA Check-In Share คือ missing, หรือ it looks higher than expected.

Fix:

  1. Refresh ของ Analytics tab.
  2. Confirm ของ วันที่ range matches your PMS report.
  3. Check that ของ range uses your โรงแรม timezone.
  4. Confirm your PMS คือ sending arrival dates และ reservation statuses.
  5. If it still looks wrong, contact support ด้วย a screenshot.

หากคุณ do ไม่ see these การ์ด, your PMS ข้อมูล may be missing ของ fields AVA needs. ผู้ให้บริการที่ไม่รองรับ PMS providers do ไม่ แสดง these การ์ด.

การ์ดความครอบคลุมของ Check-Out​

AVA แสดง checkout ความครอบคลุม เท่านั้น เมื่อ your PMS provides a เสร็จสมบูรณ์ departure-scoped cohort. คุณ may see two การ์ด ใน ของ Check-Out มุมมอง. การ์ดเหล่านี้ measure AVA checkout กิจกรรม separately จาก check-ใน กิจกรรม.

CardWhat it showsWhy it matters
Eligible Check-Out UnitsDistinct confirmation or sub-reservation units departing in the selected periodThis is the checkout coverage denominator
AVA Check-Out SharePercentage of eligible units with durable AVA checkout activityThis shows AVA adoption for departures in that period
ความครอบคลุมใช้วันที่ออกจากที่พัก

Checkout ความครอบคลุม uses each reservation's departure วันที่ ใน your โรงแรม's timezone. Check-ใน ความครอบคลุม uses arrival dates, so ของ two การ์ด สามารถ cover แตกต่าง units. The checkout numerator credits durable AVA checkout กิจกรรม เท่านั้น. Search-เท่านั้น lookups และ PMS หรือ front-desk sync ขั้นตอน do ไม่ count.

ความครอบคลุม Check-Out ตาม PMS​

Cloudbeds, Mews, และ OPERA provide native departure cohorts สำหรับ checkout ความครอบคลุม. AVA does ไม่ relabel arrival ความครอบคลุม as checkout ความครอบคลุม. ผู้ให้บริการที่ไม่รองรับ PMS adapters may แสดง Unavailable instead ของ a percentage. สำหรับ OPERA, incomplete reservation pagination also แสดง Unavailable. AVA does ไม่ calculate a percentage จาก partial departure ข้อมูล.

ความครอบคลุม Check-Out ไม่พร้อมใช้งาน​

What you see: The checkout ความครอบคลุม การ์ด แสดง Unavailable instead ของ a percentage.

Why this happens: AVA cannot verify เสร็จสมบูรณ์, departure-scoped ความครอบคลุม ข้อมูล. The PMS may ไม่ support departure cohorts, หรือ an OPERA reservation page may be incomplete. It hides ของ อัตรา rather than showing a misleading result.

Fix:

  1. Confirm you ที่เลือก Check-Out และ ของ correct วันที่ range.

  2. Refresh ของ Analytics tab after PMS sync finishes.

  3. Try ของ เดียวกัน range again after a few นาที.

  4. Contact support หาก ของ การ์ด remains unavailable.

    ✓ An unavailable การ์ด means ของ result cannot be trusted yet. It คือ ไม่ a zero.

ส่งออก CSV ของ STB EVA submissions​

ตั้งค่าแบบรวดเร็ว

ใช้เวลา under 1 minute. The ส่งออก ปรากฏ เท่านั้น on Check-In เมื่อ EVA คือ enabled.

ใช้ ของ small ดาวน์โหลด icon on ของ STB EVA submissions panel ไปยัง ส่งออก ของ ที่เลือก วันที่ range.

ItemWhat it showsWhat you can do
STB EVA submissionsAttempted, successful, and failed EVA submissions for the selected periodClick the download icon to download the CSV
CSV contentsSummary counts plus one row per EVA API attempt from eva_submission_logsUse it for STB reporting or audit review

  1. Open Main Menu → Command Center.

  2. เลือก ของ Analytics tab.

  3. Keep ของ Check-In มุมมอง ที่เลือก.

  4. Scroll ไปยัง STB EVA submissions.

  5. คลิก ของ ดาวน์โหลด icon.

  6. Save the downloaded stb-eva-submissions.csv file.

    ✓ The ไฟล์ รวม transaction IDs, result codes, reservation และ check-ใน IDs, ข้อผิดพลาด metadata, และ sanitized request รายละเอียด. ✓ Passport และ document numbers คือ masked. ✓ MRZ และ base64 fields คือ omitted. ✓ The ส่งออก no longer รวม legacy reservation rows จาก เก่ากว่า EVA reports. ✓ If ของ ดาวน์โหลด fails, AVA แสดง a local ข้อผิดพลาด ข้อความ ใน ของ panel.

กราฟ Funnel (จุดหลุดและเวลาของขั้นตอน)​

The funnel แสดง ของ percentage ของ เซสชัน that reached each ขั้นตอน.

  • Drop‑off compares each ขั้นตอน ไปยัง ของ ขั้นตอน before it.
  • Avg Stage Duration measures เวลา spent inside ของ stage, จาก stage start ไปยัง stage success.
  • Avg Time ไปยัง Next Step measures เวลา จาก one สำเร็จ ขั้นตอน ไปยัง ของ next.
  • The Slowest Step การ์ด uses stage duration first.
  • If AVA does ไม่ have stage timing, it falls back ไปยัง ของ next-ขั้นตอน duration.
  • If a later ขั้นตอน happens earlier than ของ prior ขั้นตอน, ของ duration คือ shown as 0.

ใช้ ของ Biggest Drop‑Off การ์ด ไปยัง pick ของ ขั้นตอน that needs coaching first.

ตัวอย่าง

หาก Document Upload has 60 เซสชัน และ ของ prior ขั้นตอน has 100, drop‑off คือ 40%. หาก Document Upload itself takes 20 วินาที, Avg Stage Duration คือ 20 วินาที. หาก Document Upload completes at 10:05 และ Validation at 10:07, Avg Time ไปยัง Next Step คือ 2 นาที.

การเปลี่ยนผ่านของ Checkout ใช้ milestone ที่จำเป็น​

In Check‑Out, AVA calculates conversion จาก ของ ที่จำเป็น checkout milestones.

StageHow AVA treats it
Checkout StartedRequired starting milestone from FETCH_CHECKOUT
Bill ReviewedOptional activity when a guest views the bill
Charges ConfirmedOptional activity when a guest confirms charges
Checkout PaymentOptional activity when payment is collected
Checkout CompleteRequired final milestone from CHECKOUT

A แขก สามารถ move directly จาก Checkout Started ไปยัง Checkout Complete. AVA นับ that พาธ as completed instead ของ showing a false drop‑off.

Observed optional stages appear ใน Optional checkout กิจกรรม. They do ไม่ lower conversion หรือ create a red loss transition. The dashboard และ downloadable analytics report use ของ เดียวกัน stage rules.

AVA แสดง Checkout Payment เมื่อ it observes checkout payment กิจกรรม. It keeps payment outside ของ ที่จำเป็น funnel, even เมื่อ a saved setting คือ stale. It does ไม่ label missing payment as ไม่ ที่จำเป็น หรือ treat it as a failure.

การ Check-Out โดยตรงผ่าน PMS ดูเหมือนจุดหลุด​

What you see: A แขก completed checkout ใน ของ PMS, but skipped bill หรือ payment stages.

Fix:

  1. เลือก Check‑Out ใน Command Center → Analytics.

  2. Find Checkout Complete as ของ final ที่จำเป็น stage.

  3. ตรวจสอบ Optional checkout กิจกรรม สำหรับ bill, charge, หรือ payment เหตุการณ์.

  4. Compare ของ dashboard ด้วย ของ downloadable report หาก you need a saved copy.

    ✓ Direct PMS checkouts count toward final conversion.

ดูการจองจากจุดหลุดของขั้นตอนที่จำเป็น​

Required checkout drop-offs สามารถ รวม a View รายการ action. ใช้ it ไปยัง find การจอง that reached one ที่จำเป็น stage but missed ของ next.

  1. เลือก Check‑Out ใน Command Center → Analytics.
  2. Find a ที่จำเป็น-stage transition ด้วย a drop-off count.
  3. คลิก View รายการ.
  4. ตรวจสอบ ของ confirmation จำนวน, แขก name, room, และ ล่าสุด failure รายละเอียด.
  5. คลิก Download CSV ไปยัง save ของ displayed การจอง.

AVA แสดง View รายการ เท่านั้น เมื่อ every matched session equals ของ displayed drop-off count. หาก ของ reservation mapping คือ incomplete, AVA hides ของ action สำหรับ that transition.

ตรวจสอบ ล้มเหลว checkout payments​

Payment ปรากฏ under Optional checkout กิจกรรม เมื่อ AVA observes checkout payment กิจกรรม. It สามารถ appear even เมื่อ a saved payment setting คือ stale. Payment กิจกรรม never changes checkout การเสร็จสมบูรณ์ หรือ ที่จำเป็น-stage conversion.

  1. เลือก Check‑Out ใน Command Center → Analytics.
  2. Find Payment under Optional checkout กิจกรรม.
  3. คลิก View ล้มเหลว การจอง เมื่อ ล้มเหลว payments คือ listed.
  4. ตรวจสอบ ของ reservation รายละเอียด และ failure ข้อความ.
  5. คลิก Download CSV ไปยัง save ของ displayed failures.

The CSV รวม Confirmation จำนวน, Guest name, Room, Failure ขั้นตอน, และ Failure ข้อความ. AVA แสดง View ล้มเหลว การจอง เท่านั้น เมื่อ every ล้มเหลว payment maps ไปยัง a session.

Successful Check-Outs ปรากฏในอีกวันหนึ่ง​

What you see: A checkout started on one day, but Successful Check‑Outs increases on another day.

Fix:

  1. Check เมื่อ ของ terminal checkout เหตุการณ์ succeeded.

  2. Compare that timestamp ด้วย your โรงแรม's local calendar วันที่.

  3. ตรวจสอบ ของ checkout start วันที่ เมื่อ comparing attempts หรือ funnel stages.

  4. Refresh ของ Analytics tab หาก ของ checkout completed recently.

    ✓ รายการนี้ คือ expected เมื่อ checkout crosses midnight หรือ completes after a delay.

การวิเคราะห์เวลา (ปริมาณรายชั่วโมง)​

Time Analysis แสดงความพยายามของ journey แยกตามชั่วโมงใน flow ที่เลือก การจองแต่ละรายการจะใช้กิจกรรมแรกที่สำเร็จใน flow นั้น

  • กลุ่มชั่วโมงใช้เขตเวลาที่กำหนดไว้ของโรงแรม
  • การตอบกลับ Analytics ระบุเขตเวลานี้ด้วย timeAnalysis.timezone
  • ระบบใช้ offset ของเขตเวลาสำหรับวันที่เลือก รวมถึงการเปลี่ยนแปลงเวลาออมแสง
  • ความพยายาม Pre‑Arrival ที่ยังไม่เสร็จสมบูรณ์แต่มีการบันทึกจะรวมอยู่ในจำนวนความพยายามรายชั่วโมง
  • ชื่อกราฟ ชั่วโมงสูงสุด และคำแนะนำเมื่อวางเมาส์จะแสดงว่าเป็นความพยายาม
  • ความพยายาม Check-Out ใช้กิจกรรม Check-Out เมื่อ flow นั้นมีกิจกรรมของตัวเอง
  • เมตริกการเสร็จสมบูรณ์ของ Pre‑Arrival ยังคงต้องมีขั้นตอน PRE_ARRIVAL ที่สำเร็จ
  • แสดง Peak Hours และ Rush Periods เพื่อช่วยวางแผนกำลังคน

ใช้ Peak Hours เพื่อวางแผนกำลังคนในช่วงเวลาที่มีผู้ใช้งานหนาแน่นที่สุด

ตัวอย่าง

เซสชันที่บันทึกเวลา 7:10 ตามเวลาท้องถิ่นของโรงแรมจะถูกนับในชั่วโมง 07:00

Issues (ความล้มเหลวล่าสุด)​

Issues แสดง เซสชัน ด้วย ของ most recent ล้มเหลว ขั้นตอน.

  • AVA checks ของ last 10 เหตุการณ์ สำหรับ failures.
  • If no recent failures exist, it uses ของ most recent failure on record.

ใช้ View Details ไปยัง see full ขั้นตอน history.

ตัวอย่าง

หาก a payment ล้มเหลว at 3:12 after earlier success, ของ issue แสดง Payment at 3:12. หาก ของ last 10 เหตุการณ์ คือ สำเร็จ, AVA แสดง ของ most recent failure on record.

กิจกรรมล่าสุด​

Recent Activity แสดง key ขั้นตอน that were สำเร็จ หรือ ล้มเหลว, such as:

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

รายการนี้ คือ capped ไปยัง ของ ล่าสุด 30 items.

ใช้ this รายการ ไปยัง confirm which ขั้นตอน were completed most recently.

ตัวอย่าง

คุณ may see “Check‑In completed successfully” หรือ a failure ข้อความ สำหรับ Identity Verification.

การกระจายขั้นตอนสุดท้าย (จุดที่ session จบ)​

กราฟนี้ groups ของ last ขั้นตอน ของ each session into categories:

  • Success — Full การเสร็จสมบูรณ์ ขั้นตอน
  • Timing — Early check‑ใน ขั้นตอน (including Room Queued)
  • Partial — Pre‑registration
  • Room — Room assignment ขั้นตอน (Room Assignment)
  • Documentation — Document หรือ ID verification
  • Payment — Payment ขั้นตอน
  • Early — Entry / Fetch ขั้นตอน

หาก a failure happens after ของ last success, ของ failure ขั้นตอน becomes ของ final ขั้นตอน.

ใช้ this chart ไปยัง see ของ most common stopping points.

ตัวอย่าง

Out ของ 50 เซสชัน, 20 end at Check‑In (success), 10 at Early Check‑In (timing), 8 at Document Upload (documentation), และ 12 at Payment (payment).

เปิด session จากการกระจายขั้นตอนสุดท้าย​

  1. เลือก a bar segment ใน Final Step Distribution.

  2. ตรวจสอบ ของ session รายการ that opens.

    ✓ The รายการ แสดง confirmation จำนวน, แขก, room, และ ของ ล่าสุด failure.

  3. เลือก เปิด รายละเอียด on any session.

    ✓ The Reservation Details panel opens สำหรับ that session.

Session lists vs การจอง

รายการ แสดง เซสชัน, ไม่ grouped การจอง. ใช้ it ไปยัง spot repeat failures fast.

Device Analytics (ไม่บังคับ)​

Device Analytics ใช้ ของ device รายละเอียด จาก ของ check‑ใน/out session.

หาก a kiosk session has no physical kiosk ID, AVA แสดง it as Unidentified kiosk. วิธีนี้ทำให้ ของ session separate จาก Guest device กิจกรรม.

The Unidentified kiosk label means ของ session แหล่งข้อมูล คือ known, but its device metadata คือ missing. It does ไม่ identify a แขก-owned phone หรือ tablet.

Live analytics และ rollup analytics use ของ เดียวกัน kiosk classification.

ระบุแหล่งที่มาของพนักงานที่ช่วย check-in​

Virtual assisted check-ใน เซสชัน appear ด้วย ของ ปัจจุบัน staff alias ใน ของ แหล่งข้อมูล รายการ. รายการนี้ helps you identify which staff member handled each assisted check-ใน. New เซสชัน จาก Streamliner virtual staff kiosks count as Kiosk การเดินทาง. They no longer appear as front-desk หรือ desktop sources.

หาก a staff member changes their name, Analytics uses ของ updated alias เมื่อ you refresh ของ มุมมอง. วันที่เก่า การเดินทาง keep their original แหล่งข้อมูล identity และ do ไม่ need ไปยัง be rewritten.

If ของ แหล่งข้อมูล แสดง an ID

AVA keeps ของ raw virtual-master ID เมื่อ ของ alias service คือ unavailable. รายการ เก่ากว่า staff master without an alias also แสดง its raw ID.

ระบุแหล่งที่มาของคีออสก์ที่เก็บถาวร​

รายการที่ถูกนำออก manual หรือ managed kiosks no longer appear ใน ของ active CCI device รายการ. Their historical Analytics rows สามารถ still แสดง ของ archived kiosk alias.

รหัส kiosk ID ปรากฏ below ของ alias สำหรับ reliable device matching. หาก a kiosk ID ปรากฏ ใน both lists, AVA uses ของ active device alias. รายการ archived alias identifies historical กิจกรรม เท่านั้น; it does ไม่ restore ของ kiosk. The archive คือ display-เท่านั้น, so active kiosk การตั้งค่า cannot edit historical aliases.

อ่านยอดรวม journey ตามแหล่งที่มา​

Device Analytics groups เซสชัน into Kiosk การเดินทาง และ Guest device การเดินทาง. แต่ละ แหล่งข้อมูล แสดง ทั้งหมด การเดินทาง, สำเร็จ การเดินทาง, และ its การเสร็จสมบูรณ์ อัตรา.

The reconciliation ข้อความ compares these sources ด้วย ของ dashboard's unique reservation การเดินทาง. ยอด คือ deduplicated by reservation, so repeated เซสชัน do ไม่ inflate ของ totals.

สำหรับ check-ใน, เท่านั้น a สำเร็จ PMS CHECKIN เหตุการณ์ นับ as สำเร็จ. Room assignment, key retrieval, และ key encoding แสดง progress, ไม่ completed check-ใน.

What you seeMeaning
Successful journeys out of total journeysSource completion and its denominator
Unidentified kioskKiosk-origin journey without physical kiosk metadata
Source totals match the dashboardBoth views use the same reservation journey cohort

ใช้ this มุมมอง ไปยัง compare kiosk vs mobile usage by OS.

ตัวอย่าง

หาก most เซสชัน คือ iOS, you may want ไปยัง optimize ของ mobile check‑ใน โฟลว์.

ขีดจำกัดและความใหม่ของข้อมูล​

  • Analytics covers up ไปยัง 92 inclusive calendar วัน per วันที่-เท่านั้น query.
  • Full quarters คือ supported, including July 1–September 30.
  • AVA validates วันที่-เท่านั้น ranges by โรงแรม-local calendar วัน, independent ของ daylight-saving changes.
  • When daily rollups คือ ที่มีอยู่, wide ranges load จาก rollup ข้อมูล first.
  • CCI และ ACI filters use their matching daily rollup slices เมื่อ ที่มีอยู่.
  • Older โหมด-filtered ranges สามารถ temporarily use live calculation while slices refresh.
  • The unfiltered Overall มุมมอง สามารถ use เก่ากว่า rollups without โหมด slices.
  • Very busy properties may need a smaller range หาก ของ result set คือ too large.
  • If AVA asks you ไปยัง narrow ของ วันที่ range, shorten ของ period และ try again.
  • Oversized requests return an ข้อผิดพลาด without a partial report หรือ bulk-ข้อมูล fallback.
  • Session lists คือ capped สำหรับ performance (about 200 per ขั้นตอน และ 2,000 ทั้งหมด).

เลือกช่วงวันที่ Analytics ที่ถูกต้อง​

The Date control แสดง ของ Analytics limit before AVA loads ข้อมูล. เลือก no more than 92 calendar วัน, counting both ของ start และ end dates. รายการนี้ allows เสร็จสมบูรณ์ calendar quarters, including July 1–September 30.

What you seeWhat it meansFix
Analytics: up to 92 days, including full quartersYour range is valid.Continue reviewing the report.
Select up to 92 calendar days...Your range is longer than the Analytics limit.Shorten the range or review one quarter at a time.

เมื่อแผง range คือ invalid, AVA does ไม่ send Analytics หรือ missing-reservation requests. The ที่เลือก dates stay unchanged, so you สามารถ correct ของ range yourself. Analytics resumes after ของ range becomes valid. Other Status filters keep their existing วันที่-range behavior.

การแก้ไขปัญหา​

All charts แสดง zero​

What you see: Summary การ์ด แสดง 0 และ charts คือ empty.

Fix:

  1. Expand ของ วันที่ range.
  2. Confirm there คือ logs ใน Status.
  3. Check หาก your plan รวม Analytics.

อัตราการเสร็จสมบูรณ์ต่ำกว่าที่คาด​

What you see: Completion อัตรา คือ low even though many แขก checked ใน.

Check:

  • Demo check-ins คือ excluded, so test เซสชัน do ไม่ raise Total Logs.
  • Pre-arrival-เท่านั้น เซสชัน do ไม่ count toward All Check‑Ins.
  • A session that completes pre-arrival และ later completes check-ใน ปรากฏ ใน both relevant มุมมอง.
  • A session that starts Pre‑Arrival but abandons it qualifies สำหรับ Pre‑Arrival และ lowers its การเสร็จสมบูรณ์ อัตรา.
  • A session that เท่านั้น opens a pre-arrival link does ไม่ qualify without recorded โฟลว์ กิจกรรม.
  • Check-In การเสร็จสมบูรณ์ uses สำเร็จ PMS CHECKIN.
  • KEY_ENCODED places a session ใน Full Check‑In, but does ไม่ เสร็จสมบูรณ์ it.
  • Early Check‑In และ Pre‑Registration คือ tracked ใน their own sub‑tabs.
  • Successful Check‑Ins นับ สำเร็จ PMS CHECKIN milestones.
  • Checkout-เท่านั้น records ด้วย a legacy CHECKIN marker do ไม่ count without Check-In กิจกรรม evidence.
  • Room Access Delivery Rate สามารถ be lower เมื่อ AVA does ไม่ record a post-check-ใน access เหตุการณ์.

ยอดรวมตามแหล่งที่มาแตกต่างจากรายงานเก่า​

What you see: Device Analytics totals หรือ การเสร็จสมบูรณ์ rates changed after deployment.

Fix:

  1. Compare ของ เดียวกัน วันที่ range ใน Command Center → Analytics.

  2. Read ของ reconciliation ข้อความ below ของ แหล่งข้อมูล summary.

  3. Treat CHECKIN as ของ เท่านั้น สำเร็จ check-ใน เหตุการณ์.

  4. Allow เวลา สำหรับ เก่ากว่า cached analytics ไปยัง refresh after deployment.

    ✓ Current แหล่งข้อมูล rows reconcile ด้วย ของ dashboard's canonical reservation การเดินทาง.

ไม่พบการ์ดความครอบคลุม​

What you see: คุณ เท่านั้น see ของ standard summary การ์ด.

Fix:

  1. Stay on Check-In.

  2. Confirm your PMS connection คือ active.

  3. Refresh ของ page after sync finishes.

  4. If ของ วันที่ range คือ busy, refresh again after a few นาที.

    ✓ If your PMS supports reservation ความครอบคลุม, Eligible Check-In Units และ AVA Check-In Share appear after Completion Rate.

การ์ดความครอบคลุมยังไม่เปลี่ยนแปลง​

What you see: Eligible Check-In Units หรือ AVA Check-In Share still looks ของ เดียวกัน after a refresh.

Fix:

  1. Wait a minute.
  2. Refresh ของ Analytics tab again.
  3. Confirm ของ วันที่ range matches ของ PMS update you expect.
  4. If it still looks wrong, check that PMS sync has finished.

การวิเคราะห์เวลาใช้ชั่วโมงท้องถิ่นไม่ถูกต้อง​

What you see: Peak ชั่วโมง do ไม่ match your โรงแรม's local เวลา.

Fix:

  1. ตรวจสอบค่า timeAnalysis.timezone ในการตอบกลับ Analytics
  2. เปรียบเทียบกลุ่มชั่วโมงกับเขตเวลาที่กำหนดไว้ของโรงแรม
  3. ตรวจสอบเขตเวลาของโรงแรมที่ Settings → Essentials → Hotel Basic Details
  4. รีเฟรชแท็บ Analytics หลังเปลี่ยนเขตเวลา

Analytics โหลดไม่เสร็จหรือขอให้ลดช่วงวันที่​

What you see: The Analytics tab spins สำหรับ a long เวลา, แสดง a timeout, หรือ asks you ไปยัง narrow ของ วันที่ range.

Why this happens: The ที่เลือก range may contain more than 20,000 เซสชัน. AVA จะปฏิเสธคำขอที่มีขนาดใหญ่เกินไปก่อนแสดงรายงาน

Fix:

  1. เลือก a smaller วันที่ range.

  2. Refresh ของ Analytics tab และ retry.

  3. Split long periods into separate reports.

  4. If small วันที่ ranges still fail, contact support ด้วย ของ ที่เลือก dates.

    ✓ Smaller ranges should finish faster และ help you confirm whether ของ issue คือ range size หรือ ข้อมูล availability.

หาก เท่านั้น a โหมด-filtered มุมมอง loads slowly, its historical rollup slices may still be refreshing. ลอง ของ unfiltered Overall มุมมอง, หรือ retry ของ โหมด มุมมอง later.

ช่วงวันที่ Analytics แสดงข้อผิดพลาด​

What you see: The Date control คือ marked invalid และ แสดง a 92-day ข้อความ.

Fix:

  1. Keep ของ start วันที่ หาก it คือ correct.

  2. Move ของ end วันที่ until ของ range รวม 92 วัน หรือ fewer.

  3. For longer reporting, split ของ period into separate quarter-sized ranges.

    ✓ AVA keeps your ที่เลือก dates until you correct ของ range. ✓ Analytics loads automatically after ของ range becomes valid.

Analytics แสดงขั้นตอนจากอีกวันหนึ่ง​

What you see: A ที่เลือก day ปรากฏ ไปยัง รวม a การเสร็จสมบูรณ์ จาก another calendar day.

Fix:

  1. Confirm ของ โรงแรม's timezone at Settings → Essentials → Hotel Basic Details.
  2. Re-select ของ วันที่ range using ของ โรงแรม's local calendar day.
  3. Refresh ของ Analytics tab.
  4. If ของ result still looks wrong, contact support ด้วย ของ ที่เลือก dates และ reservation จำนวน.

การคัดลอก MCP config ล้มเหลว​

What you see: The button แสดง an ข้อผิดพลาด after you click Copy Codex MCP Config หรือ Copy Claude MCP Config.

Fix:

  1. Stay on ของ Analytics tab.
  2. Try ของ copy button again.
  3. Refresh ของ page และ retry หาก ของ token request timed out.
  4. If ของ ข้อผิดพลาด stays, contact support ด้วย ของ exact ข้อความ.

คัดลอก config แล้ว แต่ไคลเอนต์เชื่อมต่อไม่ได้​

What you see: The modal opens, but Codex หรือ Claude does ไม่ load ของ Streamliner เซิร์ฟเวอร์.

Fix:

  1. Check that you pasted ของ config into ของ correct ไฟล์.
  2. Confirm the STREAMLINER_MCP_TOKEN value is still present.
  3. Restart ของ ไคลเอนต์ completely.
  4. Copy a fresh config หาก setup took too long.

ไม่พบเครื่องมือการตั้งค่า​

What you see: Your ไคลเอนต์ connects, but การตั้งค่า actions do ไม่ appear.

Fix:

  1. Copy a fresh config จาก Analytics.
  2. Restart ของ ไคลเอนต์ completely.
  3. Confirm the pasted STREAMLINER_MCP_TOKEN is the latest one.
  4. Remove any เก่ากว่า Streamliner config block หาก it คือ still present.

การเขียนการตั้งค่าหมดเวลา​

What you see: A การตั้งค่า save looks stuck, then returns a timeout หรือ cancel ข้อความ.

Fix:

  1. Copy a fresh config จาก Analytics.

  2. Restart ของ ไคลเอนต์ completely.

  3. Try ของ การตั้งค่า change again.

  4. If it fails again, check whether your token หรือ session expired.

    ✓ Valid การตั้งค่า updates should finish instead ของ hanging.

การยืนยันตัวตนล้มเหลวขณะเขียนการตั้งค่า​

What you see: คุณ get an authentication ข้อผิดพลาด เมื่อ saving merchant การตั้งค่า.

Fix:

  1. Copy a fresh config จาก Analytics.

  2. Restart ของ ไคลเอนต์ completely.

  3. Retry ของ การตั้งค่า change ใน ของ เดียวกัน โรงแรม.

  4. If you switched hotels, refresh ของ config after ของ switch.

    ✓ The new ข้อผิดพลาด should tell you ไปยัง generate a fresh MCP config/token.

การดาวน์โหลด PDF ไม่เริ่มทำงาน​

What you see: คุณ click Download report, but no PDF downloads.

Fix:

  1. Wait until ของ Analytics summary finishes loading.
  2. Retry Download report.
  3. Narrow ของ วันที่ range หาก ของ report remains slow.
  4. Check that your browser allows downloads.
  5. Contact support หาก ของ PDF still does ไม่ ดาวน์โหลด.

ไม่พบการส่งออก STB EVA​

What you see: คุณ do ไม่ see ของ ดาวน์โหลด icon under STB EVA submissions.

Fix:

  1. Switch ไปยัง Check-In.
  2. Confirm EVA คือ enabled สำหรับ Singapore ใน Settings → Check-ใน → Government Integration.
  3. Refresh ของ page after ของ analytics ข้อมูล loads.
  4. If ของ panel คือ still hidden, ของ ที่เลือก วันที่ range may ไม่ รวม EVA submissions.

การส่งออก CSV ล้มเหลว​

What you see: คุณ click ของ ดาวน์โหลด icon, but no ไฟล์ downloads.

Fix:

  1. Retry after ของ analytics summary finishes loading.
  2. Narrow ของ วันที่ range.
  3. Check that your browser allows downloads.
  4. Try again once ของ local ข้อผิดพลาด clears.
  5. Contact support หาก ของ ส่งออก still fails.

ไม่พบรายการการจองใน Funnel​

What you see: A ที่จำเป็น drop-off หรือ ล้มเหลว payment has no รายการ action.

Fix:

  1. Confirm you ที่เลือก Check‑Out และ ของ correct วันที่ range.
  2. Check that ของ transition has a non-zero drop-off หรือ ล้มเหลว-payment count.
  3. Refresh ของ Analytics tab after ของ ข้อมูล finishes loading.
  4. If mapping remains incomplete, use Status ไปยัง search สำหรับ ของ reservation.

AVA hides รายการ actions เมื่อ it cannot safely match every displayed count.

ยอดรวมตามโหมดไม่ตรงกัน​

What you see: The Overall ทั้งหมด คือ higher than ของ explicit CCI + ACI ทั้งหมด.

Fix:

  1. Confirm you ที่เลือก ของ เดียวกัน วันที่ range และ measure ใน each มุมมอง.

  2. ใช้ Check-ใน Result → Successful Check-Ins สำหรับ usage reporting.

  3. Check whether you คือ comparing Overall ด้วย CCI + ACI.

  4. Remember that mixed-โหมด การเดินทาง count once under their attributed โหมด.

  5. ใช้ Funnel → Completed เท่านั้น เมื่อ measuring journey conversion.

    ✓ Explicit CCI + ACI reconciles ด้วย attributed CCI และ ACI การเดินทาง.

ไม่พบแผงข้อมูลระดับที่พัก​

What you see: Payment, EVA, หรือ lost-key metrics คือ missing จาก Check-In → Analytics.

Fix:

  1. เลือก ของ CCI + ACI report มุมมอง.

  2. Confirm ของ ที่เลือก วันที่ range รวม ของ กิจกรรม.

  3. Refresh ของ Analytics tab after ของ ข้อมูล finishes loading.

  4. For EVA metrics, confirm EVA คือ enabled สำหรับ your ที่พัก.

    ✓ CCI และ ACI โหมด slices intentionally omit ที่พัก-wide panels.

ยังแก้ไม่ได้ใช่ไหม​

Contact success@vouch-technologies.com หาก:

  • ❌ Analytics แสดง ข้อมูล ใน Status but Analytics คือ empty
  • ❌ Charts never update after changing ของ วันที่ range
  • ❌ Issues รายการ แสดง incorrect timestamps

Helpful ไปยัง รวม:

  • Date range you ที่เลือก
  • Screenshot ของ ของ Analytics tab
  • Confirmation จำนวน ของ a sample reservation