ข้อมูลของคุณพร้อมหรือยัง? ข้อกำหนดสำหรับ BrazeAI Decisioning Studio

Over-the-shoulder view of a monitor showing an abstract data table with one green row, a hand on a trackpad and four index cards beside the keyboard, showing a data readiness check.

BrazeAI Decisioning Studio Pro เรียนรู้จากข้อมูลที่คุณเชื่อมต่อ ดังนั้นความพร้อมของข้อมูลจึงเป็นตัวตัดสินว่าเอเจนต์จะทำงานได้ดีเพียงใด Braze ได้กำหนดหลักการไว้ 4 ประการ ได้แก่ การใช้ตัวระบุลูกค้าเพียงหนึ่งเดียวในทุกสินทรัพย์, การส่งเหตุการณ์เป็นสตรีมแบบเพิ่มข้อมูล, การรีเฟรชสแนปชอตตามกำหนดเวลา และการมีบันทึกข้อมูลที่สะอาดและไม่มีข้อมูลซ้ำซ้อน คู่มือนี้จะครอบคลุมหลักการเหล่านั้น ตัวเลือกการเชื่อมต่อ และกฎการเติมข้อมูลย้อนหลัง พร้อมปิดท้ายด้วยการตรวจสอบความพร้อม 4 ขั้นตอน

ประเด็นสำคัญ

Braze ได้กำหนดหลักการข้อมูล 4 ประการสำหรับ Decisioning Studio Pro และระบุว่าการละเมิดหลักการข้อใดข้อหนึ่งถือเป็นสาเหตุที่พบบ่อยที่สุดประการหนึ่งที่ทำให้ประสิทธิภาพของโมเดลลดลง
ใช้ตัวระบุลูกค้าหลักเพียงหนึ่งเดียวในทุกสินทรัพย์ Braze แนะนำให้ใช้ Braze external ID
ส่งเหตุการณ์เป็นบันทึกข้อมูลแต่ละรายการที่มีการประทับเวลา และรีเฟรชสแนปชอตตามกำหนดเวลาสำหรับลูกค้าทุกคน รวมถึงลูกค้าที่ไม่มีเหตุการณ์ใหม่เกิดขึ้น
แบ่งส่วนการส่งออกเหตุการณ์รายวันตามการประทับเวลาการสร้าง (creation timestamp) เนื่องจากการแบ่งส่วนตามการประทับเวลาของเหตุการณ์ (event timestamp) จะทำให้พลาดบันทึกข้อมูลที่มาถึงล่าช้าอย่างถาวร
เลือกฟีเจอร์ที่ช่วยให้เอเจนต์แยกแยะตัวเลือกเฉพาะของคุณได้ ไม่ใช่ฟีเจอร์ที่อธิบายลูกค้าในภาพรวมเท่านั้น
เราแนะนำให้ตรวจสอบความพร้อม 4 ขั้นตอนตามลำดับ ได้แก่ ข้อมูลระบุตัวตน, เหตุการณ์, สแนปชอต และการเติมข้อมูลย้อนหลัง

ข้อกำหนดด้านข้อมูลของ Braze Decisioning Studio มีอะไรบ้าง?

BrazeAI Decisioning Studio มี 2 ระดับ ซึ่งการจัดการข้อมูลจะแตกต่างกันไปในแต่ละระดับ โดยรุ่น Go จะเรียนรู้จากสัญญาณ 3 ประการภายใน Braze ได้แก่ กลุ่มเป้าหมายของคุณ, การมีส่วนร่วมทางอีเมลของกลุ่มเป้าหมายนั้น และความเข้าใจในเนื้อหาของคุณเอง ส่วนรุ่น Pro จะเพิ่มข้อมูลบุคคลที่หนึ่งของคุณเข้าไปด้วย เช่น คุณลักษณะที่กำหนดเอง, ข้อมูลจากคลังข้อมูล และเหตุการณ์การแปลงผลที่กำหนดเอง

หน้าการเตรียมข้อมูลถูกเขียนขึ้นสำหรับรุ่น Pro โดยเน้นย้ำถึงความสำคัญอย่างชัดเจน ข้อมูลคุณภาพสูงคือรากฐานของเอเจนต์ที่มีประสิทธิภาพ การละเมิดหลักการทั้ง 4 ประการถือเป็นสาเหตุที่พบบ่อยที่สุดประการหนึ่งที่ทำให้ประสิทธิภาพของโมเดลลดลง

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

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

