การปรับแต่งเนื้อหาในระดับสเกล: การใช้ Braze Liquid Tags

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

‍

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

• Braze จะประมวลผลองค์ประกอบของข้อความแต่ละส่วนแยกกัน ดังนั้นคุณต้องใส่โค้ด Liquid ซ้ำในทุกฟิลด์ที่ต้องการให้แสดงค่า
• Content Blocks ที่แทรกผ่าน Liquid จะยังคงเชื่อมโยงกับบล็อกต้นฉบับอยู่เสมอ ในขณะที่บล็อกที่ใช้วิธีลากวางจะถูกตัดการเชื่อมต่อและคงเวอร์ชันเดิมไว้
• Liquid รองรับเฉพาะอักขระแบบตรง (straight characters) เท่านั้น ดังนั้นควรปิดการใช้งานฟีเจอร์ Smart Quotes และ Smart Dashes บนทุกเครื่องที่ใช้แก้ไขงานใน Braze
• ใช้เครื่องหมายยัติภังค์ (hyphens) ภายในตัวคั่นแท็ก หรือใช้คำสั่งเงื่อนไขแบบบรรทัดเดียว เพื่อป้องกันไม่ให้ Liquid เพิ่มบรรทัดว่างโดยไม่ตั้งใจ
• รักษาขนาดของข้อมูลบริบท (context payloads) ใน Canvas ให้ไม่เกิน 1 KB โดยประมาณ และส่งเฉพาะตัวระบุ (identifiers) แทนการส่งข้อมูลทั้งออบเจกต์
• กำหนดประเภทข้อมูลและค่าสำรอง (fallback) ของแต่ละฟิลด์ให้ชัดเจนก่อนเริ่มเขียนเนื้อหาที่ปรับแต่งเฉพาะบุคคล

‍

อะไรจะเปลี่ยนไปเมื่อการปรับแต่งเนื้อหาด้วย Liquid ใน Braze ถูกนำไปใช้กับข้อความจำนวนมาก?

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

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

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

‍

ทำไมตัวแปรจากหัวข้ออีเมลถึงหายไปในเนื้อหาข้อความ?

Braze ประมวลผลองค์ประกอบของข้อความแต่ละส่วนแยกกัน รวมถึงหัวข้ออีเมล, เนื้อหา HTML, ข้อความพรีเฮดเดอร์ และหัวข้อการแจ้งเตือนแบบ Push การใช้คำสั่ง assign หรือ capture ในฟิลด์หนึ่งจะไม่สามารถนำไปใช้ในอีกฟิลด์หนึ่งได้ วิธีแก้ไขที่ Braze แนะนำคือการใส่โค้ด Liquid หรือการเรียกใช้ Connected Content ซ้ำในแต่ละฟิลด์ที่ต้องการค่านั้นๆ

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

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

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

‍

คุณควรนำ Liquid กลับมาใช้ใหม่ผ่าน Content Blocks อย่างไร?

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

Braze ระบุว่า Content Blocks ที่แทรกผ่าน Liquid จะยังคงเชื่อมโยงกับบล็อกต้นฉบับและแสดงผลการเปลี่ยนแปลงในภายหลัง แต่การลากบล็อกไปวางในข้อความแบบลากและวาง (drag-and-drop) จะยังคงรูปแบบเดิมไว้แต่จะตัดการเชื่อมโยงออก ทำให้การแก้ไขในอนาคตไม่มีผลกับข้อความนั้น ข้อควรพิจารณาคือในส่วนของการแสดงตัวอย่าง (preview) ซึ่งสื่อสำหรับมือถือ (mobile media queries) ในบล็อกที่ติดแท็กไว้อาจแสดงผลไม่เหมือนกัน

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

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

‍

กฎข้อบังคับใดบ้างที่จะช่วยป้องกันไม่ให้ Liquid เกิดปัญหาเมื่อทำงานร่วมกันเป็นทีม?

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

