معظم الفرق تريد أن تعرف أي حملة تسويقية تُدرّ عليها المال فعليًا. ما يوقفها عادة هو الإسناد (Attribution): بيانات المبيعات موزّعة على أنظمة مختلفة، كل منها بتنسيقه الخاص، فربطها بالرسالة التي أدت إلى عملية الشراء يتحول إلى مشروع منفصل بذاته. لهذا تعود الفرق إلى معدلات الفتح والنقر — فهذه الأرقام موجودة بالفعل في لوحة التحكم.
الحل هو جلب بيانات الإيرادات إلى منصة الرسائل التسويقية بصيغة تستطيع فعلاً استخدامها. إليك كيف يتم ذلك في Pushwoosh.
لماذا لا تصل بيانات الإيرادات أبدًا إلى منصة الرسائل لديك 💰
السبب يعود إلى التنسيق: الإيرادات لا تصل أبدًا بشكل واحد موحّد.
على سبيل المثال، يُطلق الـ SDK لديك حدث شراء داخل التطبيق عندما يشتري أحدهم عملة داخل اللعبة. الخادم الخلفي يرسل حدثًا مخصصًا باسم OrderPlaced. Stripe و Shopify يرسلان أحداث webhook خاصة بهما للاشتراكات وطلبات المتجر. لكل واحد منها أسماء حقول مختلفة، وبنية مختلفة، وتعريف مختلف لما يعنيه “المبلغ”.
للتقرير عن الإيرادات عبر كل هذه المصادر، يحتاج شخص ما إلى كتابة منطق مخصص لكل مصدر والحفاظ على تزامنه. معظم الفرق لا تفعل ذلك لأنه نادرًا ما يكون أولوية — حتى مراجعة نهاية الربع، وعندها تكون البيانات غير متوفرة. فيتأجل تتبع الإيرادات، ويستمر الفريق في التقرير عن معدلات الفتح لأن هذه المقاييس القياسية موصولة أصلًا.
والمشكلة قابلة للحل بسرعة: كل الأمر يتلخّص في توحيد الإيرادات في تنسيق واحد متسق.
حدث واحد لكل إيراداتك
يحلّ Pushwoosh مشكلة التنسيق بحدث واحد مدمج: PW_Conversion. أيًّا كان المصدر الأصلي، تصل الإيرادات في سجل واحد موحّد بمجموعة ثابتة من الحقول:
- value — قيمة المعاملة
- currency — مثل USD أو SAR أو AED
- transaction_id و product_id — معرّفات اختيارية
هذا كل شيء. تجديد اشتراك، عملية شراء داخل التطبيق، طلب من Shopify — كلها تصبح نفس نوع الحدث. بمجرد أن تصل الإيرادات كـ PW_Conversion، كل ما هو لاحق يقرأ نفس البيانات: تقسيم RFM، رحلات العملاء (Customer Journeys)، لوحات التحكم، و ManyMoney AI.
طريقتان للبدء
تُعدّ أحداث التحويل لكل تطبيق على حدة، وهناك طريقتان. اختر التي تناسب طريقة تدفق بيانات مبيعاتك الحالية.
- ربط حدث موجود مسبقًا — دون أي كود. إذا كانت بيانات المبيعات تصل بالفعل إلى Pushwoosh عبر حدث آخر، وجّه Pushwoosh نحوه مباشرة. اختر حدث المصدر واربط حقوله: أي سمة تحمل السعر، وأي سمة تحمل العملة. بعدها يقوم Pushwoosh تلقائيًا بتوليد سجل PW_Conversion في كل مرة يُطلق فيها ذلك الحدث، دون تغيير أي سطر من كود تطبيقك. يمكنك ربط عدة مصادر في آن واحد — حدث purchase_completed مخصص إلى جانب webhook من Stripe أو Shopify.
- إرسال PW_Conversion مباشرة من الكود. إذا كنت تفضّل إرسال الإيرادات بشكل صريح، أضف استدعاء postEvent في أي مكان تكتمل فيه عملية الشراء داخل تطبيقك أو خادمك الخلفي. تحتاج هذه الطريقة إلى مساعدة من فريق التطوير لديك، لكنها عملية دمج صغيرة تُنفَّذ مرة واحدة فقط.
الأحداث التي يمكنك تحويلها إلى إيراد (والتي لا يمكنك)
طريقة الربط تعمل مع أي حدث يحمل مبلغًا ماليًا:
- الأحداث المخصصة — أحداثك الخاصة مثل purchase_completed و subscription_renewed و order_placed.
- الأحداث الافتراضية — عندما تمثّل إجراءً مدفوعًا.
- أحداث الـ webhook الواردة — Stripe و Shopify ومصادر الدفع الأخرى المتصلة لديك.
ما لا يمكنك ربطه هو أي حدث لا يحمل مبلغًا يمكن قراءته. أحداث مثل App_open و screen_view و push_opened تتتبع فقط ما فعله المستخدم. بلا مبلغ، لا يوجد شيء يمكن تحويله.
ما يمكنك قياسه بمجرد وصول الإيرادات
هذه هي الفائدة الحقيقية. مع توحيد الإيرادات، تتحول 3 أشياء كانت تحتاج عملًا مخصصًا إلى ميزات جاهزة:
- تقسيم حسب الإنفاق. يقرأ تقسيم RFM بيانات PW_Conversion مباشرة، فيصل أكبر عملائك إنفاقًا تلقائيًا إلى شريحة Champions، جاهزين لعرض ولاء مخصص لهم.
- إثبات أي رحلات عملاء تدفع فعليًا نحو الشراء. حدّد PW_Conversion كـ هدف تحويل (Conversion Goal) في أي رحلة عملاء. بعد انتهاء تنفيذها، تُظهر إحصاءات الهدف عدد من اشترى فعلًا، لا مجرد عدد من فتح الرسالة. سؤال “هل استحقّ هذا المسار الجهد؟” أصبح له إجابة واضحة مباشرة على لوحة الرحلة.
- عرض الإيرادات في لوحات التحكم إلى جانب مؤشرات أداء التطبيق المهمة الأخرى، دون بناء منطق مخصص لكل حدث شراء.
ابحث عن نوع تطبيقك هنا
نفس الإعداد يتكيّف مع الطريقة التي يحقق بها تطبيقك الإيرادات فعليًا. ابحث عن الصف الأقرب لحالتك:
| نوع التطبيق | الأحداث التي تربطها أو ترسلها | ما ستراه أخيرًا |
|---|---|---|
| التجارة الإلكترونية | ربط order_placed + webhook من Shopify أو Stripe | أي مسارات استرجاع السلة تُنتج طلبات حقيقية؛ تقسيم RFM حسب الإنفاق لتحديد العملاء المتكررين خاصة قبل مواسم مثل رمضان والجمعة البيضاء |
| الألعاب | إرسال iap_completed و battle_pass_bought من الكود | هل يتحول عرض ما بعد المستوى فعليًا أم يُفتح فقط؛ شرائح قائمة على الإنفاق للاعبين ذوي القيمة العالية |
| الاشتراكات (إعلام، بث) | ربط subscription_renewed و plan_upgraded (Stripe، App Store) | هل تُنتج رحلات استعادة العملاء اشتراكات حقيقية؛ RFM حسب حداثة التجديد |
| التكنولوجيا المالية | ربط premium_subscribed أو first_trade أو webhook دفع | أي حوافز تأهيل تؤدي فعليًا إلى حسابات مموَّلة؛ شرائح حسب حجم المعاملات |
| توصيل الطلبات | ربط order_placed من الخادم الخلفي | أي إشعارات إعادة تفاعل تدفع نحو إعادة الطلب؛ RFM حسب أحدث طلب |
| السفر والحجوزات | ربط booking_confirmed + خدمات إضافية مثل seat_upgraded | أي تنبيهات انخفاض سعر تتحول إلى حجوزات فعلية؛ شرائح حسب قيمة الرحلة |
order_placed + webhook من Shopify أو Stripeiap_completed و battle_pass_bought من الكودsubscription_renewed و plan_upgraded (Stripe، App Store)premium_subscribed أو first_trade أو webhook دفعorder_placed من الخادم الخلفيbooking_confirmed + خدمات إضافية مثل seat_upgradedاجعل الإيرادات ظاهرة حيث يعمل المسوّقون بالفعل
أحداث التحويل هي جزء واحد من توجّه أكبر لدى Pushwoosh: جعل الإيرادات مرئية حيث يعمل المسوّقون فعلًا، بدلًا من تقرير عليهم أن يذهبوا لجلبه بأنفسهم.
أنتم بالفعل من يقرر ماذا يُرسَل، ولمن، وبأي وتيرة. حاليًا تُبنى هذه القرارات على معدلات الفتح والنقر، لأن هذا كل ما نُعيده لكم. أرسِلوا PW_Conversion، وستُبنى القرارات نفسها على أساس الأموال: أي الحملات تبقى، وأيها تُلغى، وأي الشرائح تستحق مزيدًا من الرسائل — وأيها تكلّفكم إلغاء اشتراكات دون أي مقابل.
هناك عائد متراكم بمجرد أن تبدأ الإيرادات بالتدفق:
فعّل تتبع الإيرادات في Pushwoosh
ابدأ بالمسار الأقل جهدًا: اربط حدثًا ترسله بالفعل، أو سلّم فريق التطوير لديك نموذج postEvent. حدّد PW_Conversion كهدف تحويل في رحلتك القادمة، وشاهد الإيرادات تظهر إلى جانب معدلات الفتح والنقر.
