ด้านเทคนิคของการแบ่งกลุ่มลูกค้า – การซิงโครไนซ์ข้อมูล

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

สารบัญ:

1. ความซับซ้อนของการจัดเก็บและรูปแบบ
2. รูปแบบข้อมูล
3. ความถี่การซิงโครไนซ์
4. สื่อซิงโครไนซ์ข้อมูล
5. API แรกของโลก
6. ทริกเกอร์การซิงโครไนซ์ข้อมูล
   

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

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

คำพูดที่ฉลาดหลายคำหมายความว่าโดยพื้นฐานแล้วเป็นโดเมนของทีมวิศวกร แต่การทำตัวเองให้คุ้นเคยกับแนวคิดหลักช่วยได้มาก นี่คือภาพรวม:

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

ความซับซ้อนของการจัดเก็บและรูปแบบ

เนื่องจากการพัฒนาเทคโนโลยีล่าสุด ค่าใช้จ่ายในการจัดเก็บข้อมูลจึงลดลง สิ่งนี้ทำให้องค์กรสามารถรวบรวมข้อมูลจำนวนมหาศาลได้

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

การจัดเก็บข้อมูลที่มีโครงสร้างส่วนใหญ่หมายถึง ฐานข้อมูล SQL หรือ ไฟล์ Excel เป็นเครื่องมือที่ยอดเยี่ยมและใช้งานได้หลากหลาย แต่ก็มีข้อเสียเช่นกัน SQL นั้นเรียนรู้ได้ยากสำหรับผู้ที่ไม่มีพื้นฐานทางเทคนิค ข้อได้เปรียบและความยืดหยุ่นสูงสุดของ Excel กลายเป็นฝันร้ายสำหรับการบำรุงรักษาความสมบูรณ์ของข้อมูลในระยะยาว นั่นเป็นสาเหตุที่เครื่องมือซอฟต์แวร์เอนกประสงค์เหล่านี้ได้รับการปรับโครงสร้างขั้นสูงด้วยเครื่องมือที่มุ่งเน้นมากขึ้น เช่น CRM, CMS, ERP หรือเครื่องมือวิเคราะห์

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

นี่คือเหตุผลที่กระบวนการซิงค์ข้อมูลส่วนใหญ่ต้องการ คนกลาง ปรับรูปแบบข้อมูลที่สร้างโดยซอฟต์แวร์การเขียน (เรียกว่า "ต้นทาง" ในโลกไอที) เป็นรูปแบบปลายทาง ("เป้าหมาย") กระบวนการของการปรับตัวดังกล่าวเรียกว่า ETL เป็นตัวย่อจาก Extract (ข้อมูลจากต้นทาง) แปลง (ในลักษณะที่เป้าหมายรับรู้และยอมรับ) โหลด (ไปยังเป้าหมายที่รักษาความสอดคล้องของข้อมูล)

รูปแบบข้อมูลประเภทใดที่คุณจะพบในอุตสาหกรรมการแบ่งกลุ่มลูกค้า

รูปแบบข้อมูล

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

CSV – ค่าที่คั่นด้วยจุลภาค ลองนึกภาพว่าคุณนั่งโต๊ะ ตารางปกติจาก MS Word นั้นใช้ได้ ตอนนี้เรามาลบเส้นขอบภายนอกและแทนที่เส้นขอบภายในด้วยเครื่องหมายจุลภาค Voila คุณเพิ่งสร้างไฟล์ CSV

ข้อได้เปรียบที่ใหญ่ที่สุด? ความเรียบง่ายและความกะทัดรัด นักพัฒนาสามารถส่งออกข้อมูลในรูปแบบนี้ได้อย่างง่ายดาย เนื่องจากฐานข้อมูล SQL และ Excel เก็บข้อมูลในตาราง

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

เนื่องจากการเปลี่ยนแปลงที่เทคโนโลยีการตลาดได้รับในช่วงไม่กี่ปีที่ผ่านมา ข้อจำกัดนี้จึงกลายเป็นอุปสรรคสำคัญ

ด้วยเหตุนี้ ระบบสมัยใหม่จึงเริ่มแลกเปลี่ยนข้อมูลกับข้อมูล XML และ JSON ทั้งสองใช้แนวคิดเดียวกันในการแสดงข้อมูล เราจะอธิบายอย่างหลังเพราะเป็นที่นิยมมากกว่า

นี่คือตัวอย่างไฟล์ JSON เมื่อเราเปรียบเทียบไฟล์ JSON กับไฟล์ CSV เราจะพบความคล้ายคลึงกันในทันที เราจะเห็นว่าไฟล์นี้จัดเก็บข้อมูลเดียวกันทุกประการ

ความแตกต่างที่โดดเด่นคือชื่อคอลัมน์จากไฟล์ CSV ซ้ำกัน แม้ว่าสิ่งนี้อาจดูซ้ำซากและขัดขวางความสามารถในการอ่านของมนุษย์ แต่การทำซ้ำที่ให้ความยืดหยุ่นของ JSON - ทำให้การเรียงลำดับของรายการไม่เกี่ยวข้อง สิ่งนี้มีประโยชน์หากคุณต้องการเพิ่มคุณสมบัติใหม่ (คอลัมน์) ให้กับไฟล์ที่แลกเปลี่ยน ซอฟต์แวร์เป้าหมายที่คาดหวังคุณสมบัติใหม่จะใช้มัน ในขณะที่เป้าหมายที่ประมวลผลไฟล์ก่อนการเพิ่มคอลัมน์ จะละเว้นคุณสมบัติใหม่และจะทำงานโดยไม่ถูกรบกวน

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

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับไฟล์ JSON ได้ที่นี่

ความถี่การซิงโครไนซ์

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

