
หากต้องการขยายขีดความสามารถของ Braze ให้เลือกจุดเชื่อมต่อโดยพิจารณาจากสองคำถาม ได้แก่ ข้อมูลเคลื่อนที่ไปในทิศทางใด และข้อมูลนั้นมีความสดใหม่เพียงใด ข้อมูลจะถูกส่งเข้ามาผ่านทาง SDK, Braze API, Cloud Data Ingestion หรือ Data Transformation และจะถูกส่งออกผ่านทาง Webhooks และ Currents โดยจะแสดงผลในขณะที่ข้อความถูกเรนเดอร์ผ่าน Connected Content และทำงานบนหน้าจอผ่าน JavaScript bridge
ประเด็นสำคัญ
- เลือกจุดเชื่อมต่อ Braze แต่ละจุดโดยพิจารณาจากทิศทางการเคลื่อนที่ของข้อมูลและความสดใหม่ของข้อมูลนั้น
- ควรทำ Batch สำหรับการอัปเดตผ่าน /users/track เนื่องจากแต่ละคำขอสามารถรองรับออบเจกต์ได้สูงสุดถึง 75 รายการ ทั้งในส่วนของแอตทริบิวต์ เหตุการณ์ และการซื้อ
- Connected Content จะเรียกไปยังเอนด์พอยต์ของคุณในขณะที่ข้อความแต่ละฉบับถูกเรนเดอร์ ดังนั้นควรเตรียมขนาดของเอนด์พอยต์ให้รองรับการส่งข้อความจำนวนมากที่สุดของคุณได้
- Braze จะลองส่ง Webhooks ซ้ำเฉพาะในกรณีที่ได้รับคำตอบบางประเภทเท่านั้น เช่น 408, 429 และ 5XX ดังนั้นควรตรวจสอบระบบปลายทางเพื่อหาข้อผิดพลาดจากฝั่งไคลเอนต์ด้วย
- Currents มีการส่งข้อมูลแบบอย่างน้อยหนึ่งครั้ง (at-least-once) ดังนั้นคุณควรจัดการข้อมูลซ้ำโดยใช้ฟิลด์ event id
- ในกรณีที่ใช้ HTML แบบกำหนดเอง คุณต้องเรียกใช้เมธอดคลิกของ JavaScript bridge อย่างชัดเจน มิฉะนั้นรายงานการคลิกสำหรับข้อความนั้นจะไม่แสดงข้อมูล
ในฐานะนักพัฒนา การขยายขีดความสามารถของ Braze หมายความว่าอย่างไร?
Braze มีจุดเชื่อมต่อที่จัดทำเอกสารไว้ให้แล้ว โดยแต่ละจุดมีพฤติกรรมการส่งข้อมูลที่แตกต่างกัน หน้าที่ของนักพัฒนาคือการเลือกจุดที่เหมาะสมที่สุดสำหรับการเชื่อมต่อแต่ละแบบ จากนั้นจึงออกแบบระบบเพื่อรองรับพฤติกรรมของจุดเชื่อมต่อนั้นๆ ในกรณีที่เกิดข้อผิดพลาด
ให้พิจารณาทางเลือกโดยอิงจากทิศทางและเวลา ทิศทางคือการถามว่าข้อมูลกำลังเข้าสู่ Braze, ออกจาก Braze, ถูกดึงมาใช้ในข้อความขณะเรนเดอร์ หรือกำลังทำงานบนหน้าจอของผู้ใช้ ส่วนเวลาคือการถามว่าข้อมูลนั้นเก่าได้แค่ไหนก่อนที่จะถูกนำไปใช้งาน
การตอบคำถามทั้งสองข้อนี้ผิดพลาดอาจนำไปสู่ความเสียหายได้ การใช้การดึงข้อมูลขณะเรนเดอร์ในจุดที่ควรใช้การซิงค์รายวันจะเพิ่มภาระให้กับเอนด์พอยต์ของคุณในทุกครั้งที่มีการส่งข้อความ หรือการใช้การซิงค์แบบกลุ่มในจุดที่ข้อความต้องการสถานะปัจจุบัน จะทำให้ได้ข้อมูลที่เป็นของเมื่อวานแทน
จุดเชื่อมต่อใดเหมาะกับงานประเภทไหน?
แต่ละแถวด้านล่างคือจุดเชื่อมต่อที่มีการจัดทำเอกสารไว้ คอลัมน์สุดท้ายคือพฤติกรรมที่คุณต้องออกแบบระบบมารองรับ ซึ่งเป็นส่วนที่ต้องใช้ความพยายามในการพัฒนามากที่สุด
จุดเชื่อมต่อ ทิศทาง เวลาที่ทำงาน สิ่งที่ต้องออกแบบรองรับ SDK เข้าสู่ Braze เมื่อผู้ใช้ดำเนินการ เหตุการณ์ที่ยังไม่ได้ส่งจะถูกเก็บไว้บนอุปกรณ์และจะลองส่งใหม่หลังจากเชื่อมต่อได้ โดยไม่มีการจำกัดเวลา REST API, /users/track เข้าสู่ Braze เมื่อระบบของคุณเรียกใช้งาน รองรับสูงสุด 75 ออบเจกต์ต่อคำขอ ทั้งในส่วนของแอตทริบิวต์ เหตุการณ์ และการซื้อ Cloud Data Ingestion เข้าสู่ Braze ตามกำหนดเวลาหรือตามคำขอ ช่วงเวลาที่สั้นที่สุดบนแดชบอร์ดคือ 15 นาทีโดยค่าเริ่มต้น เอนด์พอยต์สามารถกระตุ้นการซิงค์ได้ตามต้องการ Data Transformation เข้าสู่ Braze เมื่อบุคคลที่สามส่ง Webhook เขียนข้อมูลผ่าน /users/track และบันทึกจุดข้อมูลในลักษณะเดียวกัน Connected Content เข้าสู่ข้อความ ขณะที่ข้อความถูกเรนเดอร์ คำขอ GET จะถูกแคชไว้โดยค่าเริ่มต้น ไม่รองรับการลองส่งใหม่สำหรับข้อความในแอปหรือแบนเนอร์ Webhooks ออกจาก Braze เมื่อขั้นตอนข้อความส่งข้อมูล ลองส่งใหม่เฉพาะบางคำตอบเท่านั้น ข้อผิดพลาดส่วนใหญ่จากไคลเอนต์จะไม่ถูกลองส่งใหม่ Currents ออกจาก Braze อย่างต่อเนื่อง ส่งข้อมูลแบบอย่างน้อยหนึ่งครั้ง ดังนั้นอาจมีข้อมูลซ้ำเกิดขึ้นได้ JavaScript bridge บนหน้าจอ เมื่อผู้ใช้โต้ตอบ การคลิกในโค้ดที่กำหนดเองจำเป็นต้องมีการเรียกใช้คำสั่งอย่างชัดเจนจึงจะถูกบันทึก
ตารางนี้ยังแสดงให้เห็นถึงสิ่งที่ขาดหายไปจากการเชื่อมต่อแบบเดี่ยว ควรวางแผนให้มีเส้นทางขาเข้าอย่างน้อยหนึ่งเส้นทาง เส้นทางขาออกหนึ่งเส้นทาง และการตัดสินใจเกี่ยวกับข้อมูลที่ใช้ขณะเรนเดอร์
ข้อมูลควรเข้าสู่ Braze อย่างไร?
ใช้ SDK สำหรับทุกสิ่งที่ผู้ใช้ทำในแอปของคุณ เพราะเป็นจุดที่ใกล้ชิดกับการกระทำมากที่สุด Braze ระบุว่า Android, Swift และ Web SDK จะจัดเก็บเหตุการณ์ที่ยังไม่ได้ส่งไว้บนอุปกรณ์และจะลองส่งใหม่หลังจากเชื่อมต่อได้ โดยไม่มีการจำกัดเวลา ดังนั้นเหตุการณ์ที่ล่าช้าจึงเป็นเรื่องปกติ และโมเดลปลายทางใดๆ ควรยอมรับข้อมูลเหล่านี้ได้
ใช้ Braze API เมื่อระบบของคุณเป็นแหล่งข้อมูลหลัก แต่ละคำขอ /users/track สามารถรองรับออบเจกต์ได้สูงสุด 75 รายการรวมกันทั้งแอตทริบิวต์ เหตุการณ์ และการซื้อ ควรทำ Batch อัปเดตให้ถึงขีดจำกัดนั้นแทนการส่งหนึ่งคำขอต่อการเปลี่ยนแปลงหนึ่งครั้ง เพื่อให้จำนวนคำขออยู่ในระดับต่ำ
ใช้ Cloud Data Ingestion เมื่อข้อมูลอยู่ในคลังข้อมูล (Warehouse) อยู่แล้ว โดยค่าเริ่มต้นช่วงเวลาที่สั้นที่สุดบนแดชบอร์ดคือ 15 นาที และเอนด์พอยต์ช่วยให้คุณกระตุ้นการซิงค์ได้เมื่อการทำงานของคลังข้อมูลเสร็จสิ้น ควรตั้งค่าให้กระตุ้นเมื่อจบงานหากทำได้ เพราะตารางเวลาที่กำหนดไว้อาจเริ่มทำงานในขณะที่ข้อมูลยังโหลดไม่เสร็จ
ใช้ Data Transformation เมื่อแพลตฟอร์มของบุคคลที่สามสามารถส่ง Webhooks ได้และคุณไม่สามารถแก้ไขโค้ดของแพลตฟอร์มนั้นได้ โดยจะเปลี่ยนเพย์โหลดของ Webhook ให้เป็นคำขอ Braze API ด้วย JavaScript ซึ่งมีขีดจำกัดอัตราอยู่ที่ 1,000 คำขอต่อนาทีต่อหนึ่ง Workspace การเขียนข้อมูลจะบันทึกจุดข้อมูลเช่นเดียวกับการเรียก /users/track โดยตรง ดังนั้นควรวางแผนงบประมาณสำหรับส่วนนี้ด้วย
คู่มือของเราสำหรับการรวมข้อมูล CRM เข้ากับ Brazeจะเจาะลึกเรื่องการเลือกฟิลด์ที่จะซิงค์ ส่วนการตั้งชื่อเหตุการณ์นั้นครอบคลุมอยู่ในการติดตามเหตุการณ์ของผู้ใช้ใน Braze.
เมื่อใดที่ข้อความควรดึงข้อมูลในขณะที่แสดงผล?
ควรดึงข้อมูลในขณะแสดงผลก็ต่อเมื่อค่าที่ล้าสมัยจะทำให้ข้อความนั้นผิดพลาดเท่านั้น ฟีเจอร์ Connected Content จะเรียกไปยังเอนด์พอยต์ของคุณในขณะที่ข้อความแต่ละข้อความแสดงผล จึงเหมาะสำหรับข้อเสนอ ยอดคงเหลือ และสต็อกสินค้าที่มีการเปลี่ยนแปลงระหว่างการซิงค์ ส่วนข้อมูลอื่นๆ ทั้งหมดนั้น การซิงค์ล่วงหน้าจะประหยัดค่าใช้จ่ายมากกว่า
เอกสารของ Braze ระบุว่า Connected Content รองรับคำขอแบบ get และ post ในขณะที่ Banners รองรับเฉพาะคำขอแบบ get เท่านั้น คำขอแบบ get จะถูกแคชไว้โดยค่าเริ่มต้น ส่วนคำขอแบบ post จะถูกแคชก็ต่อเมื่อคุณกำหนดอายุของแคชไว้เท่านั้น โดยอายุของแคชสามารถตั้งค่าได้ตั้งแต่ห้านาทีไปจนถึงสี่ชั่วโมง
รูปแบบทั้งสองนี้มาจากเอกสารของ Braze โดยตรง
{% connected_content https://api.example.com/user :save user_data %}
{% connected_content https://example.com/webservice.json :cache_max_age 900 %}
เอนด์พอยต์ของคุณจะเป็นผู้รับภาระงาน และนั่นคือส่วนที่คุณต้องวางแผน Braze ไม่มีการจำกัดอัตราการเรียกใช้งาน (rate limit) แยกต่างหากสำหรับ Connected Content และข้อความจะถูกส่งแบบขนานไปทั่วทั้งแคมเปญและ Canvas ของคุณ ดังนั้นควรเตรียมเอนด์พอยต์ให้รองรับปริมาณการส่งสูงสุด ไม่ใช่ค่าเฉลี่ย
การลองส่งซ้ำ (retry) ก็ต้องให้ความสำคัญเช่นกัน ตัวเลือกการลองส่งซ้ำไม่มีให้ใช้งานสำหรับข้อความในแอป (in-app messages) หรือ Banners ในขั้นตอน Canvas Message หากการลองส่งซ้ำทั้งหมดล้มเหลว ข้อความนั้นจะถูกยกเลิกและผู้ใช้จะไปยังขั้นตอนถัดไป
Braze ควรส่งข้อมูลออกอย่างไร?
ใช้ webhooks เมื่อขั้นตอนข้อความจำเป็นต้องทำให้เกิดการดำเนินการในระบบอื่น Braze จะลองส่ง webhook ซ้ำเฉพาะในกรณีที่ได้รับคำตอบบางอย่างเท่านั้น เช่น 408, 429 และ 5XX ส่วนคำตอบอื่นๆ ส่วนใหญ่ รวมถึง 401 Unauthorized จะไม่มีการลองส่งซ้ำ
ควรออกแบบเพื่อรองรับรายละเอียดส่วนสุดท้ายนี้ก่อน ข้อมูลรับรองที่หมดอายุในฝั่งผู้รับมักจะส่งผลให้เกิดข้อผิดพลาด 401 ซึ่งหมายความว่า webhook เหล่านั้นจะไม่ถูกส่งซ้ำ ดังนั้นควรตรวจสอบอัตราข้อผิดพลาดของระบบผู้รับ ไม่ใช่แค่จำนวนการส่งของ Braze และหมั่นเปลี่ยนข้อมูลรับรองก่อนที่จะหมดอายุ
หากคำขอส่วนใหญ่ไปยังโฮสต์หนึ่งล้มเหลว Braze จะระงับการส่งข้อมูลไปยังโฮสต์นั้นชั่วคราวและจะกลับมาส่งใหม่หลังจากช่วงเวลาพัก (cooldown) ซึ่งเป็นการปกป้องระบบของคุณ แต่ก็หมายความว่าหากคุณมีการปรับใช้ (deploy) ที่ผิดพลาด ก็อาจทำให้ webhook ทุกรายการที่ส่งไปยังโฮสต์นั้นหยุดชะงักได้
ใช้ Currents เมื่อคุณต้องการข้อมูลเหตุการณ์จาก Braze ในคลังข้อมูลหรือเครื่องมือวิเคราะห์ Currents จะส่งข้อมูลอย่างน้อยหนึ่งครั้ง ดังนั้นจึงอาจมีข้อมูลซ้ำเกิดขึ้นได้เป็นครั้งคราว ให้ทำการลบข้อมูลซ้ำ (deduplicate) โดยใช้ฟิลด์ event id ที่มาพร้อมกับทุกเหตุการณ์ และประมวลผลไฟล์ทันทีที่ได้รับ แทนที่จะกลับไปสแกนพาร์ทิชันเก่าๆ
การประทับเวลา (timestamps) จะถูกส่งออกในรูปแบบเวลาสากลเชิงพิกัด (UTC) และเหตุการณ์ที่ล่าช้าอาจเข้ามาโดยไม่มีกรอบเวลาสูงสุด ดังนั้นควรสร้างแบบจำลองข้อมูลเหล่านี้ก่อนที่จะมีใครเริ่มทำรายงานประจำวันจากข้อมูลดังกล่าว
แล้วโค้ดที่ทำงานบนหน้าจอของผู้ใช้ล่ะ?
ข้อความในแอปแบบ HTML ที่กำหนดเองและ Banners สามารถสื่อสารกับ Braze SDK ผ่าน JavaScript bridge ได้ นี่คือวิธีที่เลย์เอาต์แบบกำหนดเองจะรายงานสิ่งที่ผู้ใช้ทำกลับไปยัง Braze ส่วนหน้า Landing Page ก็ได้รับฟีเจอร์ JavaScript bridge เช่นกัน ซึ่งระบุว่าพร้อมใช้งานทั่วไปในบันทึกประจำรุ่นวันที่ 20 สิงหาคม 2026
ข้อควรระวังคือการติดตามการคลิก ใน HTML แบบกำหนดเอง SDK ไม่สามารถแนบตัวรับฟังการคลิก (click listeners) เข้ากับองค์ประกอบของคุณได้โดยอัตโนมัติ ดังนั้นการเรียกใช้คำสั่งคลิกของ bridge จึงต้องทำอย่างชัดเจน ให้ถือว่าการลืมใส่คำสั่งคลิกเป็นอุปสรรคในการปล่อยงาน เพราะหากไม่มีคำสั่งนี้ รายงานการคลิกสำหรับข้อความนั้นจะว่างเปล่า
บทความของเราเรื่องการสร้างข้อความในแอปที่น่าสนใจครอบคลุมถึงกรณีที่ควรเลือกใช้ HTML แบบกำหนดเองเพื่อให้คุ้มค่ากับความพยายามในการสร้าง
คุณควรเลือกจุดเชื่อมต่อ (extension point) ตามลำดับอย่างไร?
ให้พิจารณาคำถามเหล่านี้ตามลำดับสำหรับการเชื่อมต่อแต่ละรายการ และหยุดที่คำถามแรกที่ให้คำตอบกับคุณได้
- ข้อมูลเริ่มต้นจากการที่ผู้ใช้ทำกิจกรรมในแอปของคุณใช่หรือไม่? ถ้าใช่ ให้ใช้ SDK
- ระบบของคุณเป็นแหล่งข้อมูลหลักและมีการเปลี่ยนแปลงตามกำหนดเวลาของตัวเองใช่หรือไม่? ถ้าใช่ ให้ใช้ Braze API แบบเป็นชุด (batched)
- ข้อมูลอยู่ในคลังข้อมูล (warehouse) อยู่แล้วใช่หรือไม่? ถ้าใช่ ให้ใช้ Cloud Data Ingestion โดยตั้งค่าให้ทำงานเมื่อการโหลดข้อมูลเสร็จสิ้น
- บุคคลที่สามรองรับเฉพาะ Webhook ใช่หรือไม่? ถ้าใช่ ให้ใช้ Data Transformation
- หากค่าที่ซิงค์ไว้ก่อนหน้านี้อาจทำให้ข้อความผิดพลาดได้ใช่หรือไม่? ถ้าใช่ ให้ใช้ Connected Content โดยปรับขนาดให้เหมาะสมกับปริมาณการส่งที่มากที่สุดของคุณ
- การส่งข้อความควรทำให้เกิดการดำเนินการที่อื่นด้วยหรือไม่? ถ้าใช่ ให้ใช้ Webhook และคอยตรวจสอบฝั่งผู้รับ
- คุณจำเป็นต้องใช้ประวัติเหตุการณ์นอก Braze หรือไม่? ถ้าใช่ ให้ใช้ Currents และทำการขจัดข้อมูลซ้ำ (deduplicate) โดยใช้ event id
จดคำตอบสำหรับแต่ละการเชื่อมต่อพร้อมระบุผู้รับผิดชอบ รายการที่จดไว้นี้จะช่วยให้ผู้อื่นสามารถแก้ไขปัญหาที่อาจเกิดขึ้นในภายหลังได้
ส่วนนี้เชื่อมต่อกับส่วนอื่นๆ ของโปรแกรมอย่างไร?
ข้อมูล ณ เวลาที่แสดงผล (Render-time data) เป็นหนึ่งในรูปแบบที่อยู่ใน7 วิธีในการส่งคอนเทนต์แบบไดนามิก. การส่งข้อความที่กระตุ้นด้วย API ซึ่งเป็นการสิ้นสุดของการเชื่อมต่อหลายๆ รูปแบบนั้น ครอบคลุมอยู่ในการทำอีเมลธุรกรรมอัตโนมัติ.
ในฐานะพันธมิตรด้านการติดตั้งใช้งาน Braze ทาง CustomerIK แนะนำให้ตัดสินใจเรื่องทิศทางและความสดใหม่ของข้อมูลสำหรับการเชื่อมต่อทุกรายการก่อนที่จะเลือกเครื่องมือ เครื่องมือที่เหมาะสมจะตามมาจากคำตอบทั้งสองข้อนั้น รวมถึงวิธีการจัดการข้อผิดพลาดส่วนใหญ่ด้วย
คำถามที่พบบ่อย
1. Data Transformation บันทึก Data Points หรือไม่?
Braze ระบุว่าบันทึกในกรณีส่วนใหญ่ โดยการแปลงข้อมูลแต่ละครั้งจะจบลงด้วยการเรียกใช้ /users/track ซึ่งจะบันทึก Data Points เสมือนว่าคุณได้เรียกใช้ endpoint นั้นโดยตรง
2. Connected Content สามารถลองเรียกซ้ำ (retry) หากการเรียกใช้งานในข้อความในแอป (in-app message) ล้มเหลวได้หรือไม่?
ไม่ได้ ตัวเลือกการลองซ้ำไม่มีให้ใช้งานสำหรับข้อความในแอปหรือแบนเนอร์ ดังนั้นควรออกแบบข้อความเหล่านั้นให้ยังคงอ่านเข้าใจได้แม้ในกรณีที่การเรียกใช้งานล้มเหลว
3. Braze จะลองส่ง Webhook ซ้ำในกรณีใดบ้างหากเกิดความล้มเหลว?
Braze จะลองส่งข้อมูลซ้ำเฉพาะการตอบกลับบางประเภทเท่านั้น เช่น 408, 429 และ 5XX ส่วนการตอบกลับอื่นๆ ส่วนใหญ่ รวมถึง 401 Unauthorized จะไม่มีการลองส่งซ้ำ
4. Currents สามารถส่งเหตุการณ์เดิมซ้ำสองครั้งได้หรือไม่?
ได้ ในบางครั้ง Currents มีการรับประกันการส่งข้อมูลแบบ at-least-once ดังนั้นคุณควรจัดการข้อมูลซ้ำ (deduplicate) โดยใช้ฟิลด์ id ที่ส่งมาพร้อมกับทุกเหตุการณ์
5. คำขอ /users/track หนึ่งรายการสามารถบรรจุออบเจกต์ได้กี่รายการ?
สูงสุด 75 ออบเจกต์รวมกัน ทั้งในส่วนของแอตทริบิวต์ เหตุการณ์ และการซื้อ โดยแต่ละออบเจกต์จะทำการอัปเดตผู้ใช้หนึ่งราย
แหล่งข้อมูล
- Brazeการแปลงข้อมูล. สืบค้นเมื่อ 14 ต.ค. 2026
- Brazeเว็บฮุค (Webhooks). สืบค้นเมื่อ 14 ต.ค. 2026
- Brazeหลักการส่งเหตุการณ์ของ Currents. สืบค้นเมื่อ 14 ต.ค. 2026
- Brazeทำการเรียกใช้งาน Connected Content. สืบค้นเมื่อ 14 ต.ค. 2026
- Brazeการแคชการตอบกลับของ Connected Content. สืบค้นเมื่อ 14 ต.ค. 2026
- Brazeการลองเชื่อมต่อเนื้อหาซ้ำ (Connected Content retries). สืบค้นเมื่อ 14 ต.ค. 2026
- Brazeโค้ดที่กำหนดเองและ JavaScript bridge สำหรับแบนเนอร์. สืบค้นเมื่อ 14 ต.ค. 2026
- Brazeขีดจำกัดของ API. สืบค้นเมื่อ 14 ต.ค. 2026
- Brazeการนำเข้าข้อมูลบนคลาวด์ (Cloud Data Ingestion). สืบค้นเมื่อ 14 ต.ค. 2026
- Brazeมีอะไรใหม่ใน Braze. สืบค้นเมื่อ 14 ต.ค. 2026
CustomerIK คือพันธมิตรด้านการติดตั้งใช้งาน Braze ที่มีความเชี่ยวชาญทั้งในด้านการเริ่มต้นใช้งาน การเชื่อมต่อทางเทคนิค การดำเนินงานด้านการตลาด และการจัดการข้อมูลลูกค้า
หากคุณกำลังวางแผนการเชื่อมต่อระบบ Braze และต้องการให้มีการระบุจุดเชื่อมต่อ (extension points) ก่อนเริ่มการพัฒนา มาคุยกันก่อนได้เลย




