การใช้ Braze Connected Content เพื่อสร้างแคมเปญเฉพาะบุคคล

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

Braze Connected Content ทำงานอย่างไรในระหว่างการเรนเดอร์ข้อความ?

Connected Content จะส่งคำขอเว็บจาก Braze ไปยังเอนด์พอยต์ของคุณในระหว่างการเรนเดอร์ จากนั้นจะใช้ Liquid เพื่อแทรกผลลัพธ์ที่ได้ โดยเขียนคำขอด้วยแท็ก connected_content และบันทึกผลลัพธ์ลงในตัวแปรด้วย :save

จังหวะการทำงานเป็นสิ่งที่ต้องออกแบบเผื่อไว้ เนื่องจาก Connected Content จะทำงานเมื่อข้อความถูกเรนเดอร์ สำหรับข้อความในแอป (In-App Message) จะเกิดขึ้นในขณะที่แสดงผลให้ผู้ใช้เห็น คำขอในเทมเพลตเดียวกันจะทำงานจากบนลงล่าง ดังนั้นคำขอที่ตามมาจึงสามารถใช้ตัวแปรที่คำขอก่อนหน้ากำหนดไว้ได้

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

จะส่งข้อมูลผู้ใช้ไปยังเอนด์พอยต์อย่างปลอดภัยได้อย่างไร?

Braze อนุญาตให้คุณใส่แอตทริบิวต์จากโปรไฟล์ผู้ใช้ลงใน URL ของคำขอได้ โดยค่าของแอตทริบิวต์จะต้องอยู่ภายใน ${} และควรใช้ฟิลเตอร์ url_param_escape กับค่าที่มีอักขระพิเศษ เช่น เครื่องหมาย @ ในอีเมล

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

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

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

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

ทำไมจำนวนคำขอ Connected Content ถึงมากกว่าจำนวนการส่ง?

Braze ระบุว่าหนึ่งการส่งข้อความไม่ได้เท่ากับหนึ่งคำขอ Connected Content และไม่รับประกันอัตราส่วน 1:1 ดังนั้นเอนด์พอยต์ของคุณจึงต้องรองรับจำนวนคำขอที่มากกว่าจำนวนผู้รับจริง

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

Braze ระบุว่าจำนวนผู้รับคูณสองหรือสามมักใช้เป็นค่าประมาณเผื่อสำหรับอีเมล ทั้งนี้ไม่มี Rate Limit แยกเฉพาะสำหรับ Connected Content เนื่องจากจำนวนคำขอจะเพิ่มขึ้นตามอัตราการส่งข้อความ การลด Delivery Speed ของแคมเปญจึงเป็นวิธีช่วยป้องกันไม่ให้เอนด์พอยต์รับภาระหนักเกินไป

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

เอนด์พอยต์ต้องรองรับข้อจำกัดใดบ้าง?

Braze ระบุข้อจำกัดหลักไว้ไม่กี่ข้อ ซึ่งควรตรวจสอบทีละข้อก่อนเริ่มสร้างเทมเพลต

ข้อจำกัดมีดังนี้: เวลาตอบกลับต้องน้อยกว่าสองวินาที มิฉะนั้นจะไม่แทรกเนื้อหา, ขนาดผลตอบกลับต้องไม่เกิน 1 MB, ไม่รองรับการ Redirect, ถือว่าสำเร็จเฉพาะสถานะ 2xx เท่านั้น, รองรับพอร์ต 80 และ 443 เท่านั้น, รองรับเมธอด GET และ POST (สำหรับ Banners ใช้ได้เฉพาะ GET), หากผลตอบกลับเป็น 404 Braze จะแสดงสตริงว่างแทน, และหากเป็น 500 หรือ 502 คำขอจะถือว่าล้มเหลวและเข้าสู่ตรรกะการลองใหม่

กฎเรื่อง Redirect มักทำให้เกิดความสับสน Braze ระบุว่า Postman และไคลเอนต์อื่นๆ มักติดตาม Redirect ให้โดยอัตโนมัติ URL จึงอาจใช้งานได้ใน Postman แต่กลับแสดงผลว่างใน Braze ดังนั้นควรระบุ URL ปลายทางโดยตรงในแท็ก

เมื่อคำขอ Connected Content ล้มเหลวจะเกิดอะไรขึ้น?

มีสามวิธีที่ระบุไว้ในเอกสารซึ่งมีการทำงานแตกต่างกัน ควรเลือกนโยบายให้เหมาะสมกับแต่ละข้อความก่อนเริ่มสร้าง