ทุกสินทรัพย์ควรใช้ตัวระบุลูกค้าตัวใด?

คำแนะนำของ Braze คือการใช้ตัวระบุหลักเพียงหนึ่งเดียวที่ปรากฏในทุกสินทรัพย์ และแนะนำให้ใช้ Braze external ID โดยรุ่น Pro จะทำงานโดยใช้ ID นั้นเป็นหน่วยหลักในการระบุตัวตนของลูกค้าเพียงอย่างเดียว

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

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

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

CustomerIK'sการจัดการข้อมูลลูกค้า ครอบคลุมการแก้ไขข้อมูลระบุตัวตนและการรวมโปรไฟล์ที่ซ้ำกัน ของเรา กรณีศึกษาเกี่ยวกับการรวมโปรไฟล์ลูกค้าที่กระจัดกระจาย อธิบายถึงการทำงานในลักษณะดังกล่าว

หากธุรกิจของคุณมีหน้าร้านหลายแห่งหรือมีแบรนด์ย่อย โปรดปรึกษากับทีม AI Decisioning Services เกี่ยวกับลำดับชั้นของลูกค้าก่อน โดยหน้านี้จะสอบถามข้อมูลดังกล่าวให้คุณทราบก่อนที่จะสรุปกลยุทธ์การระบุตัวตน

ควรส่งข้อมูลเหตุการณ์ (events) และภาพรวมข้อมูล (snapshots) ในแต่ละวันอย่างไร?

Pro จะรันไปป์ไลน์การแนะนำข้อมูลวันละหนึ่งครั้งและต้องการข้อมูลสองรูปแบบ ได้แก่ Snapshots ซึ่งอธิบายสถานะของลูกค้า เช่น ฟิลด์โปรไฟล์และฟีเจอร์ที่คำนวณไว้ และ Event streams ซึ่งบันทึกสิ่งที่เกิดขึ้น โดยจะเป็นบันทึกที่ไม่สามารถเปลี่ยนแปลงได้หนึ่งรายการต่อหนึ่งเหตุการณ์

Snapshots ควรถูกสร้างขึ้นตามกำหนดเวลาสำหรับลูกค้าทุกคน รวมถึงลูกค้าที่ไม่มีเหตุการณ์ใหม่เกิดขึ้น โดยบันทึก Snapshot ใหม่จะถูกเพิ่มเข้าไปแทนที่จะเขียนทับค่าเดิม ส่วนเหตุการณ์ (Events) จะทำงานในทางกลับกัน เนื่องจากจะมีเพียงลูกค้าที่มีเหตุการณ์เกิดขึ้นเท่านั้นที่จะมีบันทึกใหม่

ให้แบ่งข้อมูลส่งออกรายวันแต่ละชุดตามการประทับเวลาที่สร้าง (creation timestamp) หากคุณแบ่งข้อมูลตามการประทับเวลาของเหตุการณ์ (event timestamp) เหตุการณ์ที่ถูกบันทึกลงในระบบหลังจากที่เกิดขึ้นจริงจะสูญหายไปอย่างถาวร หน้านี้ได้แสดงรูปแบบการสืบค้นข้อมูลโดยให้ t คือวันที่รันระบบ:

-- ถูกต้อง: ใช้ create_timestamp เพื่อให้แน่ใจว่าเหตุการณ์ที่เข้ามาล่าช้าจะถูกบันทึกไว้
SELECT * FROM events_data WHERE DATE (create_timestamp) = { t - 1 }
-- ในวันที่รัน t ให้ส่งออกบันทึกทั้งหมดที่สร้างขึ้นเมื่อวานนี้

กลไกของ Braze	รูปแบบข้อมูล	พฤติกรรมที่ระบุไว้
คุณลักษณะที่กำหนดเอง (Custom attributes)	ข้อมูล Snapshot: โปรไฟล์ลูกค้าและฟีเจอร์ที่คำนวณไว้	การอัปเดตแต่ละครั้งจะเขียนทับค่าก่อนหน้า ดังนั้นคุณลักษณะจะเก็บสถานะล่าสุดไว้และเหตุการณ์ก่อนหน้าจะหายไป Braze แนะนำว่าไม่ควรใช้คุณลักษณะที่กำหนดเองเพื่อส่งข้อมูลเหตุการณ์ดิบ
Braze Currents, `USER_BEHAVIOR_CUSTOM_EVENTS` ตาราง	ข้อมูลสตรีมเหตุการณ์ (Event stream data)	บันทึกทุกเหตุการณ์ที่กำหนดเองที่เกิดขึ้นจริง ทำให้เป็นแหล่งข้อมูลที่ถูกต้องสำหรับการเปิดใช้งาน การมีส่วนร่วม และเหตุการณ์การแปลงผล (conversion events)