กฎสาเหตุที่พบวิธีบังคับใช้ใช้เครื่องหมายคำพูดแบบตรงเท่านั้นLiquid รองรับเฉพาะอักขระแบบตรง ดังนั้นเครื่องหมายคำพูดและขีดแบบสมาร์ท (smart quotes/dashes) จึงทำให้เกิดข้อผิดพลาดในการแยกวิเคราะห์ ซึ่งมักเกิดจากการตั้งค่า Use smart quotes and dashes บน macOSปิดการตั้งค่านี้บนทุกเครื่องที่ใช้แก้ไข Braze โดยถือเป็นขั้นตอนการเริ่มต้นใช้งานควบคุมช่องว่างโดยค่าเริ่มต้นLiquid แบบหลายบรรทัดในตัวแก้ไขแบบลากและวางจะแสดงการขึ้นบรรทัดใหม่เป็นบรรทัดว่างก่อนการแสดงผลจริงเขียนตัวคั่นแท็กแบบมีเครื่องหมายยัติภังค์ในส่วนของโค้ดที่ใช้ร่วมกันตั้งแต่ต้นบังคับประเภทข้อมูลเมื่อกำหนดค่าประเภทคุณสมบัติของ Canvas context บางประเภทจำเป็นต้องมีการบังคับประเภทข้อมูลก่อนการเปรียบเทียบหรือคำนวณใช้ plus: 0 ในบรรทัดการกำหนดค่า (assign) ห้ามใช้ในส่วนของการเปรียบเทียบห้ามเปรียบเทียบเวลากับค่าว่างLiquid ไม่สามารถเปรียบเทียบออบเจกต์เวลา (time object) กับสตริงได้กำหนดคุณสมบัติเวลาโดยมีค่าเริ่มต้นเป็นสตริงว่าง จากนั้นจึงเปรียบเทียบตัวแปรปีกกาคู่ ห้ามซ้อนกันการมีปีกกาเกินหรือขาดทำให้เกิดข้อผิดพลาด Unexpected end token และทำให้ Liquid ที่เรียกผ่าน API ทำงานผิดพลาดค้นหาปีกกาสามชั้นในทุกส่วนของโค้ดก่อนตรวจสอบเหตุผลการยกเลิกเป็นข้อความคงที่แท็ก abort_message รับค่าเป็นสตริงคงที่ ไม่ใช่ Liquidใส่ตรรกะไว้ก่อนแท็กและรักษาเหตุผลให้ชัดเจนในการรายงาน

‍

เครื่องหมายคำพูดแบบสมาร์ท (smart quotes) เป็นปัญหาอันดับแรกเพราะเกิดจากการตั้งค่าในแล็ปท็อป ดังนั้นความรู้เรื่อง Liquid เพียงอย่างเดียวจึงไม่สามารถป้องกันปัญหานี้ได้

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

‍

Canvas context และข้อมูลทริกเกอร์ควรมีขนาดใหญ่เพียงใด?

Braze ไม่ได้กำหนดขีดจำกัดที่ตายตัวสำหรับคุณสมบัติของ Canvas context แต่แนะนำให้รักษาขนาดข้อมูล (payload) ไว้ไม่เกินประมาณ 1 KB หรือประมาณ 1,000 ตัวอักษร ออบเจกต์ที่มีขนาดใหญ่กว่านี้อาจเพิ่มการใช้หน่วยความจำและทำให้การแสดงผลข้อความล่าช้าในช่วงที่มีการส่งข้อความจำนวนมาก

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

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

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

‍

คุณควรสร้างเทมเพลต Liquid ที่ใช้ร่วมกันตามลำดับใด?

ให้สร้างตามลำดับนี้ เพราะแต่ละขั้นตอนจะช่วยขจัดปัญหาแต่ละประเภทก่อนที่ขั้นตอนถัดไปจะทำให้ปัญหาเหล่านั้นถูกบดบัง

1. ระบุรายการฟิลด์ทั้งหมดที่ข้อความจะแสดงผล รวมถึงข้อมูลโปรไฟล์ เหตุการณ์ หรือบริบทที่แต่ละฟิลด์อ่านค่า
2. กำหนดประเภทของแต่ละค่าและค่าสำรองเมื่อข้อมูลว่างเปล่า รวมถึงกรณีที่เป็นข้อความที่มีเพียงช่องว่าง
3. เขียนส่วนหัวการกำหนดค่า (assign header) สำหรับแต่ละฟิลด์ โดยระบุค่าเริ่มต้นและการบังคับประเภทข้อมูลไว้ในบรรทัดการกำหนดค่า
4. เขียนเงื่อนไขไว้ในบรรทัดเดียวหรือใช้ตัวคั่นแบบขีดกลาง
5. แทรกบล็อกที่ใช้ร่วมกันโดยใช้แท็ก Content Block และจดบันทึกข้อความใดก็ตามที่มีสำเนาที่ถูกลากมาวาง
6. ใช้ฟีเจอร์ Preview as Custom User และป้อนค่าคุณสมบัติเหตุการณ์ตัวอย่างสำหรับแต่ละสถานะ
7. ดูตัวอย่างหัวเรื่อง พรีเฮดเดอร์ และเนื้อหาสำหรับผู้ใช้คนเดียวกันก่อนส่งทดสอบจริง

