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

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

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

عندما نحصرها في تقسيم العملاء ، يجب أن يكون أخصائي CRM على دراية بتفرد البيانات وأنواع البيانات وقيود البيانات.

تفرد البيانات

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

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

لهذا السبب تستخدم CRMs معرفًا داخليًا فريدًا. لقد تمت صياغته كمعرف فريد عالميًا (UUID) أو معرفًا فريدًا عالميًا (GUID) .

هذه خوارزميات تأخذ السمات الفريدة للعميل (مثل البريد الإلكتروني أو رقم الهاتف) ، وتقوم بتشفيرها ، وإنشاء سلسلة من الأحرف العشوائية - فريدة لكل عميل . عندما يصبح جون عميلك ، سينشئ CRM معرفًا له ، مثل 8f14a65f-3032-42c8-a196-1cf66d11b930.

من خلال إنشاء مثل هذا المعرف الطويل ، فإنك تقلل من مخاطر إنشاء معرف مكرر إلى الصفر تقريبًا.

أنواع البيانات

قد يكون التنسيق الذي تخزن به البيانات تهديدًا آخر أو يساعد على تكامل البيانات. تخيل إجراء استبيان وسؤال جمهورك عن هاتف ذكي مفضل - فأنت تريد إرسال عرض إلى كل عميل اختار iPhone X أثناء العرض الترويجي.

عندما تقرأ قائمة الردود ، ترى السجلات التالية:

• iPhone X
• آيفون X
• أنا Phone10
• هاتف iPhone X
• آيفون 10
• نوكيا 3310
• وهلم جرا...

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

يمكن تجنب أخطاء بسيطة ولكنها مزعجة مثل هذه من خلال فهم نموذج البيانات والتحقق منه مرة أخرى لكل خطوة من خطوات رحلة العميل. تتمثل الخطوة الأولى في زيارة الوثائق المتعلقة بالخيارات التي يقدمها برنامج CRM لتخزين البيانات ومعالجتها لكل كيان - يطلق عليه مخطط البيانات.

دعنا نستكشف كيف يبدو مخطط البيانات وكيف يمكنك استخدام ميزاته لضمان تكامل البيانات. أنواع البيانات هي الأولى.

أنواع البيانات

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

البدائية - الأنواع الأساسية

• منطقي - يمثل القيم صحيحة أو خاطئة. على سبيل المثال ، تخيل سمة: is_first_time_customer.
• عدد صحيح - يمثل عددًا ، موجبًا أو سالبًا ، لا يحتوي على فاصلة عشرية. على سبيل المثال ، في Salesforce CRM ، تحتوي الأعداد الصحيحة على قيمة دنيا تبلغ -2،147،483،648 وقيمة قصوى تبلغ 2،147،483،647.
• عشري (عشري) - رقم يتضمن فاصلة عشرية ، على سبيل المثال ، 3.14159.
• الحرف - حرف واحد أو أي حرف ، بما في ذلك الأرقام (تسمى مجتمعة الأبجدية الرقمية).
• سلسلة - يخزن سلسلة من أي أحرف أبجدية رقمية ، مثل كلمة أو عبارة أو جملة.
• التاريخ - قيمة تشير إلى يوم معين.
• Datetime - قيمة تشير إلى يوم ووقت محددين.
• Blob - (من الكائن الثنائي الكبير) مجموعة من البيانات الثنائية المخزنة ككائن واحد. يمكنك التفكير في الأمر كملف واحد (صورة ، تسجيل صوتي ، فيلم ، PDF ، إلخ) للتبسيط.

قبل أن ننتقل إلى الأنواع المتقدمة ، دعنا نتوقف للحظة لاكتساب بعض الحدس حول كيفية اختيار النوع المناسب. ربما لاحظت بالفعل أن كل نوع بيانات له خاصيتان:

• ما نوع القيم التي يمكن أن تمثلها ،
• ما هي القيم الدنيا والقصوى التي يمكن تخزينها.

هناك قاعدتان أساسيتان لكليهما:

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

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