หน้านี้อธิบายเกี่ยวกับการเพิ่ม Snapshot ในที่หนึ่ง และการเขียนทับคุณลักษณะที่กำหนดเองในอีกที่หนึ่ง เราขอแนะนำให้คุณสอบถามทีม AI Decisioning Services ว่ามีการเก็บประวัติสถานะไว้ในระบบของคุณอย่างไร

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

คุณเชื่อมต่อข้อมูลอย่างไร และส่วนใดที่ต้องผ่านการตรวจสอบความปลอดภัย?

Braze ระบุรูปแบบการเชื่อมต่อสี่แบบสำหรับ Pro ซึ่งมีความซับซ้อนในการตั้งค่าที่แตกต่างกัน

รูปแบบการเชื่อมต่อ	เหมาะสำหรับ	ความซับซ้อนในการตั้งค่า
Braze Data Platform	ลูกค้าที่ใช้ Braze อยู่แล้ว	ต่ำ
Braze Cloud Data Ingestion (CDI)	การเชื่อมต่อคลังข้อมูลภายนอก	ปานกลาง
Cloud Storage (GCS, AWS, Azure)	การส่งออกข้อมูลโดยตรงจากแพลตฟอร์มอื่น	ปานกลาง
การเชื่อมต่อ CEP	ข้อมูลส่วนขยาย SFMC, Klaviyo	ปานกลาง

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

ข้อมูลจากคลังข้อมูลสามารถส่งถึง Pro ผ่าน CDI ได้สองวิธี คุณสามารถซิงค์ข้อมูลเข้าสู่ Braze Data Platform หรือส่งตรงไปยัง Pro โดยไม่ต้องเพิ่มลงในโปรไฟล์ผู้ใช้หรือคุณลักษณะที่กำหนดเอง ตัวเลือกการส่งตรงนี้อยู่ในช่วงการเข้าถึงก่อนกำหนด (early access) และบันทึกประจำรุ่น ณ วันที่ 20 ส.ค. 2026 ก็ระบุสถานะเดียวกันนี้

การซิงค์โดยตรงแต่ละครั้งต้องใช้คีย์หลักหรือคีย์ผสมและจับคู่กับสินทรัพย์เดียว ดังนั้นควรวางแผนการซิงค์หนึ่งครั้งต่อหนึ่งสินทรัพย์

รายละเอียดหลายประการที่ระบุไว้ในเอกสารควรได้รับการตรวจสอบความปลอดภัยก่อนที่จะทำการเชื่อมต่อใดๆ:

หน้าการเชื่อมต่อข้อมูลระบุว่าฝ่ายความปลอดภัยของข้อมูล (Information Security) ยังคงจำเป็นต้องตรวจสอบจุดเชื่อมต่อทั้งหมด
คู่มือการเชื่อมต่อระบุว่า Decisioning Studio ไม่รองรับข้อมูลระบุตัวตนส่วนบุคคล (PII) ดังนั้นการส่งออกข้อมูลด้วย ID ภายนอกจะต้องส่งคืนเฉพาะฟิลด์ที่ไม่ใช่ PII เท่านั้น
หน้าสินทรัพย์ระบุว่าข้อมูลภูมิศาสตร์เป็นคุณลักษณะของโปรไฟล์ โดยมีเงื่อนไขกำกับว่า "ในกรณีที่อุตสาหกรรมและข้อกำหนดด้านความเป็นส่วนตัวของคุณอนุญาต"
คู่มือการเชื่อมต่อระบุสิทธิ์ของ Braze API key ที่การเชื่อมต่อนี้ใช้งาน ซึ่งไม่ใช่ทั้งหมดที่เป็นแบบอ่านอย่างเดียว /users/track อัปเดตคุณลักษณะที่กำหนดเองบนโปรไฟล์ผู้ใช้ และ /messages/send ส่งตัวแปรที่แนะนำผ่านแคมเปญ API
เส้นทางของ Klaviyo ต้องการ Private API key ที่มีสิทธิ์เข้าถึงโปรไฟล์แบบเต็ม (Full Access to Profiles) ส่วนเส้นทางของ Salesforce Marketing Cloud กำหนดให้คุณต้องระบุ Extension ID และ API key ให้กับทีม AI Decisioning Services

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

