วงจรลูกค้า (ฝั่งเซิร์ฟเวอร์)

1. ทำไมมีส่วนนี้ควบคู่สะพานเชื่อมเบราว์เซอร์

MousePlayer มีสะพานเชื่อมวงจรลูกค้าที่เขียนลง SDK บนหน้าอยู่แล้ว ทั้ง Klaviyo, Braze, Customer.io และอีกหกระบบ ส่วนนี้ทำงานเดียวกันจากเซิร์ฟเวอร์ เพราะสองแพลตฟอร์มใหญ่ที่สุดใช้ทางเบราว์เซอร์ไม่ได้:

• ActiveCampaign ไม่มี API เบราว์เซอร์สำหรับเหตุการณ์เลย คำสั่ง vgo() ตั้งบัญชีและอีเมลแล้วเริ่มติดตามได้ แต่ส่งเหตุการณ์ไม่ได้ เหตุการณ์ต้องผ่าน Event Tracking API ด้วย event key แยก เฉพาะฝั่งเซิร์ฟเวอร์
• Mailchimp มี แต่รองรับชื่อจำกัด พิกเซลติดตามเว็บไซต์รับ PAGE_VIEWED, PRODUCT_VIEWED, PURCHASED และชื่อที่กำหนดไว้อีกไม่กี่ชื่อ ไม่มีช่องให้เหตุการณ์กำหนดเอง การฝืนข้อมูลเราให้เป็น PAGE_VIEWED จะทำให้โมเดลข้อมูลของคุณเองเป็นเท็จ

2. สิ่งที่ต้องใช้

สามช่อง โดยขึ้นกับแพลตฟอร์มว่าจะกรอกช่องใด

ช่องที่สามคือชื่อเหตุการณ์ที่จะแสดง ควรสั้น: ไม่เกิน 32 อักขระ เป็นข้อจำกัด API ไม่ใช่ของเรา เราตัดตอนบันทึกไม่ใช่ตอนส่ง มิฉะนั้นแบบฟอร์มจะแสดงต่างจากข้อมูลที่ถึง

3. ทำงานเมื่อใดและไม่ทำงานเมื่อใด

ทันทีที่ระบุตัวตนเซสชัน เมื่อเว็บไซต์เรียก MousePlayer.setUserId() หรือสะพานเชื่อมวิเคราะห์อ่าน distinct ID หรือเซิร์ฟเวอร์เรียกปลายทาง identify ก่อนหน้านั้นเราไม่ทราบว่าบันทึกเป็นของใคร

เฉพาะ ID ที่เป็นอีเมล

ทั้งสี่แพลตฟอร์มใช้ที่อยู่อีเมลระบุผู้ติดต่อ หาก ID ลูกค้าเป็นเลขสัญญาจะไม่ส่งอะไร การเพิ่มงานที่ล้มเหลวแน่นอนมีแต่ทำให้บันทึกรก

ทุกเหตุการณ์มี ID

เซสชันเดียวจึงไม่นับซ้ำแม้งานลองใหม่

4. สิ่งที่ถึงอีกฝั่ง

หนึ่งเหตุการณ์พร้อมลิงก์เล่นย้อนหลังในพร็อพเพอร์ตีชื่อ mouseplayer_session_url เปิดแล้วเข้าสู่บันทึกเซสชันนั้นโดยตรง

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

คีย์ไม่ออกจากเซิร์ฟเวอร์เรา

เก็บเข้ารหัส AES-256-GCM ไม่แสดงอีกหลังบันทึก และตั้งใจไม่ใส่ในคิวภายในที่เก็บงาน ตัวประมวลผลงานอ่านจากฐานข้อมูลเอง

HTTP 200 ไม่ได้แปลว่าส่งถึง

ActiveCampaign ตอบสถานะ 200 พร้อม {"success":0} เมื่อปฏิเสธเหตุการณ์ เราอ่านเนื้อหาคำตอบ ไม่ใช่แค่สถานะ การปฏิเสธจึงแสดงล้มเหลวในบันทึกการส่ง แทนสำเร็จเงียบๆ