مرحبا يا هبر!
سوف أشارك تجربتي في كيفية وضع نظام التخصيص الخاص بنا على أساس "المعرفة" عن مشتر محتمل.
يتمثل الاختلاف الوحيد بين حلنا والحلول الكلاسيكية في استخدام مجموعة مختلطة من عدد من الحلول وتلبية قائمة المتطلبات:
- كان من المفترض أن تعمل الخدمة فورًا على مواقع N
- تجزئة الجمهور الديناميكي
- التصفية التعاونية لأغراض التنبؤ في ظروف مختلفة لشرائح الجمهور
- ثابت تم إنشاؤه مسبقًا في شكل محتوى موصى به + مزيج ديناميكي من السلع استنادًا إلى تحليل clickstream
- تغيير المحتوى ، في الوقت الحقيقي تقريبًا ، من ذاكرة الوصول العشوائي (RAM) ، مع مراعاة المعاملات الديناميكية
هذا هو أكثر تفصيلا :) وحول أشعل النار الذي ساعدنا على تغيير المكدس للأفضل.
قبل التاريخ
هناك مجموعة من المواقع من نفس الموضوع ، والتي تتشابه جمهورها - مواقع واحدة القابضة. يختلف المحتوى ، كقاعدة عامة ، ينشر كل موقع معلومات حول البضائع التي تنتجها الشركة القابضة. بالإضافة إلى مواقع "المحتوى" هذه ، يوجد أيضًا متجر إلكتروني خاص بها تُباع فيه هذه المنتجات.
يحتوي كل موقع على فريق تسويق خاص به ، وعدادات GA و Ya Metrics الخاصة به. من خلال تحليل جمهورهم ، خصص المسوقون الزملاء محتوى الموقع ، مع مراعاة احتياجات الزوار. بطبيعة الحال ، تتقاطع جماهير هذه المواقع ، ولكن بما أنه في ذلك الوقت لم يكن هناك عداد واحد ، فإن نتائج التحليل كانت محلية.
أي محلل سوف يتخذ القرار الصحيح ، ويكون في متناول اليد مع المزيد من البيانات. من أجل هذا الغرض الجيد ، طور نسخته الخاصة من العداد.
لماذا لا جوجل تحليلات؟أخذ العينات ، عدم القدرة على جذب كل شيء عن المستخدم من خلال سلسلة من التحركات من الموقع الخارجي ، من خلال مجموعة من مواقعنا ، مع التفاصيل التي شاهدها ، إلخ. نعم ، من حيث مهام GA ، إنها أداة جيدة ، ولكن عندما ترغب في الحصول على البيانات في الوقت الفعلي وتحديد المحتوى المراد عرضه على الفور ، إذن ... عملاق التحليلات ليس لديه مثل هذا الحل. ليس خيارنا هو الرقص مع الدف من هوية العميل للنقل بين المواقع.
لا يعد تحديد عداد واحد لجميع المواقع قرارًا "سياسيًا" صحيحًا تمامًا ، وسيقع على الفور في تقييد الإصدار المجاني.
يجب أن أقول على الفور أنني لم أبدأ في إعادة اختراع العجلة وقصر نفسي على وظيفة متواضعة كانت مهامها:
- إصلاح كل مستخدم فريد ، بغض النظر عن الموقع الذي توجد فيه المجموعة. كان هذا ضروريًا لإنشاء ملف تعريف عميل واحد حيث ستتم كتابة جميع بياناته بالرجوع إلى كل موقع.
- تتبع سلسلة طويلة من التحولات بين جميع مواقع المجموعة خلال الجلسة. كان هذا ضروريًا لتحديد: مصالح المستخدمين ؛ ما شاهدوه ماذا اشترى ما تم وضعه في السلة ولكن لم يتم شراؤه ؛ ما هي منتجات المواقع المختلفة التي يمكن أن تكون "منتجات بديلة" أثناء عملية الشراء ، إلخ.
- تتبع الأنشطة الإعلانية لجميع المسوقين (في كل فريق من الموقع) لتحليلها لاحقا. كان هذا ضروريًا من أجل: إثراء الملف الشخصي لكل زائر ؛ تحديد الحملات الإعلانية المثالية المرتبطة بالمنتج ؛ تحديد القنوات الإعلانية الفعالة مع الإشارة إلى منتج أو حملة ، إلخ. القائمة طويلة جدا.
تم سكب جميع البيانات في الوقت الحقيقي في المجموعة المحلية. اتضح ليس سيئا للغاية. في المستقبل ، كان من الممكن تقديم أي تقارير مجمعة حسب المنتج وحسب: الجمهور والحملات الإعلانية ومصادر المرور وأي شيء يتبادر إلى الذهن. لكل وحدة من البضائع كانت هناك بيانات عن الأسعار والكمية في الأسهم والخصومات والعروض الترويجية وحتى بحر من البيانات.
مدح الموقف ، فأنا محلل + مطور + مسوق + مدير + كان بإمكاني الوصول إلى كل شيء تم ترقيمه في الحجز. لم يكن لدي مهمة فنية في البداية ، لقد قمت بذلك بنفسي لحل مهام تحليل البيانات العادية.
لحظة فنية:
- تم استخدام MongoDB كنظام تخزين موحد
- جمع البيانات في الوقت الحقيقي القائم على جافا سكريبت
- التبادل المحلي للبيانات بين المواقع على أساس rabbitmq
في حين أن كل شيء ، مثل أي شخص آخر ... ولكن بعد ذلك بدأ
نظرًا لحقيقة أن المعرفة المكتسبة حول المشترين والمنتجات قد تراكمت بشكل كافٍ ، فقد قررنا إنشاء نظام توصيات خاص بنا لمتجر على الإنترنت.
كل شيء تحول كبير. قمنا بتحليل كل شيء ، ولكن دون تعصب. زاد حجم النموذج ، وكما يحدث عادة ، فقد حان الوقت عندما أردت المزيد.
اللحظة الفنية 2:
- ساعد النسخ المتماثل MongoDB على العيش ، ولكن تم التخلي عن التقسيم على الفور. لم تمر هذه اللحظة بعدد من الجوانب الداخلية. إذا كانت مجموعة clickstream يمكن أن تنتشر حول القطع ، فإن مجموعة ملفات تعريف المستخدمين لم تعد موجودة. كان من الممكن جمع نتائج الاستعلامات المجمعة من مجموعات مختلفة لجزء من التقارير ، لكن سرعة التنفيذ تركت الكثير مما هو مرغوب فيه. بدون التقسيم ، عملت بشكل أفضل وأكثر استقرارًا
- جمع البيانات في الوقت الفعلي استنادًا إلى javascript - هنا كانت حزمة CORS + HTTPS ديكتاتورًا. الحالة ، عندما جاء أحد المستخدمين إلى أحد مواقع المجموعة ، و "سمحت" خدمتنا له على الفور في منطقة متعددة المجالات (أذكر ، كان هناك 5 مواقع منفصلة مستقلة في ذلك الوقت) كانت جميلة من الناحية التكنولوجية وغامضة بالنسبة إلى زملائه المسوقين الذين يمكنهم الآن رؤية جميع سلسلة ضرب لجميع المواقع في وقت واحد.
- تم كتابة نموذج خدمة التوصية في بيثون. لكن التدريب استغرق وقتا طويلا. ملف النموذج هو عدة عشرات غيغابايت.
- عملت خدمة التوصية على مستوى واجهة برمجة التطبيقات الخاصة بها ، لكن استجابة الخادم أصبحت عنق الزجاجة ، أو بالأحرى ، الوقت الذي استغرقته للحصول على النتيجة. كلما زادت البيانات ، زاد حجم النموذج ، زاد حجم النموذج ، وأبطأ النتيجة. استجابةً لذلك ، كان من الضروري مراعاة العديد من العوامل التي تغيرت كل ساعة (مخزونات السلع الموجودة في المخازن ، وخصائص المستخدم والأزياء ، وجميع أنواع الخصومات ، وما إلى ذلك)
بعد بضعة أشهر ، تجاوزت جودة واجهة برمجة التطبيقات جميع الحدود المعقولة لـ "الجودة". بالنسبة للمستخدمين ، تجاوزت سرعة الاستجابة علامة 400ms. كتل المحتوى تجمع ببطء ، بدأ الموقع ممل بشكل ملحوظ. مجموع مجموعات MongoDB عشرات الملايين من السجلات ...
حان الوقت لتغيير شيء ما
تم تسجيل جميع الأدوات تقريبًا على مستوى العمليات ، وتم قياس كل تعطس.
ما الذي تغير لما:
- Clickhouse على MongoDB
- مزيد من MongoDB إلى MongoDB + Tarantool
- عشية على قارورة
- مزيد من قارورة على الصقر
- كان هناك ملف منفصل مع الوعود في js ومع إذن المستخدم على جميع المجالات. إنهم لم يغيروا المنطق ، فقد فازوا بإعادة البيع
لماذا لا متري API؟في البداية ، كنت أبحث فقط في اتجاه الحلول الجاهزة من ياندكس ، لكنها لم تكن طويلة. هذا جيد عندما يكون هناك موقع واحد قيد التشغيل. وعندما يكون هناك n ، وتريد معالجة البيانات على الفور ، فلا يوجد وقت للرقص مع الدف.
لماذا MongoDB؟تمت إضافة مواصفات المنتج باستمرار ، والبعض منها ، للأسف ، لم يتم تقديمه دائمًا.
باستخدام استعلامات مجمعة - تتناسب بشكل جيد مع شكل الأسلوب التكنولوجي المحلي للفريق. SQL الكلاسيكية لا تريد إنتاج الجداول.
في كثير من الأحيان ، تم تعديل أنواع ومتغيرات البيانات التي تم تخزينها ومعالجتها.
في البداية ، اعتقدت أنني سوف أستخدم Yandex clickhouse أساسًا للخدمة ، ولكن بعد ذلك تخلت عن هذه الفكرة ، لكن clickhouse كان أيضًا في حامل المكدس الخاص بنا.
لقد حان وقت جديد ، 2000 طلب في الثانية ... شريطة أن يتم طرح وظائف جديدة خلال أسبوع وأن الحمل سيزداد أكثر.
أثناء التعلم الآلي ، ولأول مرة في htop ، رأيت حمولة 100٪ من 12 مركزًا دفعة واحدة ومبادلة كاملة على خادم منتج. أبلغ Zabbix بنشاط أن MongoDB قد قام بالفعل بتغيير أسياد في النسخة المتماثلة مرتين في 10 دقائق. الجميع أراد الاستقرار وحالة يمكن التنبؤ بها.
حان الوقت لتغيير شيء 2.0
زاد عدد المستخدمين. عدد العملاء مشابه. لكل من زار أيًا من المواقع ، جمعنا ملفًا شخصيًا. تم تشكيل جمهور الزوار بشكل جزئي.
ماذا تعرف كيف تفعل؟ نعم ، أي تقرير غير قياسي لتنوع محتوى التحليلات +:
- حدد جميع المستخدمين الذين جاءوا من الحملة الإعلانية A ، والتي كانت في الربع الأخير ، من بينها ، ابحث عن أولئك الذين كانوا مهتمين بالسلع من العنوان N ، ثم استبعد أولئك الذين اشتروا فقط في الأسهم ، واستبعد أولئك الذين وضعوا أي منتج في السلة واليسار الموقع. وفقًا لهم ، قم بالفرز بترتيب تنازلي لدخل المتجر إذا جاء هؤلاء المستخدمون الآن إلى موقع المتجر واشتروا بضائع Z. شيء من هذا القبيل ، ومع أزرار أم اللؤلؤ الأخرى ...
- لتحليل حركة المرور الواردة ، للمستخدمين الذين لديهم علامة ut Y لتشكيل عرض محتوى ، ولكن قبل الإنشاء ، حدد المستخدم ، واستبعد أولئك الذين كانوا في الأسبوع الماضي ولكنهم كانوا في الموقع S (أحد مجموعة المواقع القابضة) وكانوا مهتمين بالمنتج Q - لهذا توليد محتوى مرتبة حسب معايير س ، ص ، ض
- من المبتذلة العثور على أولئك الذين يزورون الموقع "أ" ، وأحيانًا يحدث ذلك في الموقع "ب" (قاموا بزيارة قسم معين) ، والذين لديهم فحص متوسط في المتجر عبر الإنترنت لأكثر من N روبل.
في الواقع ، لم يكن هذا في شكل "البرمجة غير الطبيعية" ، أردت شيئا آخر. جاء آخر لنا. في وقت الحملات الإعلانية ، كان المتجر على الإنترنت مثنيًا ، فماذا يمكننا أن نقول عن واجهة برمجة التطبيقات (API-shki) التي اشتعلت هذا الحمل "واقفًا بجواره".
القرارات التي اتخذت في الوقت المحدد
أجرينا تحليلًا للجمهور ، وقررنا جمع المحتوى ليس للجميع ، ولكن لمجموعات الزوار. كان الحشد كله متجمعا. كل مجموعة لها خصائصها و "ذوقها" للتسوق. يتم التجميع كل يوم. يعد ذلك ضروريًا حتى يقوم المستخدم في الزيارة التالية بعرض المحتوى الذي يتوافق معه تمامًا.
من الجلسة إلى الجلسة ، تتغير اهتمامات العميل واحتياجاته ، وإذا كانت آخر مرة تم تعيينه تلقائيًا في المجموعة رقم 788897 ، ثم مع مراعاة اهتماماته الحالية ، يمكن للنظام نقلها إلى المجموعة رقم 9464 ، مما سيؤثر بشكل أكثر فعالية على التحويل اللاحق.
بعد إجراء التجميع اليومي ، تم إطلاق المرحلة التالية - تدريب النموذج ، مع مراعاة البيانات الجديدة والمعرفة حول العملاء ومراعاة البضائع التي ظهرت على أرفف المتاجر أو تركتها إلى الأبد.
لكل كتلة ، قمنا بتشكيل كتل المحتوى مسبقًا وتسجيلها في الذاكرة. ثم جاء Tarantool على الساحة بكل مجده. في السابق ، استخدمناها لتخزين البيانات السريعة ، والتي كانت تستخدم بعد ذلك في التعلم الآلي. كان هذا هو الحل الأفضل ، حتى لا يهز لعبة MongoDB التي كانت مشغولة بالفعل بمهام أخرى. في الفضاء Tarantool تخزين البيانات على البضائع ، وبيانات المستخدم (المعرفة اللازمة عن المشتري).
وبشكل تقريبي ، قمنا الليلة "بإعداد" محتوى لكل مجموعة من الجماهير التي قد تزور الموقع غدًا. جاء المستخدم ، وسرعان ما قررنا ما إذا كنا نعرف أي شيء عنه ، وإذا كانت الإجابة نعم ، فستتوجه حزمة المحتوى المطلوبة إلى Nginx. بشكل منفصل ، لمستخدمي NoName ، تم تجميع كتلة افتراضية مع محتواها.
تحليل نتائج التخصيص
لقد عرفنا أن هناك مستخدمين بسيطين ، وهناك أولئك الذين لديهم ملف كامل للمعرفة. كل هذه الأشياء كانت في تارانتول وتحديثها في الوقت الحقيقي.
في وقت تجميع الصفحة ، كنا نعرف التاريخ الكامل للمشتريات والسلال المهجورة لكل زائر (إذا كان عميلًا من قبل) ، وحدد انتمائه العنقودي ، وأعطيت وحدة clickstream المعرفة حول مصدر الحركة ، عرفنا بمصالحه السابقة والفورية. بناءً على مجموعة TOP50 أثناء الطيران من المنتجات التي تم عرضها سابقًا (على أي من مواقع المجموعة) ، قمنا "بتحديد الأزياء" وخلطنا في المحتوى "الذوق" لتلك المنتجات ، والتي غالبًا ما تكون مواضيعها ضمن TOP50. أعطى هذا التحليل البسيط لآخر المنتجات المعروضة ربحًا حقيقيًا. المحتوى العنقودي ، قمنا بإثراء شخصية.
نتيجة تجربتنا
- حصلنا على تسريع عملية إنشاء محتوى شخصي N مرة
- انخفاض تحميل الخادم بنسبة 15 مرة
- يمكننا إنشاء أي محتوى تقريبًا شخصيًا ، مع الأخذ في الاعتبار العديد من مسوقي قائمة الأمنيات وميزات العرض التقديمي للمنتج والعديد من الاستثناءات ، مع مراعاة البيانات من ملف تعريف المستخدم والأحداث التي تحدث على الموقع في الوقت الحالي - وكل هذا لمدة ~ 25 مللي ثانية
- لا يقل التحويل لهذه الكتل عن 5.6٪ - المستخدمون على استعداد لشراء ما هو أقرب إلى احتياجاتهم في الوقت الحالي
- سرعة تحميل الصفحة مثالية - لقد أزالوا المحتوى الذي "تجاوز" الكتلة بنسبة> 67 ٪ ، وهذا صحيح
- لقد حصلنا على أداة ، وفقًا لمهام المسوِّقين ، لا تقدم الإجابة "ما حدث سابقًا" فحسب ، بل تساعد أيضًا في صياغة المحتوى في المستقبل القريب المجزأ ، مع مراعاة اهتمامات واحتياجات المشترين المحتملين
- تمت إضافة معلومات من DMP إلى ملف تعريف كل مشتر ، والآن يمكننا القيام بالتكتلات ، بما في ذلك عن طريق الشبكة الاجتماعية ، والفوائد ، ومستوى الدخل والحلويات الأخرى
- أصبحت خدمة التوصية لدينا أفضل ، والمزيد من الطلبات في المتجر
ما هو جيد هذا؟
لقد حصلنا على تجربة جديدة واختبرنا عددًا من الفرضيات التي لم نكن نعرف كيف نتعامل معها من قبل ، ونحن لا نستخدم حلولًا مدفوعة من جهة خارجية لخدمة التوصية التي لم تأخذ في الاعتبار جميع ميزاتنا وعملت على نفس المجال. تلقى الفريق حالة جيدة ومثيرة ، والتي تمكنوا من إدارتها بنجاح.
تتزايد شهية ... الآن نحن نختبر منطق جديد لتجميع المحتوى. نريد جمع صفحات للحملات الإعلانية والنشرات الإخبارية وغيرها من الأنشطة الخارجية. تتضمن الخطط نقل منطق التكوين من وضع manul إلى اتجاه تعلم الآلة. ستعيش المواقع حياتهم الخاصة ، وسنلاحظ ، إلى جانب "الفشار" ، تطور عرض محتوى الموقع بناءً على رأي منظمة العفو الدولية.