คุณควรสร้างฟีเจอร์ใดบ้างสำหรับเอเจนต์?

Braze อธิบายประเภทฟีเจอร์ไว้ 4 ประเภท ได้แก่ การทำโปรไฟล์ผู้ใช้ (user profiling), ความโน้มเอียงของผู้ใช้ (user propensity), พฤติกรรมผู้ใช้ (user behavioural) และสภาพแวดล้อม (environmental) ฟีเจอร์การทำโปรไฟล์จะเก็บข้อเท็จจริงเชิงวัตถุเกี่ยวกับสถานะ ส่วนฟีเจอร์ความโน้มเอียงจะเป็นคะแนนที่ได้จากแบบจำลอง ฟีเจอร์พฤติกรรมจะสรุปกิจกรรมในช่วงเวลาหนึ่ง และฟีเจอร์สภาพแวดล้อมจะนำสัญญาณภายนอกที่เกี่ยวข้องกับลูกค้ามาใช้

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

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

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

คุณควรสำรองข้อมูลย้อนหลัง (backfill) อย่างไร?

Braze ระบุว่าฟีเจอร์ใหม่ การกู้คืนข้อมูล และการเปลี่ยนแปลงตรรกะเป็นเหตุผลทั่วไปที่ต้องมีการสำรองข้อมูลย้อนหลัง ช่วงเวลาที่ย้อนกลับไปดู (lookback window) จะวัดเป็นเดือนและขึ้นอยู่กับความต้องการในการฝึกฝนของแบบจำลอง ทีม AI Decisioning Services จะเป็นผู้ยืนยันสำหรับกรณีการใช้งานของคุณ โดยโพสต์นี้ไม่ได้ระบุตัวเลขที่ตายตัว

มีมาตรฐานที่ต้องปฏิบัติตามสองประการ คือ ภาพรวมข้อมูลย้อนหลัง (historical snapshots) ต้องมาจากกระบวนการที่สอดคล้องกับการสร้างภาพรวมข้อมูลแบบเรียลไทม์อย่างสมบูรณ์ และโครงสร้างข้อมูล (schema) ต้องตรงกับไปป์ไลน์รายวัน รวมถึงฟิลด์ ประเภทข้อมูล และชื่อคอลัมน์

Braze เรียกการรั่วไหลของข้อมูล (data leakage) ว่าเป็นข้อผิดพลาดที่ร้ายแรงที่สุดในการสำรองข้อมูลย้อนหลัง ตัวอย่างเช่น ฟีเจอร์มูลค่าตลอดช่วงชีวิตลูกค้า (lifetime value) ที่สร้างจากยอดใช้จ่ายรวมจนถึงปัจจุบัน แล้วนำไปใช้ทำนายพฤติกรรมจากหลายเดือนก่อน วิธีแก้ไขคือการสร้างฟีเจอร์ย้อนหลังแต่ละรายการขึ้นใหม่จากข้อมูลที่มีอยู่ ณ ช่วงเวลานั้นๆ

งานสำรองข้อมูลย้อนหลังที่ล้มเหลวระหว่างดำเนินการและถูกเริ่มใหม่ อาจทำให้เกิดบันทึกข้อมูลซ้ำซ้อนได้ ดังนั้นควรออกแบบสคริปต์ทุกตัวให้เป็นแบบ Idempotent เพื่อให้การรันซ้ำสองครั้งให้ผลลัพธ์เหมือนกับการรันครั้งเดียว Braze แนะนำสองรูปแบบคือ การลบแล้วแทรกใหม่สำหรับช่วงเวลาเป้าหมาย หรือการใช้ Upsert โดยอ้างอิงจากรหัสธุรกรรมหรือการประทับเวลาที่ไม่ซ้ำกัน

