الجوانب الفنية لتجزئة العملاء - مزامنة البيانات

"خبرة واسعة في تحليل وتقسيم قواعد بيانات CRM" ، "فهم قوي لتجزئة الجمهور" ، "فهم وتجربة تقسيم البيانات وخدمة المحتوى المخصص." هذه أمثلة على المتطلبات الأكثر شيوعًا الموضوعة في عروض وظائف تسويق CRM / دورة الحياة. على الرغم من أن مفهوم تجزئة العملاء بسيط إلى حد ما ويسهل البدء به ، فإن التحول إلى محترف تجزئة يتطلب الغوص في التفاصيل الفنية. مع هذه المقالة ، نريد مساعدتك في اتخاذ هذه القفزة.

جدول المحتويات:

1. تعقيد التخزين والشكل
2. تنسيقات البيانات
3. تردد التزامن
4. وسيط مزامنة البيانات
5. API الأول العالم
6. مشغلات مزامنة البيانات
   

يبدأ تقسيم العملاء بجمع بيانات العميل في مكان مركزي واحد وجعلها جاهزة للتجميع والعمل وفقًا لها. يبدو الأمر سهلاً ، لكن العدد المتزايد من مصادر البيانات يضيف تعقيدًا إلى جمع البيانات وطحنها.

لهذا السبب يبدأ التقسيم الفعال بضمان تدفق بيانات متسق من عدة مصادر بيانات إلى خادم واحد. اكتسبت هذه العملية اسمًا ربما سمعته كثيرًا مؤخرًا - مزامنة البيانات أو ببساطة مزامنة البيانات . إنها عملية لتحقيق الاتساق بين الأنظمة والتحديثات المستمرة اللاحقة للحفاظ على التوحيد.

تعني الكثير من الكلمات الذكية أنه مجال الفريق الهندسي في المقام الأول. لكن جعل نفسك على دراية بالمفاهيم الأساسية يساعد كثيرًا. فيما يلي نظرة عامة:

• مزامنة البيانات - في هذا القسم سوف نتعرف على كيفية تخزين بيانات العملاء ، ولماذا يريد الناس تحريكها وما هي العوائق التي تحتاج الفرق الرقمية للتغلب عليها للقيام بذلك. في ملاحظة أكثر عملية ، يشرح هذا الفصل الأجزاء الداخلية لكيفية تبادل أنظمة CRM الحديثة للبيانات عبر الإنترنت باستخدام واجهات برمجة التطبيقات.
• سلامة البيانات وأمانها - سيساعدك الجزء التالي على فهم ما يتطلبه الأمر للحفاظ على البيانات في حالة متسقة بعد مزامنتها. سنتعلم كيف يمكنك استخدام المخطط لرعاية تفرد البيانات ومنع تكرار البيانات. أخيرًا ، سنفكر في الجوانب التقنية لأمن البيانات والخصوصية حيث أصبحوا مواطنين من الدرجة الأولى في أوقات ما بعد القانون العام لحماية البيانات وقانون حماية خصوصية المستهلك.
• معالجة البيانات - أخيرًا ، سنساعدك على أن تصبح بطلاقة من خلال عرض بعض النصائح لك حول تصفية البيانات واتخاذ قرارات تعتمد على البيانات بشكل عام.

تعقيد التخزين والشكل

بسبب التطورات الأخيرة في التكنولوجيا ، انخفضت تكلفة تخزين البيانات. هذا مكن الشركات من جمع كميات هائلة من البيانات.

يمكن تقسيم هذه البيانات إلى فئتين: منظمة وغير منظمة . لإنجاح التجزئة ، تحتاج الفرق الرقمية إلى معرفة كيفية الانتقال من غير منظم إلى منظم.

من خلال تخزين البيانات المنظمة فإننا نعني في الغالب قواعد بيانات SQL أو ملفات Excel . إنها أدوات رائعة ومتعددة الاستخدامات ، ولكن لها عيوبها أيضًا. يصعب تعلم SQL للأشخاص الذين ليس لديهم خلفية تقنية ، وأهم ميزة لـ Excel ، والمرونة ، تصبح كابوسًا لصيانة تكامل البيانات على المدى الطويل. لهذا السبب تم تصميم أدوات البرامج ذات الأغراض العامة هذه باستخدام أدوات أكثر تركيزًا مثل CRM أو CMS أو ERP أو أدوات التحليلات.