ในการบรรลุเป้าหมายนั้น การจัดเก็บข้อมูลพื้นฐานได้นำ การซิงโครไนซ์แบบเรียลไทม์ มาใช้

อย่างไรก็ตาม มีความท้าทายสองประการในการซิงโครไนซ์แบบเรียลไทม์ที่ควรคำนึงถึง

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

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

สื่อซิงโครไนซ์ข้อมูล

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

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

เพื่อให้มีความเฉพาะเจาะจงมากขึ้น แพลตฟอร์มซอฟต์แวร์ที่ทันสมัยใช้ Hypertext Transfer Protocol (HTTP) ซึ่งเป็นรากฐานของเวิลด์ไวด์เว็บ

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

โดยสรุป คุณสามารถปฏิบัติต่อโปรโตคอล HTTP ได้เสมือนเป็นแนวทางในการบอกนักพัฒนาว่าพวกเขาส่งข้อมูลผ่านอินเทอร์เน็ตอย่างไร ที่ด้านบนของ HTTP นักพัฒนาสร้าง Application Programming Interfaces (APIs) ซึ่งเป็นคำอธิบายเฉพาะของข้อมูลใดและในลำดับใดที่สามารถแลกเปลี่ยนระหว่างสองระบบได้

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

มาเล่นกับ API กัน

API แรกของโลก

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

แม้ว่าจะเป็นงานของนักพัฒนา แต่การดำน้ำในหัวข้อนี้อาจช่วยให้คุณสำรวจโลกของเทคโนโลยีการตลาดได้

เราได้สร้างบทความเฉพาะที่มีตัวอย่างเชิงปฏิบัติเกี่ยวกับการทำความเข้าใจ API ดังนั้นหากคุณต้องการเชี่ยวชาญ (และควรทำอีกครั้ง) ให้อ่าน ที่ นี่

นี่คือข้อความที่ตัดตอนมาที่สำคัญที่สุด:

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

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

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

กลับมาที่การซิงโครไนซ์ คำถามที่เหลืออยู่ในตอนนี้คือการค้นหาว่าระบบสองระบบควรแลกเปลี่ยนข้อมูลภายใต้เงื่อนไขใด

ทริกเกอร์การซิงโครไนซ์ข้อมูล

สมมติว่าเรามีเซิร์ฟเวอร์แอปพลิเคชันสองเครื่องพร้อมที่จะแลกเปลี่ยนข้อมูล เพื่อให้เฉพาะเจาะจงมากขึ้น สมมติว่าผู้ให้บริการอีเมลของคุณ ( ESP ) ต้องการทราบจำนวนคำสั่งซื้อของลูกค้า (e-shop) เพื่อส่งคูปองส่งเสริมการขายให้พวกเขาหลังจากคำสั่งซื้อที่สิบ ตอนนี้ เราสามารถนำโฟลว์ข้อมูลประเภทใดไปใช้เพื่อให้บรรลุสถานการณ์นี้ เราสามารถแยกแยะสาม “ทริกเกอร์” ที่สามารถเริ่มต้นเครื่องจักรคูปองอีเมลทางฝั่ง ESP

ก) การสำรวจข้อมูล - ในกรณีนี้ ESP ถาม e-shop API ซ้ำๆ: "แจ้งให้เราทราบจำนวนการสั่งซื้อทั้งหมดสำหรับ Jane Doe" มันทำทุกนาที หนึ่งชั่วโมง หรือหนึ่งวัน เป็นต้น เมื่อ ESP ได้รับข้อมูล มันจะคำนวณเงื่อนไขการส่งคูปองใหม่ทุกๆ คำขอของ API ความรู้สึกอุทรของคุณถูกต้องถ้าคุณคิดว่านี่อาจไม่เหมาะที่จะเรียกและประมวลผลข้อมูลด้วยวิธีนี้ ทางเลือกคืออะไร?

b) การผลักข้อมูล – จะเกิดอะไรขึ้นหากร้านค้าออนไลน์สามารถแจ้งแอปพลิเคชัน ESP ได้ในทันทีที่ Jane ทำการสั่งซื้อครั้งที่ 10 ของเธอ ถูกตัอง. แพลตฟอร์มอีคอมเมิร์ซสมัยใหม่ตระหนักถึงข้อบกพร่องเหล่านี้และรวมการแจ้งเตือนดังกล่าวไว้ในชุดคุณลักษณะ โดยปกติแล้วจะเรียกว่า เว็บฮุค หรือการโทรออก เป็นฟังก์ชันที่เรียบง่ายแต่ทรงพลัง ช่วยให้คุณกำหนดได้ว่าเมื่อใดและแอปพลิเคชันใดควรได้รับแจ้งภายใต้เงื่อนไขเฉพาะ คุณยังสามารถกำหนดประเภทของข้อมูลในการแจ้งเตือนได้ — บางครั้งก็สมเหตุสมผลที่จะส่งข้อมูลทั้งหมด แต่บ่อยครั้งเพียงคุณสมบัติที่เปลี่ยนแปลงก็เพียงพอแล้ว

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

เงื่อนไขที่เป็นประโยชน์: เพื่อป้องกันไม่ให้ส่งคำขอไปยังเซิร์ฟเวอร์มากเกินไป ผู้พัฒนาแอปพลิเคชันจึงใช้ ตัวจำกัดอัตรา กับแอปพลิเคชันของตน จำกัดจำนวนการเรียก API ในช่วงเวลาที่กำหนด เช่น การเรียก 5,000 ครั้งต่อนาที บ่อยครั้ง การโทรที่เกินโควต้าจะถูก ควบคุม ปริมาณ ซึ่งหมายความว่าในที่สุดพวกเขาจะเสิร์ฟ (แทนที่จะทิ้งทั้งหมด) แต่อาจมีความล่าช้าบ้าง

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