عندما يأتيني عميل كويتي يسأل: 'نريد تحليلات، أي أداة نستخدم؟' أول سؤال أطرحه هو: 'ماذا ستفعل بالبيانات بالضبط؟'
معظم الشركات تقفز مباشرة إلى الأداة قبل الإجابة على هذا السؤال. النتيجة: غرفة من الأرقام لا أحد يفهمها ولا أحد يستخدمها.
دعني أكون واضحاً: اختيار Firebase أم Mixpanel ليس المشكلة الحقيقية. المشكلة الحقيقية هي تحديد: أي أحداث تهمك؟ متى تتصرف على أساس البيانات؟ ومن المسؤول عن هذا التصرف؟
Firebase: الخيار الذي يناسب معظم التطبيقات الخليجية
Firebase بسيط. مجاني حتى مليون حدث يومي. التكامل مع React Native و Flutter و iOS و Android سهل وموثق جيداً. أنت تضيف سطر أو سطرين من الكود وينتهي الحديث.
من تجربتي: معظم التطبيقات التي طورناها في الكويت والإمارات تستخدم Firebase وتكفيها تماماً. لماذا؟ لأنهم يحتاجون إلى الإجابات البسيطة:
- كم واحد فتح التطبيق اليوم؟
- في أي شاشة بينهم الناس يتركون التطبيق؟
- كم واحد أكمل عملية الشراء من الناحية؟
Firebase يجيبك على هذه الأسئلة في دقائق. واجهته مباشرة وسهلة. لا تحتاج محلل بيانات متفرغ لتفسير الرسوم البيانية.
سعره: 0 دولار حتى المليون حدث يومي. بعدها تدفع. لكن صراحةً، التطبيقات الكويتية التي وصلت لمليون حدث يومي عددها محدود جداً.
Mixpanel: للشركات التي تريد فهم المستخدم الواحد
Mixpanel مختلف. بدلاً من "كم واحد فتح التطبيق"، Mixpanel يسألك: "ما الذي يفعله المستخدم x بالضبط؟ هل هو متشابه مع المستخدم y؟ ما سبب تركه للتطبيق؟"
هذا أقوى. لكنه أعقد. وأغلى. خطة Mixpanel الأساسية حول 500 دولار/شهر (حوالي 150 دينار). بعدها يزيد السعر حسب عدد الأحداث وحجم فريقك.
رأيت شركات خليجية تشتري Mixpanel ثم لا تستخدمه. السبب؟ الأداة توفر 50 مميزة، والفريق لا يعرف بأي سؤال يبدأ.
لكن عندما تعرف أنت بالضبط ماذا تريد — مثلاً: تحديد أي ميزة في التطبيق تسبب retention أعلى، أو أي segment من المستخدمين ينفقون أكثر — هنا Mixpanel يستحق الفلوس.
الفرق الحقيقي: نية السؤال
ليس الأداة. الفرق هو الأسئلة التي تسأل نفسك كل صباح.
Firebase مناسب إذا:
- تطبيقك B2C بسيط (تطبيق طعام، تطبيق خدمات، متجر إلكتروني).
- فريقك صغير (أقل من 10 أشخاص) ولا يوجد data analyst متفرغ.
- أسئلتك بسيطة: كم user؟ أين الـ drop off؟ كم واحد استكمل العملية؟
- ميزانيتك محدودة.
Mixpanel مناسب إذا:
- تطبيقك B2C في مرحلة نمو ولديك funding أو إيرادات ثابتة.
- تريد فهم سلوك المستخدم بالتفصيل (behavior funnels, retention cohorts, lifetime value).
- عندك فريق product أو marketing يعيش على البيانات.
- تحتاج campaigns مخصصة بناء على سلوك المستخدم.
تصنيف الأحداث: المكان الذي تفشل فيه معظم الشركات
هذا الجزء أهم من اختيار الأداة نفسها.
قبل أن تكتب سطر كود واحد، اجلس مع فريقك — product، marketing، dev — واكتبوا: ما الأحداث التي تخبرك عن صحة التطبيق؟
لا تقل: "كل شيء." لأنك لو جمعت كل شيء، انتهى الأمر أنك لا تجمع شيء.
جرب نموذج بسيط: 3 طبقات من الأحداث.
الطبقة 1: أحداث النواة (Core Events)
5-8 أحداث فقط. الأشياء التي إذا لم تحدث، التطبيق فشل. مثلاً لتطبيق طعام: "user_searched"، "restaurant_viewed"، "order_placed"، "payment_completed". هذه الأحداث كل واحد منها يجيب سؤال واحد محدد جداً: هل الناس تبحث؟ هل الناس تختار مطعم؟ هل تشتري فعلاً؟
الطبقة 2: أحداث التفاعل (Interaction Events)
15-20 حدث. لماذا الناس تتركك؟ مثلاً: "login_failed"، "filter_applied"، "review_opened"، "share_clicked". هذه تخبرك كيف الناس تستخدم التطبيق فعلاً.
الطبقة 3: أحداث التفاصيل (Detail Events)
كل حاجة أخرى. لكن لا تجمعها كحد ما. جمعها فقط عندما تحتاج إجابة سؤال محدد. ثم احذفها بعدين إذا ما احتجتها.
من تجربتي: الخطأ الكبير
رأيت هذا الخطأ يُغرق مشاريع كانت ممولة تمويلاً جيداً: الفريق يجمع 200+ حدث في الشهر الأول، بعدها يقول "البيانات ملخبطة" أو "نحن لا نفهم ماذا يحكي الأرقام." المشكلة ليست البيانات. المشكلة أنك لم تقرر أساساً: ماذا تريد تعرف؟ كل حدث يجب أن يجيب سؤال واحد فقط.
كيف تحدد الأحداث التي تهمك
خذ ورقة وشعب. اكتب الأسئلة الخمسة الأهم التي يسأل نفسه المدير أو صاحب الشركة كل صباح:
- كم واحد استخدم التطبيق أمس؟ (احسب retention)
- في أي خطوة الناس بتتركنا؟ (احسب drop off)
- كم واحد أكمل الهدف الأساسي؟ (احسب conversion)
- ما الفرق بين المستخدم اللي يشتري والمستخدم اللي ما يشتري؟ (احسب cohort)
- أي feature/نسخة من التطبيق أداء أحسن؟ (احسب A/B testing)
كل سؤال من هذه يحتاج 2-3 أحداث محددة جداً. لا أكثر. كل حدث يجب أن تكون قادر تكتب بجملة واحدة: "هذا الحدث يخبرني X."
الإعداد في 3 خطوات
أنت اخترت الأداة (Firebase أم Mixpanel). الآن:
الخطوة 1: فتح حساب. في Firebase، اذهب إلى console.firebase.google.com. في Mixpanel، mixpanel.com. يستغرق 5 دقائق.
الخطوة 2: أضف SDK في تطبيقك. في Flutter، استخدم firebase_analytics. في React Native، استخدم @react-native-firebase. في iOS/Android native، استخدم الـ official SDK. التوثيق واضح جداً.
الخطوة 3: أرسل الأحداث الخمسة الأولى. لا تحاول تغطي كل شيء. ابدأ بـ 5 أحداث ركّز وتأكد أنها بتجمع الحقائق. ثم أضف 5 جديدة كل أسبوع.
نصيحة عملية: الأحداث مع الـ properties
لا تقل فقط "user_searched". قل "user_searched" + {query: "iphone 15", result_count: 23, time_spent_seconds: 12}. الـ properties تحول حدث عام إلى معلومة محددة. الفرق بينهم أنك بدون properties لا تقدر تعرف: الناس بتبحث عن إيه؟ بتقضي كام ثانية؟ هل الـ search results بتعطيهم حاجة مفيدة؟
الأخطاء التي تأخذ شهور لتصححها
لا تسمّ الأحداث بأسماء غير واضحة. مثل: "evt_001" أم "button_click". الاسم الواضح: "add_to_cart" أو "payment_failed". السبب: بعد 6 أشهر أنت ما بتتذكر إيه بتعني "evt_001".
لا تغير تعريف الحدث بعد ما تبدأ تجمع بيانات. مثلاً: تقرر أن "order_placed" معناها "الناس ضغطت زر الدفع". بعدها 3 أسابيع تقرر معناها "الدفع اكتمل فعلاً". الآن كل البيانات السابقة ملخبطة.
لا تجمع معلومات شخصية حساسة (مثل كلمات المرور أو أرقام بطاقات الائتمان). بصراحةً، القوانين الخليجية ما قالت كلمتها الأخيرة، لكن الأفضل الاحتياط. جمع فقط: سن المستخدم تقريباً، المدينة، عدد الطلبات. كفاية.
متى تحول من Firebase إلى Mixpanel
عندما تبدأ تسأل نفسك: "كيف أعرف أي segment من المستخدمين بالذات هم اللي بينفقون الفلوس؟" أو "كيف أبني segment واستهدفه برسالة محددة؟" هنا Firebase مش كافي. هنا تحتاج Mixpanel أو حل مشابه.
لكن بصراحةً، معظم التطبيقات الخليجية لم تصل إلى هذه المرحلة. البيانات حتى في Firebase كثيرة أكثر من اللي الناس تستخدمها.
الهدف الحقيقي للتحليلات ليس جمع أكثر ما يمكن من البيانات. الهدف: أن تتخذ قرار واحد جيد كل أسبوع بناء على البيانات. قرار واحد. كفاية.