على الرغم من أن هذه الأدوات الموجهة للوظيفة تزيد الإنتاجية في المجالات التي تم توظيفهم من أجلها ، فإنها غالبًا ما تصبح مشكلة على مستوى القسم / الشركة. لماذا هذا؟ عادةً ما تستخدم كل أداة من هذه الأدوات تنسيق البيانات الخاص بها ، وما لم يتم دمج كلا النظامين الأساسيين للبرنامج مع بعضهما البعض ، يتم إعاقة تبادل البيانات. ويستخدم المسوق الحديث الكثير من هذه الأدوات.

هذا هو السبب في أن معظم عمليات مزامنة البيانات تتطلب وسيطًا . يقوم بتكييف تنسيق البيانات الذي تم إنشاؤه بواسطة برنامج التأليف (يسمى "المصدر" في عالم تكنولوجيا المعلومات) إلى تنسيق الوجهة ("الهدف"). تسمى عملية هذا التكيف ETL. إنه اختصار من Extract (بيانات من المصدر) ، التحويل (بطريقة يتعرف عليها الهدف ويقبلها) ، تحميل (إلى الهدف مع الحفاظ على اتساق البيانات).

ما نوع تنسيقات البيانات التي يمكنك موافاتها في صناعة تجزئة العملاء؟

تنسيقات البيانات

في الوقت الحاضر ، تستخدم برامج التجزئة تنسيقين مفتوحين لأغراض مزامنة البيانات في معظم الحالات. ولكن ما هو "تنسيق البيانات" على أي حال؟ هذا ليس أكثر من نص منظم بطريقة مفهومة لأجهزة الكمبيوتر. لنبدأ بالأول ، الأبسط.

CSV - قيم مفصولة بفواصل. تخيل أنك أخذت طاولة. الجدول المنتظم من MS Word جيد. الآن دعنا نزيل الحدود الخارجية ونستبدل الحدود الداخلية بفاصلات. فويلا ، لقد قمت للتو بإنشاء ملف CSV.

أكبر ميزة؟ البساطة والاكتناز. يمكن للمطورين تصدير البيانات بسهولة بهذا التنسيق لأن قواعد بيانات SQL و Excel تخزن البيانات في جداول.

من ناحية أخرى ، يحتوي CSV على عيبين رئيسيين. أولاً ، داخل ملف CSV ، لا يمكنك تمثيل التسلسل الهرمي. على سبيل المثال ، لا يمكنك إظهار أن إحدى القيم مرتبطة بأخرى. ثاني أهم عيب هو أن CSV هو تنسيق ثابت. يسمح لك بتبادل البيانات وفقًا للعدد الدقيق ونوع الأعمدة التي حددتها في البداية. إذا قمت بإضافة عمود ضروري لنظام هدف آخر أو قمت ببساطة بإزالة عمود ، فسيؤدي ذلك إلى حدوث خطأ عند محاولة الاستيراد. في مثل هذه الحالة ، سيحتاج المطورون إلى تعديل الكود ليعكس التغييرات الهيكلية.

بسبب الديناميكيات التي اكتسبتها تكنولوجيا التسويق في السنوات الأخيرة ، تبين أن هذا القيد يمثل عقبة رئيسية.

لهذا السبب ، بدأت الأنظمة الحديثة في تبادل البيانات مع بيانات XML و JSON . كلاهما يعتمد على نفس مفهوم تمثيل البيانات. سنصف الأخير لأنه أكثر شيوعًا.

هذا مثال لملف JSON. عندما نقارن ملف JSON الخاص بنا بملف CSV ، سنجد على الفور أوجه تشابه - يمكننا أن نرى أن هذا الملف يخزن البيانات نفسها تمامًا.