‍

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

‍

ส่วนหัวของฟิลด์ในทางปฏิบัติมีหน้าตาเป็นอย่างไร?

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

ฟิลด์หัวเรื่องจะมีส่วนหัวของตัวเอง

{%- assign first = {{${first_name}}} | default: 'there' -%} {{ first }} คำสั่งซื้อของคุณกำลังอยู่ระหว่างการจัดส่ง

‍

ฟิลด์เนื้อหาจะทำซ้ำส่วนหัวและเพิ่มสิ่งที่จำเป็นสำหรับเนื้อหาเท่านั้น

{%- assign first = {{${first_name}}} | default: 'there' -%} {%- assign item_count = {{custom_attribute.${open_order_items}}} | plus: 0 -%} {% capture order_line %}{{ item_count }} รายการจากคำสั่งซื้อ {{custom_attribute.${order_id}}}{% endcapture %} สวัสดี {{ first }} {{ order_line }} ได้ถูกจัดส่งแล้ว

‍

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

‍

Liquid มีบทบาทอย่างไรในโปรแกรมที่กว้างขึ้น?

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

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

‍

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

1. ตัวแปร Liquid ส่งผลจากหัวเรื่องไปยังเนื้อหาหรือไม่?

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

2. ทำไมการแก้ไข Content Block ถึงไม่แสดงผลในข้อความบางรายการ?

บล็อกที่ถูกลากมาวางในข้อความแบบลากและวาง (drag-and-drop) จะยังคงรูปแบบเดิมไว้แต่จะถูกตัดการเชื่อมต่อจากบล็อกต้นฉบับ ส่วนบล็อกที่แทรกผ่าน Liquid จะยังคงเชื่อมต่ออยู่และแสดงการเปลี่ยนแปลงในภายหลัง ดังนั้นให้ใช้แท็กนี้หากต้องการให้การแก้ไขมีผลกับข้อความนั้นๆ

3. ทำไมโค้ด Liquid ที่ดูถูกต้องถึงแสดงผลไม่ได้?

สาเหตุที่พบบ่อยคือการใช้เครื่องหมายคำพูดแบบ Smart quotes และขีดแบบ Smart dashes เนื่องจาก Liquid รองรับเฉพาะอักขระแบบตรง (straight characters) เท่านั้น การตั้งค่า Use smart quotes and dashes บน macOS จะแปลงอักขระเหล่านี้โดยอัตโนมัติขณะที่คุณพิมพ์ในแดชบอร์ด

4. ฉันจะลบบรรทัดว่างส่วนเกินที่เกิดจาก Liquid ในตัวแก้ไขแบบลากและวางได้อย่างไร?

ให้เพิ่มเครื่องหมายยัติภังค์ (hyphen) ไว้ภายในตัวคั่นแท็กเพื่อตัดช่องว่างรอบๆ ออก หรือเขียนโค้ด Liquid ไว้ในบรรทัดเดียว ทั้งสองวิธีนี้สามารถใช้ได้กับตัวแก้ไขอีเมล ข้อความในแอป และ Content Blocks

5. คุณสมบัติบริบท (context properties) ของ Canvas มีขนาดใหญ่ได้เท่าใด?

Braze ไม่ได้กำหนดขีดจำกัดที่ตายตัว แต่แนะนำให้รักษาขนาดข้อมูล (payload) ไว้ไม่เกินประมาณ 1 KB หรือประมาณ 1,000 ตัวอักษร ออบเจกต์ที่มีขนาดใหญ่กว่านี้อาจเพิ่มการใช้หน่วยความจำและทำให้การแสดงผลช้าลงในระหว่างการส่งข้อความจำนวนมาก

‍

แหล่งข้อมูล

• Brazeคำถามที่พบบ่อยเกี่ยวกับ Liquid. สืบค้นเมื่อ 14 ต.ค. 2026
• Brazeการตั้งค่าข้อมูลเริ่มต้น (Default values). สืบค้นเมื่อ 14 ต.ค. 2026
• Brazeบล็อกเนื้อหา. สืบค้นเมื่อ 14 ต.ค. 2026
• Brazeการยกเลิกข้อความ (Abort messages). สืบค้นเมื่อ 14 ต.ค. 2026
• Brazeมีอะไรใหม่ใน Brazeตรวจสอบการเปลี่ยนแปลงของ Liquid แล้ว ดึงข้อมูลเมื่อวันที่ 14 ตุลาคม 2026

‍

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

หากคุณกำลังสร้างไลบรารี Liquid แบบแชร์และต้องการให้เราช่วยตรวจสอบ มาคุยกันได้เลย

‍