เราแนะนำให้รันการสำรองข้อมูลย้อนหลังครั้งแรกในสภาพแวดล้อมที่ไม่ใช่การใช้งานจริง (non-production) จากนั้นให้เปรียบเทียบภาพรวมข้อมูลย้อนหลังหนึ่งรายการกับสิ่งที่ไปป์ไลน์แบบเรียลไทม์ควรจะสร้างขึ้นในวันที่ดังกล่าว

การตรวจสอบความพร้อมของข้อมูลมักเกิดข้อผิดพลาดที่จุดใด?

ประเด็นเหล่านี้เป็นการวิเคราะห์ของเราที่เกิดจากการอ่านกฎระเบียบต่างๆ ที่บันทึกไว้เปรียบเทียบกัน Braze ไม่ได้เป็นผู้ให้ข้อมูลเหล่านี้ ดังนั้นโปรดถือว่านี่เป็นเพียงจุดที่คุณควรตรวจสอบ

การทดสอบตัวระบุ (Identifier test) ต้องทำเป็นอันดับแรก การจับคู่ข้อมูลอาจดูเหมือนเป็นแบบหนึ่งต่อกลุ่ม (one-to-many) ในกลุ่มตัวอย่าง แต่อาจมีกรณีที่เป็นแบบกลุ่มต่อกลุ่ม (many-to-many) ซ่อนอยู่ในข้อมูลส่วนท้าย เช่น กรณีหมายเลขบัญชีที่ถูกกำหนดใหม่ โปรดทดสอบตารางการจับคู่ทั้งหมด เพราะเอกสารระบุว่าความคลาดเคลื่อนของตัวตน (identity drift) นำไปสู่สัญญาณการฝึกฝนที่ผิดพลาดและการระบุแหล่งที่มาที่ไม่ถูกต้อง

การหยุดชะงักของข้อมูล (Outages) เป็นเรื่องที่สอง วิธีแก้ไขที่น่าดึงดูดใจหลังจากเกิดช่องว่างของข้อมูลคือการส่งออกข้อมูลใหม่โดยแบ่งตามเวลาของเหตุการณ์ (event time) แต่นั่นจะทำให้เกิดการสูญเสียข้อมูลที่มาถึงล่าช้าตามที่เอกสารเตือนไว้ ดังนั้นควรเรียกใช้ข้อมูลใหม่โดยอิงจากเวลาที่สร้างข้อมูล (creation timestamp) แทน

คำจำกัดความของฟีเจอร์ (Feature definitions) เป็นเรื่องที่สาม หากทีมคลังข้อมูลและทีมดูแลวงจรชีวิตลูกค้าคำนวณจำนวนลูกค้าที่ใช้งานอยู่แตกต่างกัน การเติมข้อมูลย้อนหลัง (backfill) จะทำให้ข้อมูลทั้งสองส่วนปะปนกัน ดังนั้นควรเลือกผู้รับผิดชอบและกำหนดคำจำกัดความให้ชัดเจนเพียงหนึ่งเดียว ก่อนที่จะเริ่มสร้างประวัติข้อมูลใหม่

เส้นทางการเข้าถึงก่อนใคร (Early-access routes) เป็นเรื่องสุดท้าย การวางแผนวันเปิดตัวโดยอิงจากการซิงค์ข้อมูลโดยตรงกับคลังข้อมูลหมายถึงการวางแผนโดยอิงจากสถานะที่เปลี่ยนแปลงได้ ดังนั้นควรใช้เส้นทาง Braze Data Platform เป็นแผนสำรองจนกว่าสถานะจะมีความแน่นอน

การตรวจสอบความพร้อมในทางปฏิบัติเป็นอย่างไร?

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