الاختلاف اللافت للنظر هو أن أسماء الأعمدة من ملفات CSV تتكرر. في حين أن هذا قد يبدو زائدًا عن الحاجة ويعيق إمكانية القراءة للبشر ، إلا أن التكرار هو الذي يمنح JSON مرونة - فهو يجعل ترتيب العناصر غير ذي صلة. هذا مفيد إذا كنت بحاجة إلى إضافة خاصية جديدة (عمود) إلى ملف متبادل. البرنامج المستهدف الذي يتوقع الخاصية الجديدة سيستهلكها ، في حين أن الأهداف التي عالجت الملف قبل إضافة العمود ، ستتجاهل الخاصية الجديدة وستعمل دون إزعاج.

تضمن هذه الميزة أنه إذا قمت بإضافة المزيد من الحقول إلى تنسيق البيانات المرسل بواسطة التطبيق المصدر ، فلن يؤدي ذلك إلى كسر الهدف. هذا هو السبب في أن تنسيق JSON أكثر قابلية للتطوير وأكثر مرونة من CSV .

يمكنك قراءة المزيد عن ملفات JSON هنا.

تردد التزامن

الشرط الشائع اليوم هو أن أنظمة التجارة الإلكترونية تعمل في الوقت الفعلي . يريد العملاء معرفة حالة طلباتهم ، أو تتبع الطرود في الوقت الفعلي أو الرصيد الحالي في حسابهم. أيضًا ، يريد المسوقون التفاعل بسرعة ، فهم يريدون تشغيل حملات في الوقت الفعلي تخلق تجارب تسوق في الوقت المناسب.

لتحقيق ذلك ، اعتمدت مخازن البيانات الأساسية المزامنة في الوقت الفعلي .

ومع ذلك ، هناك تحديان في المزامنة في الوقت الفعلي يجب أن تضعهما في اعتبارك.

أولاً ، قاعدة عامة - كلما أردت الحصول على توقيت حقيقي أكثر ، زادت تكلفته . تتجلى هذه التكلفة في وقت المطورين ولكن أيضًا مع الأجهزة التي تدير الخوادم (اليوم هي حلول سحابية في الغالب) تحتاج إلى الحفاظ على تشغيل أنظمة مزامنة البيانات. لذا ، فإن مهمتك الأولى قبل وضع شرط "الوقت الفعلي" عند التحدث إلى المهندسين هي التفكير في نوع تردد مزامنة البيانات الذي تحتاجه حقًا. ربما تكون التحديثات المرسلة مرة كل ساعة أو مرة واحدة في اليوم كافية لضمان تجربة عملاء رائعة مع تقليل عمل المطورين وتوفير الميزانية.

التحدي الآخر هو قدرات استخراج البيانات لمخازن البيانات التي تعمل معها. في بعض الأحيان ، قد يتم إعاقة المزامنة في الوقت الفعلي عندما لا يوفر أحد الأنظمة طريقة سهلة لاستخراج البيانات. سهل المعنى صديق للمطورين. دعنا نحلل هذه المشكلة بالتفصيل من خلال استعراض كيفية قيام المطورين بنقل البيانات حول الأنظمة.

وسيط مزامنة البيانات

لقد تعلمنا كيف يتم تخزين البيانات ، وما هي التنسيقات المستخدمة للتبادل ، وكيف يمكن أن يؤثر تكرار المزامنة على جهود إعداد نظام المزامنة بالكامل. ولكن ما الذي يتطلبه الأمر بالفعل لنقل البيانات من قاعدة بيانات إلى أخرى؟ حسنًا ، أنت بحاجة إلى وسيط.

يمكن أن يكون تخزينًا ماديًا مثل DVD أو محرك أقراص USB أو مزامنة أخرى قائمة على الأجهزة ، ولكن مع الكميات الهائلة من البيانات ومتطلبات المزامنة في الوقت الفعلي ، فإن القليل يفعل ذلك بهذه الطريقة اليوم. في معظم الحالات ، يتم كل ذلك عبر الكابل ، أو في الواقع العديد من الكابلات المتصلة ببعضها بواسطة أجهزة كمبيوتر حول العالم - تسمى الإنترنت.