นโยบายและวิธีตั้งค่าสำหรับสิ่งที่ผู้รับได้รับมีดังนี้: Fallback (ใช้เงื่อนไข Liquid ตรวจสอบตัวแปรที่บันทึกไว้และใช้ข้อความสำรองสำหรับข้อความทั่วไป หรือใช้ตรรกะของคุณเอง โดยสถานะ 404 จะแสดงสตริงว่างอยู่แล้ว) และ Retry (ตัวเลือก :retry) ซึ่งจะเว้นระยะเวลาในการลองใหม่ และยกเลิกหากล้มเหลวครบห้าครั้ง (ไม่รองรับข้อความในแอปหรือ Banners และใช้กับการส่งจริงเท่านั้น ไม่ใช่การพรีวิว) และ Abortabort_message() ซึ่งจะยกเลิกข้อความภายในเงื่อนไขนั้นๆ โดยจะไม่นับรวมในยอดการส่ง และจะแสดงเป็น Liquid abort ใน Messaging Observability

Canvas มีรายละเอียดเพิ่มเติมคือ ใน Message Step ผู้รับจะรอในคิวระหว่างการลองใหม่ หากล้มเหลวครบทุกครั้ง ข้อความจะถูกยกเลิกและผู้ใช้จะไปยังขั้นตอนถัดไป แต่ใน Context และ User Update Step ความล้มเหลวหลังจากลองใหม่จะทำให้ผู้ใช้ออกจาก Canvas ทันที

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

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