ผ่าน	สิ่งที่เกิดขึ้นในกรณีสมมติ	ทดสอบทางออกที่คุณทำได้
1. ตัวตน	สร้างการจับคู่จากหมายเลขบัญชีไปยัง Braze external ID และมองหาบัญชีที่จับคู่กับโปรไฟล์มากกว่าหนึ่งโปรไฟล์ รวมหรือบันทึกแต่ละกรณี จากนั้นกำหนดคีย์ให้กับทุกสินทรัพย์ด้วย Braze external ID	ทุกแถวในทุกสินทรัพย์เชื่อมโยงกับหนึ่ง external ID และแต่ละบัญชีที่จับคู่กับหลายโปรไฟล์จะถูกรวมหรือบันทึกไว้
2. เหตุการณ์	ร้านค้าเก็บแอตทริบิวต์ "ส่วนลดล่าสุดที่ส่ง" ไว้ใน Braze ฟิลด์นั้นจะเขียนทับตัวเอง ดังนั้นประวัติการส่งต้องมาจาก Currents ในรูปแบบบันทึกรายบุคคล	สำหรับลูกค้าแต่ละราย คุณสามารถแสดงรายการการส่งทั้งหมดตามลำดับพร้อมกับเวลาของเหตุการณ์และเวลาที่สร้างข้อมูลของแต่ละรายการ
3. ภาพรวม	จำนวนวันที่ไม่ได้สั่งซื้อจะถูกคำนวณใหม่เมื่อมีการสั่งซื้อเข้ามาเท่านั้น สมาชิกที่ไม่ได้ใช้งานคือกลุ่มเป้าหมาย ดังนั้นฟีเจอร์นี้ต้องรีเฟรชตามกำหนดเวลาสำหรับสมาชิกทุกคน	ลูกค้าที่ไม่มีกิจกรรมจะยังคงแสดงค่าฟีเจอร์ตามเวลาที่เปลี่ยนไปในวันพรุ่งนี้
4. การเติมข้อมูลย้อนหลัง	ยอดใช้จ่ายตลอดชีพจะถูกคำนวณจนถึงปัจจุบัน ให้สร้างใหม่ตามสถานะ ณ วันที่ในอดีตแต่ละวัน มิฉะนั้นโมเดลจะฝึกฝนด้วยข้อมูลที่ในขณะนั้นยังไม่มีอยู่	การรันงานสองครั้งให้จำนวนแถวที่เท่ากัน และบันทึกเก่าตรงกับสิ่งที่คุณทราบ ณ วันที่นั้น

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

เราแนะนำว่าอย่าเพิ่งให้เอเจนต์เริ่มออกแบบจนกว่าทั้งสี่ขั้นตอนจะผ่านการตรวจสอบอย่างถูกต้อง

สิ่งนี้เชื่อมโยงกับส่วนที่เหลือของโปรแกรมอย่างไร?

การเลือกชั้นบริการ (Tier) มาเป็นอันดับแรก และคู่มือของเราเกี่ยวกับ การเลือกระหว่าง Decisioning Studio Go และ Pro ได้กำหนดการตัดสินใจนั้นไว้ แผนของเราสำหรับ ฟีเจอร์ AI ของ Braze ที่ควรนำมาใช้ก่อน แสดงให้เห็นว่างานด้านข้อมูลอยู่ในลำดับใด

สำหรับฟีดที่ Pro อ่านข้อมูลจาก การรวมข้อมูล CRM เข้ากับ Brazeและการติดตามเหตุการณ์ของผู้ใช้ใน Braze คือจุดเริ่มต้นในทางปฏิบัติ สุขอนามัยของกลุ่มเป้าหมาย (Segment hygiene) มีความสำคัญสำหรับ Go เพราะกลุ่มเป้าหมายที่เข้ามาไม่ควรถูกนำไปใช้ใน Canvas หรือแคมเปญอื่น คู่มือของเราเกี่ยวกับ การแบ่งกลุ่มผู้ชมใน Braze ครอบคลุมเรื่องนั้นแล้ว

คำแนะนำของ Braze เองเกี่ยวกับ การเตรียมข้อมูลของคุณ คือแหล่งข้อมูลที่ถูกต้องที่สุดสำหรับข้อจำกัดและสถานะทุกอย่างในบทความนี้ โปรดตรวจสอบอีกครั้งก่อนเริ่มวางแผน

คำถามที่พบบ่อย
‍

1. Decisioning Studio Go จำเป็นต้องมีการเตรียมข้อมูลนี้หรือไม่?

หน้าการเตรียมข้อมูลจะกล่าวถึง Pro ตลอดทั้งเนื้อหา โดย Go จะเรียนรู้จากสัญญาณ 3 อย่างที่อยู่ภายใน Braze ทั้งหมด หน้าการตั้งค่าจะขอให้คุณระบุกลุ่มผู้ชมเริ่มต้น (entry segment) ที่ไม่ได้ถูกใช้งานใน Canvas หรือแคมเปญอื่น โดยแนะนำให้มีผู้ใช้อย่างน้อย 20,000 ราย และรองรับได้สูงสุดถึง 40,000,000 ราย