لكي تكون أكثر تحديدًا ، تستخدم منصات البرامج الحديثة بروتوكول Hypertext Transfer Protocol (HTTP) الذي يعد أساس شبكة الويب العالمية.

إذا كنت مهتمًا (ومن الأفضل أن تكون!) في كيفية اتصال الخوادم مع بعضها البعض عبر الإنترنت ، فإننا نوصي بشدة بالانتقال إلى دليل الخوادم غير التقني.

باختصار ، يمكنك التعامل مع بروتوكول HTTP مثل الإرشادات التي تخبر المطورين بكيفية إرسال البيانات عبر الإنترنت. علاوة على HTTP ، يقوم المطورون بإنشاء واجهات برمجة التطبيقات (APIs) والتي تعد أوصافًا محددة للبيانات والترتيب الذي يمكن تبادله بين نظامين.

يُطلق على البرنامج الذي يجعل واجهة برمجة التطبيقات (API) متاحة على الإنترنت ويسهل الوصول إليها بواسطة أنظمة أخرى (على غرار الطريقة التي تزور بها صفحة ويب عادية) خادم التطبيقات. كل ما يفعله هو الاستماع والاستجابة للطلبات التي تأتي من خوادم التطبيقات الأخرى ، واعتمادًا على الطلب ، فإنه يضيف أو يحصل على معلومات من قاعدة البيانات الأساسية. معلومات مفيدة: عندما يذكر الأشخاص واجهة برمجة التطبيقات (API) ، غالبًا ما تكون اختصارًا لخادم التطبيق الذي يعرض واجهة برمجة التطبيقات (API) للإنترنت.

دعونا نلعب مع واجهات برمجة التطبيقات بعد ذلك.

API الأول العالم

أصبحت واجهات برمجة التطبيقات (API) لغة مشتركة للتسويق الرقمي في الوقت الحاضر. معظم أعمال مزامنة البيانات اليوم تتعلم API لتتمكن من استخراج البيانات منها. إنه يشبه تعلم مجموعة أخرى من الكلمات من لغة أجنبية ، بافتراض أنك تعرف القواعد ، والتي يتم تعريفها في هذه الحالة بواسطة HTTP.

على الرغم من أنها وظيفة مطور ، إلا أن الغوص في هذا الموضوع قد يساعدك على التنقل في عالم تكنولوجيا التسويق.

لقد أنشأنا مقالًا مخصصًا به بعض الأمثلة العملية حول فهم واجهات برمجة التطبيقات ، لذلك إذا كنت تريد إتقانها (ومرة أخرى ، يجب عليك ذلك) ، قم بقراءتها هنا .

وهذا أهم مقتطف منه:

إذا ذهبت إلى مطعم كعميل ، فلن يُسمح لك بدخول المطبخ. تحتاج إلى معرفة ما هو متاح. لذلك ، لديك القائمة. بعد الاطلاع على القائمة ، تقوم بإصدار طلب للنادل ، الذي يمررها إلى المطبخ ثم يقوم بتسليم ما طلبته. يمكن للنادل تقديم ما يمكن أن يوفره المطبخ فقط.

كيف يرتبط ذلك بواجهة برمجة التطبيقات؟ النادل هو API. أنت شخص يطلب الخدمة. بمعنى آخر ، أنت عميل API أو مستهلك. القائمة هي الوثائق التي تشرح ما يمكنك أن تطلبه من API. المطبخ ، على سبيل المثال ، خادم ؛ قاعدة بيانات لا تحتوي إلا على نوع معين من البيانات - أيًا كان ما اشتراه المشتري للمطعم كمكونات وما قرر الشيف أنه سيقدمه وما يعرف الطهاة كيفية تحضيره. "

• المطبخ - قاعدة البيانات ، لا يسمح للعملاء بحماية سلامة البيانات.
• Waiter - API ، وسيط يعرف كيفية خدمة البيانات من قاعدة البيانات دون تعطيل عملها.
• العميل - نظام خارجي يريد الحصول على بياناته.
• القائمة - يشير تنسيق البيانات إلى أن الأنظمة الخارجية يجب أن تستخدمها لأداء عملها.
• الطلب - استدعاء API واحد فعلي.