2) القاعدة الثانية حول القيم الدنيا والقصوى. كلما أعددت للحجم الأكبر للسمة ، زادت مرونتها. الآن ، قد تسأل لماذا لا تستخدم دائمًا الخيار الأكبر؟ لأن الحجم الأكبر يحتاج إلى المزيد من ذاكرة الكمبيوتر اللازمة لمعالجة البيانات ، وهذا يكلف أكثر. قد يكون الأمر ضئيلًا عندما يكون لديك مئات السجلات ، ولكن عندما تنمو إلى الملايين ، قد يكون مثيل CRM الخاص بك أبطأ في الاستجابة ، أو ستصل إلى الحد الأقصى وستضطر إلى الترقية إلى خطة تسعير أعلى.

مركب - نتيجة الجمع بين اثنين أو أكثر من الأوليات

• صفيف - مجموعة من الأوليات من أي حجم. وعادة ما يتم تمثيلها كسلسلة أو بدائل بين قوسين ، على سبيل المثال ، [1 ، 3 ، 5 ، 13 ، 5].
• مجموعة - مجموعة من العناصر الأولية من أي حجم ولكن بقيم فريدة فقط [1 ، 3 ، 5 ، 13].
• التعداد - التعداد (من العداد) هو نوع بيانات يحتوي على قيم يأخذ كل منها بالضبط واحدًا من مجموعة محدودة من المعرفات التي تحددها (يجب أن نستخدمه في استطلاعنا لتجنب الفوضى!).
• الكائن - الكائن هو قيمة تحتوي على قيم أخرى ، عادةً بأرقام وتسلسلات ثابتة ويتم فهرستها عادةً بواسطة الأسماء. تسمى عناصر السجلات عادةً الحقول أو الأعضاء. تذكر أمثلة JSON من الجزء الأول ، فهي كائنات.

قيود البيانات

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

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

هل تلقيت يومًا عنوان بريد إلكتروني عزيزي {first.name}؟ قد يكون هذا نتيجة نسيان قيد NOT NULL على سمة الاسم الأول.

إليك كيفية عمل هذه القيود النموذجية وغيرها:

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

• يجب أن يتوافق البريد الإلكتروني (سلسلة) مع نمط معين (اقرأ مقالة wiki لترى أنه أكثر تعقيدًا من إلزامي @ في المنتصف).
• يجب أن يكون العمر (عدد صحيح) أكبر من 13.
• يجب أن يكون تاريخ الميلاد (التاريخ) في شهر مارس.
• يجب أن يكون إنشاء العميل (التاريخ) قبل 1 أكتوبر 2020.
• يجب ألا يأتي آخر طلب (DateTime) قبل ظهر أمس.
• يجب أن يبدأ رقم الهاتف (السلسلة) ببادئة البلد.
• يجب أن يتكون العنوان (الكائن) من الشارع ، والرقم ، والمدينة ، والبلد ، والرمز البريدي - والتي يمكن أن يكون لها قيود "الاختيار" الخاصة بها. ‍

تطبيع البيانات

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

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

بدلاً من تخزين اسم الطبقة ، والذي يمكن أن يكون طويلاً مثل Dunder Mifflin Golden Tier لكل شخص ، نحمل ببساطة رقمًا يشير إلى جدول طبقات البرنامج.

لذلك ، بدلاً من الاحتفاظ بـ 20000 Dunder Mifflin Golden Tier ، لدينا 20000 مرجع مثل # 3. عندما تريد تغيير اسم الطبقة لسبب ما ، فأنت بحاجة إلى تحديثه في مكان واحد فقط ، وسيتم الحفاظ على تكامل البيانات.

الآن ، دعنا نتعمق في مفهوم التطبيع الأكثر تقدمًا. لنفترض أنك تريد مراقبة كيفية تحرك العميل عبر مستويات مختلفة. يمكننا تخزينه في الجدول التالي:

الزبون | الطبقة | تاريخ دخول الطبقة

مايك سكوت | الطبقة الذهبية DM | 21/07/2020

مايك سكوت | فئة DM الفضية | 04/06/2020

جيم هالبرت | فئة DM البرونزية | 17/06/2020

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

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

الوجبات الجاهزة

عندما تجد نفسك تعمل مع CRM جديد ، قم بزيارة وثائقهم لاستكشاف مخطط البيانات. تصفح الكائنات الافتراضية لترى ما يمكنك فعله خارج الصندوق. تعرف على أنواع البيانات وكيف يمكنك التعامل معها من خلال آليات مضمنة مثل حسابات Hubspot أو حقول Salesforce المحسوبة مع الصيغ أو كيفية تقديمها بلغات النماذج مثل Liquid.

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