2. ฉันควรใช้ตัวระบุ (identifier) ใดสำหรับ Decisioning Studio Pro?

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

3. ฉันสามารถส่งข้อมูลจากคลังข้อมูล (warehouse) โดยไม่ต้องเพิ่มลงในโปรไฟล์ Braze ได้หรือไม่?

ได้ ผ่านทาง Cloud Data Ingestion โดยมี Decisioning Studio เป็นปลายทาง ซึ่ง Braze ระบุว่าตัวเลือกนี้ยังอยู่ในช่วงการเข้าถึงก่อนใคร (early access) ข้อมูลจากการซิงค์เหล่านี้จะถูกนำไปใช้ใน Decisioning Studio โดยที่โปรไฟล์ผู้ใช้และพื้นที่ทำงานใน Braze ของคุณจะไม่มีการเปลี่ยนแปลง

4. Decisioning Studio รองรับข้อมูลส่วนบุคคลหรือไม่?

คู่มือการใช้งานระบุว่า Decisioning Studio ไม่รองรับข้อมูลที่ระบุตัวตนได้ (PII) ดังนั้นการส่งออกข้อมูลผู้ใช้โดยใช้ external ID จะต้องส่งออกเฉพาะฟิลด์ที่ไม่ใช่ PII เท่านั้น ส่วนการตั้งค่าของคุณจะสอดคล้องกับภาระผูกพันด้านความเป็นส่วนตัวหรือไม่นั้นเป็นอีกประเด็นหนึ่ง ซึ่งบทความนี้ไม่ได้ครอบคลุมถึง

5. ฉันควรย้อนหลังข้อมูล (backfill) ไปไกลแค่ไหน?

กรอบเวลาจะวัดเป็นเดือนและขึ้นอยู่กับความต้องการในการฝึกฝนของโมเดล โดยในหน้าเอกสารไม่ได้ระบุตัวเลขที่ชัดเจน ทีม AI Decisioning Services จะเป็นผู้ยืนยันข้อมูลนี้สำหรับกรณีการใช้งานของคุณ

แหล่งข้อมูล

Braze,ภาพรวมของ Decisioning Studio (Pro). สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,เตรียมข้อมูลของคุณ. สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,หลักการทั่วไป. สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,เชื่อมต่อข้อมูลของคุณ. สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,สินทรัพย์ข้อมูลที่สำคัญ. สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,ภาพรวมข้อมูล (Snapshots) เทียบกับสตรีมเหตุการณ์ (event streams). สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,ใช้ Braze external ID. สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,เลือกฟีเจอร์ที่ดี. สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,แนวปฏิบัติที่ดีที่สุดสำหรับการทำ Backfill. สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,การเชื่อมต่อ BrazeAI Decisioning Studio (คู่มือสำหรับนักพัฒนา). สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,ซิงค์ข้อมูล BrazeAI Decisioning Studio. สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,ตั้งค่าเอเจนต์ Decisioning Studio Go ของคุณ. สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,BrazeAI Decisioning Studio Go. สืบค้นเมื่อ 21 ต.ค. 2026.
Braze,บันทึกประจำรุ่น. สืบค้นเมื่อ 21 ต.ค. 2026.
สถานะการเข้าถึงก่อนใคร (Early-access) ขีดจำกัดของกลุ่มเป้าหมาย และข้อมูลในบันทึกประจำรุ่นได้รับการตรวจสอบเมื่อวันที่ 21 ตุลาคม 2026 ซึ่งอาจมีการเปลี่ยนแปลงได้ โปรดตรวจสอบหน้าเว็บไซต์ของ Braze ปัจจุบันก่อนเริ่มวางแผน
เขียนโดย CustomerIK พันธมิตรด้านการติดตั้งใช้งาน Braze

CustomerIK คือพันธมิตรด้านการติดตั้งใช้งาน Braze ที่เชี่ยวชาญทั้งในด้านการเริ่มต้นใช้งาน การเชื่อมต่อทางเทคนิค การดำเนินงานด้านการตลาด และการจัดการข้อมูลลูกค้า

หากคุณกำลังตัดสินใจว่าข้อมูลของคุณพร้อมรองรับ Pro agent หรือไม่ CustomerIK สามารถช่วยแนะนำขั้นตอนทั้งสี่ให้กับทีมของคุณได้ มาพูดคุยกันเถอะ