بالعودة إلى المزامنة ، فإن السؤال المتبقي الآن هو معرفة الظروف التي يجب أن يتبادل فيها نظامان البيانات.

مشغلات مزامنة البيانات

لنفترض أن لدينا خادمين للتطبيق جاهزين لتبادل المعلومات. لنكون أكثر تحديدًا ، دعنا نتخيل أن مزود خدمة البريد الإلكتروني الخاص بك ( ESP ) يريد معرفة عدد طلبات العملاء (المتجر الإلكتروني) لإرسال قسيمة ترويجية لهم بعد الطلب العاشر. الآن ، ما نوع تدفق البيانات الذي يمكننا تنفيذه لتحقيق هذا السيناريو؟ يمكننا التمييز بين ثلاثة "مشغلات" يمكنها بدء آلية قسيمة البريد الإلكتروني من جانب ESP.

أ) استقصاء البيانات - في هذه الحالة يطلب ESP من واجهة برمجة تطبيقات المتجر الإلكتروني بشكل متكرر: "أخبرني بإجمالي مبلغ الطلب لـ Jane Doe". يقوم بذلك كل دقيقة أو ساعة أو يوم وما إلى ذلك. عندما يتلقى ESP المعلومات ، فإنه سيعيد حساب شروط إرسال القسيمة لكل طلب API. إن شعورك الغريزي صحيح إذا كنت تعتقد أن هذا قد يكون دون المستوى الأمثل لاستدعاء ومعالجة البيانات بهذه الطريقة. ما البديل؟

ب) دفع البيانات - ماذا لو تمكن متجر إلكتروني من إخطار تطبيق ESP في اللحظة التي قدمت فيها جين طلبها العاشر؟ هذا صحيح. أدركت منصات التجارة الإلكترونية الحديثة أوجه القصور هذه وأدرجت هذه الإخطارات في مجموعة الميزات الخاصة بها. وعادة ما يطلق عليهم webhooks أو وسائل الشرح. إنها وظيفة بسيطة لكنها قوية. يسمح لك بتحديد متى وأي التطبيقات يجب إخطارها في ظل ظروف محددة. يمكنك أيضًا تحديد نوع المعلومات التي يجب أن يتضمنها الإشعار - في بعض الأحيان يكون من المعقول إرسال معلومات كاملة ، ولكن غالبًا ما تكون الخاصية التي تم تغييرها فقط كافية.

ج) معالجة الدُفعات - في بعض الأحيان ، يكون عدد الطلبات ضخمًا جدًا بحيث لا تكون أي من هاتين الطريقتين معقولة. قد يضر مقدار قوة المعالجة اللازمة للتعامل مع الحمل بأحد (أو حتى كليهما) من الطرفين. في هذه الحالة ، يقوم المطورون بتجميع جميع المعلومات في "دفعة" وجدولة تبادل البيانات ليلاً أو ، بشكل عام ، عندما لا تكون الخوادم مشغولة بحركة المرور اليومية. يساعد هذا في التحكم في حركة المرور إلى التطبيقات ويمنع الضغط المحتمل على الخادم الخاص بك.

شروط مفيدة: لمنع إرسال الكثير من الطلبات إلى الخادم ، يطبق مطورو التطبيقات محددات المعدل على تطبيقاتهم. إنه يحد من عدد مكالمات API في فترة معينة ، على سبيل المثال ، 5000 مكالمة في الدقيقة. في كثير من الأحيان ، يتم خنق المكالمات التي تتجاوز الحصة النسبية. هذا يعني أنه سيتم تقديمهم في النهاية (بدلاً من إسقاطهم تمامًا) ولكن مع بعض التأخير.

حتى الآن ، تعلمنا كيف تتم مزامنة بيانات العملاء. ولكن قبل أن يحدث تقسيم العملاء الفعلي ، نحتاج إلى فهم كيفية الحفاظ على اتساق البيانات في قاعدة بياناتك. في الجزء التالي ، سنصف كيفية ضمان تكامل البيانات وأمانها لتحقيق حملات جيدة الأداء.