{% connected_content https://api.example.com/recommendations?user_id={{${user_id}}} :save connected :retry %}
{% if connected.recommendations.size < 5 %}
  {% abort_message('Could not get enough recommendations') %}
{% endif %}

ตัวเลือกแท็กในตัวอย่างมาจากเอกสารของ Braze ส่วน URL และชื่อฟิลด์เป็นเพียงตัวอย่างที่ต้องแทนที่ด้วยเอนด์พอยต์ของคุณเอง

Braze ยังมีระบบป้องกันโฮสต์ที่มีปัญหา หากมีอัตราความล้มเหลวสูงภายในหนึ่งนาที ระบบจะหยุดคำขอเป็นเวลาหนึ่งนาทีและจำลองผลลัพธ์ว่าล้มเหลว รหัสที่นับรวมคือ 408, 429, 502, 503, 504 และ 529 หากต้องการให้คำขอที่ถูกระงับไว้กลับมาลองใหม่ ให้ใช้ :retry

ควรแคชผลตอบกลับ Connected Content อย่างไร?

Braze แคช GET โดยค่าเริ่มต้น แต่ไม่แคช POST โดยค่าเริ่มต้น อายุแคชปกติคือห้านาที เพิ่มได้ด้วย :cache_max_age สูงสุดสี่ชั่วโมง หรือปิดด้วย no_cache ผลตอบกลับเกิน 1 MB จะไม่ถูกแคช

คีย์แคชประกอบด้วยเวิร์กสเปซ URL ของคำขอ Content Type และ Request Body ไม่ได้ใช้ User ID หรือแคมเปญเป็นคีย์ ผลตอบกลับจึงใช้ซ้ำระหว่างผู้ใช้ แคมเปญ และ Canvas ในเวิร์กสเปซเดียวกันได้เมื่อทั้งสี่ส่วนตรงกัน ระยะเวลาแคชเป็นเพียงแนวทาง เพราะแคชไม่ถาวรและอาจถูกล้างก่อน จึงอาจมีคำขอมากกว่าที่คาดจากอายุแคช

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

Braze ระบุว่าอาจข้ามแคชเมื่อแท็กมีข้อมูลที่มีค่าหลากหลายสูง ได้แก่ User ID, Braze ID, email, email address, phone number และ date of birth ควรประเมินกำลังรองรับของคำขอเหล่านี้เสมือนว่าไม่มีแคช

การปิดแคชมีต้นทุน สำหรับเอนด์พอยต์นอกโครงสร้างพื้นฐาน Braze ตัวเลือก no_cache จะไม่เก็บ Response Body ใน Memcached แต่พักในหน่วยความจำของ Worker ระหว่างเรนเดอร์ สูงสุดประมาณ 11 นาที Braze เตือนว่าเอนด์พอยต์จะได้รับคำขอสำหรับทุกข้อความ และความล่าช้าในการส่งอาจเพิ่มหากรองรับคำขอที่พุ่งสูงไม่ได้

ทดสอบ Connected Content ก่อนเปิดแคมเปญอย่างไร?

Connected Content Debugger แสดงคำขอและผลตอบกลับสดของแต่ละคำขอใน Preview and Test Braze เปิดให้ใช้งานทั่วไปวันที่ 17 กันยายน 2026 หลังเริ่ม Early Access วันที่ 20 สิงหาคม 2026 เครื่องมือแสดง URL เมธอด สถานะ Header เพย์โหลด ระยะเวลา และการใช้แคช

ตรวจว่ารองรับช่องทางของคุณหรือไม่ Braze ระบุว่ายังไม่รองรับทุกช่องทาง เช่น KakaoTalk หรือพื้นที่สร้างเนื้อหาบางส่วน เช่น Content Blocks และ Canvas User Update Step

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

ควรตกลงอะไรบ้างก่อนเปิดคำขอแรก?

ในฐานะพาร์ทเนอร์ด้านการติดตั้ง Braze CustomerIK แนะนำให้บันทึกสี่เรื่องก่อนสร้างเทมเพลตแรก

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

เมื่อตกลงรายละเอียดเหล่านี้ได้แล้ว ทั้งสี่ข้อนี้จะช่วยให้ Connected Content กลายเป็นบริการที่มีผู้รับผิดชอบที่ชัดเจน

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

Connected Content นับรวมอยู่ใน Data Points หรือไม่?

Braze ระบุว่าไม่มีการคิดค่าใช้จ่ายสำหรับคำขอ API และไม่นับรวมในการใช้งาน Data Points

เอนด์พอยต์สามารถตอบกลับได้ช้าที่สุดเท่าใด?

Braze ต้องการผลตอบกลับภายในเวลาไม่เกินสองวินาที หากเกินกว่านั้น ระบบจะไม่แทรกเนื้อหาดังกล่าว

สามารถใช้ฟังก์ชัน Retry กับข้อความในแอปได้หรือไม่?

Braze ระบุว่า :retry ไม่รองรับการใช้งานกับข้อความในแอปหรือแบนเนอร์

เหตุใดบันทึกจึงแสดงจำนวนคำขอมากกว่าจำนวนผู้รับ?

Braze อาจมีการเรียกซ้ำต่อผู้รับหนึ่งราย เช่น สำหรับแต่ละส่วนของอีเมล จึงไม่รับประกันอัตราส่วน 1:1 กับจำนวนการส่งจริง

Braze มีการจัดเก็บผลตอบกลับจากเอนด์พอยต์หรือไม่?

Braze ระบุว่าไม่มีการจัดเก็บ Response Body อย่างถาวร แต่อาจมีการพักข้อมูลไว้ชั่วคราวเพื่อการเรนเดอร์และแคช ข้อความสุดท้ายอาจถูกจัดเก็บผ่านฟีเจอร์ Message Archiving หรือ Content Cards และเมทาดาทาของคำขอรวมถึง URL ที่เรนเดอร์แล้วอาจถูกเก็บไว้สูงสุด 30 วัน

Braze สามารถนำคำตอบที่แคชไว้ของผู้ใช้คนหนึ่งไปใช้กับอีกคนได้หรือไม่?

ระบบแคชจะพิจารณาจากเวิร์กสเปซ URL, Content Type และ Request Body ไม่ใช่ User ID ดังนั้นจึงสามารถนำมาใช้ซ้ำได้หากข้อมูลเหล่านี้ตรงกัน หากต้องการให้คำตอบเฉพาะเจาะจงสำหรับผู้ใช้แต่ละราย ควรใส่ข้อมูลนั้นไว้ใน URL หรือ Body หรือใช้ no_cache

แหล่งข้อมูล

Braze, การเรียกใช้ Connected Content API. สืบค้น 1 ตุลาคม 2026.
Braze, การแคชการตอบกลับของ Connected Content. สืบค้น 1 ตุลาคม 2026.
Braze, การใช้ตรรกะการลองใหม่ (Retry Logic) สำหรับ Connected Content. สืบค้น 1 ตุลาคม 2026.
Braze, การยกเลิก Connected Content. สืบค้น 1 ตุลาคม 2026.
Braze, ตัวแปร Connected Content ในเครื่อง. สืบค้น 1 ตุลาคม 2026.
Braze, เครื่องมือดีบั๊ก Connected Content. สืบค้น 1 ตุลาคม 2026.
Braze, What's new in Braze. สืบค้น 1 ตุลาคม 2026.

บทความที่เกี่ยวข้อง: การทำ Hyper-Personalization ใน Braze، การส่งมอบ Dynamic Content، การติดตามอีเวนต์ผู้ใช้، ข้อมูล CRM ใน Braze، ทริกเกอร์ข้อความในแอป