Tajo ย้ายข้อมูลจากระบบต้นทางของคุณไปยัง Brevo ผ่านกฎการซิงค์ที่มีการกำกับดูแล: ได้รับอนุมัติจากมนุษย์ ทำงานทิศทางเดียว รันตามกำหนดเวลา และถูกบันทึกตั้งแต่ต้นจนจบ บทความนี้อธิบายว่าสิ่งนั้นหมายความว่าอย่างไรในทางปฏิบัติ และสิ่งที่ไม่รวมอยู่ในนั้น
ตรวจสอบเบื้องต้น บทความนี้สมมติว่าคุณเชื่อมต่อ Shopify และ Brevo แล้ว และเผยแพร่กฎการซิงค์อย่างน้อยหนึ่งรายการแล้ว หากยังไม่ได้ทำ ให้เริ่มที่ เชื่อมต่อ Tajo กับ Shopify
รูปร่างของการซิงค์
การซิงค์ทุกรายการใน Tajo คือ sync rule: คำนิยามที่ผ่านการตรวจสอบและได้รับอนุมัติแล้วว่าอะไรจะย้ายและย้ายอย่างไร กฎหนึ่งข้อมีสี่ส่วนที่คุณตรวจสอบได้บนหน้าของมันภายใต้ Connectors > Syncs:
| ส่วน | ทำหน้าที่อะไร |
|---|---|
| การจับคู่ฟิลด์ | แต่ละฟิลด์ต้นทาง ฟิลด์ใน Brevo ที่มันเขียนไปถึง และการแปลงข้อมูลระหว่างทาง |
| นิพจน์ตัวกรอง | ถูกประเมินทีละเรคคอร์ด เรคคอร์ดที่ไม่ตรงเงื่อนไขจะถูกข้าม |
| Cursor | ติดตามว่าการซิงค์ดำเนินไปถึงไหนแล้ว เพื่อให้การรันแต่ละครั้งเริ่มต่อจากจุดที่ครั้งก่อนหยุดไว้ |
| Run history | การรันทุกครั้ง พร้อมจำนวนเรคคอร์ดที่อ่าน เขียน และล้มเหลว รวมถึงระยะเวลาและสถานะ |
ข้อมูลไหลใน ทิศทางเดียว: จากแหล่งข้อมูลของคุณไปยัง Brevo เท่านั้น Tajo ไม่เขียนข้อมูลกลับไปยัง Shopify
ข้อมูลซิงค์เมื่อไหร่
การรันซิงค์เกิดขึ้นเป็น ชุดข้อมูลตามกำหนดเวลา หรือเมื่อคุณสั่งรันด้วยตนเองจากหน้าของกฎ Tajo ไม่ใช่ไปป์ไลน์แบบเรียลไทม์ การเปลี่ยนแปลงใน Shopify จะไปถึง Brevo ในการรันครั้งถัดไป ไม่ใช่ภายในไม่กี่วินาที นี่คือความตั้งใจ การรันเป็นชุดข้อมูล (batch) คือสิ่งที่ทำให้ทุกการเขียนสามารถตรวจสอบได้ อยู่ภายใต้งบประมาณ และสามารถระบุที่มาไปยังการรันครั้งใดครั้งหนึ่งใน audit trail ได้
การรันแต่ละครั้งจะอ่านเรคคอร์ดใหม่และที่เปลี่ยนแปลงตั้งแต่ตำแหน่ง cursor นำนิพจน์ตัวกรองมาใช้ จับคู่ฟิลด์ และเขียนไปยัง Brevo บันทึกการรันจะแสดงจำนวนเรคคอร์ดที่อ่าน เขียน และล้มเหลวอย่างชัดเจน
การรับประกันด้านการกำกับดูแล
Consent fails closed
กฎการซิงค์ไม่สามารถเผยแพร่ได้หากไม่มีนโยบายความยินยอม และในเวลาที่รัน เรคคอร์ดที่ไม่สามารถพิสูจน์ความยินยอมได้จะไม่ถูกเขียน เมื่อไม่สามารถยืนยันความยินยอมได้ Tajo จะปฏิเสธการเขียนแทนที่จะเดา รูปแบบความล้มเหลวจะเป็น “ระมัดระวังเกินไป” เสมอ ไม่ใช่ “ส่งข้อมูลเกินความจำเป็น”
การรันเป็น idempotent
การเขียนทุกครั้งมี provenance key ที่ได้มาจากเรคคอร์ดต้นทาง (ออกแบบมาให้ไม่มีข้อมูล PII ปะปน) ดังนั้นการรันซิงค์ซ้ำ ไม่ว่าจะหลังความล้มเหลว การหยุดชั่วคราว หรือรันด้วยตนเอง จะไม่สร้างการเขียนซ้ำซ้อน การรันกฎซ้ำจึงปลอดภัยเสมอ
ทุกอย่างถูกตรวจสอบ
การเผยแพร่กฎ การตัดสินใจอนุมัติทุกครั้ง (พร้อมเหตุผลเป็นลายลักษณ์อักษร) และการรันทุกครั้ง จะถูกบันทึกไว้ใน audit trail การอนุมัติที่อนุญาตให้เผยแพร่จะผูกติดกับกฎในเวอร์ชันที่ตรวจสอบพอดี การแก้ไขกฎจะทำให้การอนุมัตินั้นเป็นโมฆะ ดังนั้น audit trail จึงสะท้อนสิ่งที่ได้รับอนุญาตจริงเสมอ
ความล้มเหลวจะหยุดกฎ
หากมีการรันล้มเหลวติดต่อกันหลายครั้ง วงจรตัด (circuit breaker) จะหยุดกฎโดยอัตโนมัติและแสดงข้อผิดพลาดล่าสุดบนหน้าของกฎ ให้แก้ไขสาเหตุแล้วเผยแพร่ใหม่เพื่อให้ทำงานต่อ การรันที่ล้มเหลวบางส่วนจะรายงานจำนวนที่ล้มเหลว เพื่อให้คุณเห็นชัดเจนว่าอะไรไม่ถูกเขียนสำเร็จ
Brevo และการยกเลิกความยินยอม
Tajo ถือว่า Brevo เป็นแหล่งข้อมูลจริง (source of truth) สำหรับความยินยอมทางอีเมล:
- เมื่อผู้ติดต่อยกเลิกการสมัครผ่านลิงก์ในท้ายอีเมลของ Brevo การยกเลิกนั้นจะถูกบันทึกไว้กับผู้ติดต่อคนนั้น และ Brevo จะไม่ส่งแคมเปญให้อีก
- ผู้ติดต่อที่ถูกขึ้นบัญชีดำ (blacklist) ใน Brevo จะยังคงถูกกันออกต่อไป การส่งข้อมูลในภายหลังจะไม่นำพวกเขากลับมา
- Tajo จะไม่ส่งสถานะการยกเลิกกลับไปยัง Shopify หากคุณเก็บความยินยอมทางอีเมลใน Shopify ด้วย ให้จัดการมันแยกต่างหาก อย่าคิดว่าทั้งสองระบบจะสะท้อนข้อมูลเดียวกันเสมอ
มีข้อมูลอะไรบ้าง
สิ่งที่ซิงค์ขึ้นอยู่กับเทมเพลตที่มีให้สำหรับแหล่งข้อมูลของคุณ สำหรับ Shopify รูปแบบทั่วไปคือข้อมูลลูกค้า ทั้งฟิลด์ระบุตัวตนและคุณสมบัติที่มาจากคำสั่งซื้อ เช่น ยอดใช้จ่ายรวมและจำนวนคำสั่งซื้อ จับคู่เข้ากับคุณสมบัติผู้ติดต่อใน Brevo ที่คุณนำไปใช้ใน เซกเมนต์ และแคมเปญได้ การจับคู่ที่แน่นอนสำหรับพื้นที่ทำงานของคุณไม่ได้ซ่อนอยู่ในคำอธิบายใดๆ เปิดกฎการซิงค์แล้วอ่านตารางการจับคู่ฟิลด์ นั่นคือคำตอบที่แท้จริงว่า “อะไรซิงค์บ้าง”
สิ่งที่ Tajo ยังไม่รองรับในวันนี้
การชัดเจนเรื่องขอบเขตสำคัญกว่ารายการฟีเจอร์ที่ยาวเหยียด:
- ไม่มีการซิงค์แบบสองทิศทาง ไม่มีอะไรถูกเขียนกลับไปยัง Shopify ไม่ว่าจะเป็นการยกเลิกความยินยอม แท็ก หรือคะแนนการมีส่วนร่วม
- ไม่มีการซิงค์แบบเรียลไทม์ การรันเป็นชุดข้อมูลตามกำหนดเวลาหรือสั่งด้วยตนเอง ไม่ใช่การสตรีมแบบต่ำกว่าหนึ่งนาที
- ไม่มีการติดตามสินค้าคงคลัง ระดับสต็อกสินค้าไม่ได้ถูกตรวจสอบ และไม่มีทริกเกอร์แจ้งเตือนเมื่อสินค้ากลับมามีในสต็อก
หากขอบเขตเหล่านี้ข้อใดข้อหนึ่งเป็นอุปสรรคต่อการใช้งานของคุณ บอกให้ทีมงานทราบ ลำดับความสำคัญในช่วง early access ถูกกำหนดจากความคิดเห็นแบบนี้โดยตรง
ดูข้อมูลของคุณได้ที่ไหน
- ใน Tajo: เปิดกฎการซิงค์ภายใต้ Connectors > Syncs เพื่อดู run history ตำแหน่ง cursor และจำนวนต่อการรัน audit trail จะบันทึกการเผยแพร่และการอนุมัติ
- ใน Brevo: เปิด Contacts และตรวจสอบคุณสมบัติของผู้ติดต่อคนใดก็ได้เพื่อยืนยันว่าฟิลด์ที่จับคู่ไว้กำลังถูกเติมข้อมูล สร้างเซกเมนต์จากคุณสมบัติเหล่านั้นเพื่อกำหนดกลุ่มเป้าหมาย
การแก้ไขปัญหา
- ผู้ติดต่อไม่ปรากฏใน Brevo: ตรวจสอบการรันล่าสุดของกฎว่ามีความล้มเหลวหรือไม่ และสถานะของกฎ (กฎที่ถูกหยุดไว้จะไม่ทำงาน) ดู ผู้ติดต่อขาดหายไปใน Brevo
- การรันล้มเหลวซ้ำๆ: วงจรตัดจะหยุดกฎและแสดงข้อผิดพลาดล่าสุด ดู ข้อมูลไม่ซิงค์
- ผู้ติดต่อซ้ำซ้อน: การเขียนเป็น idempotent ต่อเรคคอร์ดต้นทาง แต่ข้อมูลซ้ำที่มีอยู่ก่อนแล้วใน Brevo จะยังคงอยู่ ดู ผู้ติดต่อซ้ำ
คำถามที่พบบ่อย
ฉันทำให้การซิงค์เร็วขึ้นได้ไหม? คุณสามารถสั่งรันด้วยตนเองได้ทุกเมื่อจากหน้ากฎการซิงค์ ไม่มีโหมดเรียลไทม์
เกิดอะไรขึ้นถ้าการรันล้มเหลวกลางทาง? การรันจะรายงานจำนวนที่ล้มเหลว cursor จะขยับไปข้างหน้าเฉพาะส่วนที่ประมวลผลแล้ว และการรันครั้งถัดไปจะครอบคลุมส่วนที่เหลืออย่างปลอดภัย กุญแจ idempotency ป้องกันการเขียนซ้ำซ้อน
ฉันเปลี่ยนสิ่งที่ซิงค์ได้ไหม? ได้ แก้ไขการจับคู่ฟิลด์หรือตัวกรองของกฎ การแก้ไขจะสร้างเวอร์ชันใหม่ที่ต้องผ่านการขออนุมัติเผยแพร่อีกครั้งก่อนจะมีผล
ทำไมกฎของฉันถึงหยุดตัวเอง? ความล้มเหลวติดต่อกันทำให้วงจรตัดทำงาน หน้าของกฎจะแสดงจำนวนความล้มเหลวและข้อผิดพลาดล่าสุด ให้แก้ไขปัญหาแล้วเผยแพร่ใหม่
บทความที่เกี่ยวข้อง
- เชื่อมต่อ Tajo กับ Shopify
- พื้นฐานการแบ่งกลุ่ม
- การแก้ไขปัญหา: ข้อมูลไม่ซิงค์
- การแก้ไขปัญหา: ผู้ติดต่อขาดหายไปใน Brevo
ขอความช่วยเหลือ
- Live Chat: ใช้งานได้ในแดชบอร์ด Tajo (มุมขวาล่าง)
- อีเมลสนับสนุน: [email protected]
- เอกสาร: docs.tajo.io