רוב הצוותים רוצים לדעת אילו קמפיינים באמת מכניסים כסף. מה שעוצר אותם הוא ייחוס (Attribution): נתוני מכירות יושבים במערכות שונות, כל אחת בפורמט משלה, וחיבור זה להודעה שהובילה לרכישה הופך לפרויקט נפרד בפני עצמו. אז בסוף חוזרים לפתיחות ולחיצות — המספרים האלה כבר נמצאים בדשבורד.
הפתרון הוא להכניס את ההכנסה לפלטפורמת המסרים בפורמט שהיא באמת יכולה לעבד. הנה איך עושים את זה ב-Pushwoosh.
למה נתוני הכנסה כמעט אף פעם לא מגיעים לפלטפורמת המסרים שלכם 💰
הסיבה טמונה בפורמט: הכנסה אף פעם לא מגיעה בצורה אחת.
לדוגמה, ה-SDK שלכם מפעיל אירוע רכישה בתוך האפליקציה כשמישהו קונה מטבעות משחק. השרת שלכם שולח OrderPlaced מותאם אישית. Stripe ו-Shopify שולחים אירועי webhook משלהם עבור מנויים והזמנות חנות. לכל אחד שמות שדה שונים, מבנה שונה, הגדרה שונה למה זה “סכום”.
כדי לדווח על הכנסה מכל המקורות האלה יחד, מישהו צריך לכתוב לוגיקה נפרדת לכל מקור ולשמור אותה מסונכרנת. רוב הצוותים לא עושים את זה כי זה כמעט אף פעם לא בראש סדר העדיפויות — עד סיכום הרבעון. ואז הנתונים פשוט לא שם. כך מעקב ההכנסות נדחה שוב ושוב, והצוות ממשיך לדווח על פתיחות כי המדדים הסטנדרטיים האלה כבר מחוברים.
וזה נפתר מהר: הכול מתמצה בהבאת ההכנסה לפורמט אחיד אחד.
אירוע אחד לכל ההכנסות שלכם
Pushwoosh פותרת את בעיית הפורמט עם אירוע מובנה אחד: PW_Conversion. לא משנה מה המקור המקורי, ההכנסה מגיעה ברשומה מנורמלת אחת עם קבוצת שדות קבועה:
- value — סכום העסקה
- currency — לדוגמה USD או EUR
- transaction_id ו-product_id — מזהים אופציונליים
זהו. חידוש מנוי, רכישה בתוך אפליקציה, הזמנה מ-Shopify — כולם הופכים לאותו סוג אירוע. ברגע שההכנסה נכנסת כ-PW_Conversion, כל מה שבא אחרי קורא את אותם נתונים: סגמנטציית RFM, Customer Journeys, דשבורדים ו-ManyMoney AI.
2 דרכים להתחיל לעקוב
מגדירים אירועי המרה לכל אפליקציה בנפרד, ויש 2 דרכים. בחרו את זו שמתאימה לאופן שבו נתוני הרכישה שלכם כבר זורמים.
- מיפוי אירוע קיים — בלי קוד. אם נתוני הרכישה כבר זורמים ל-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 כיעד המרה בכל Customer Journey. לאחר הריצה, נתוני היעד מראים כמה משתמשים באמת קנו, לא רק כמה פתחו. השאלה “האם המסלול הזה השתלם?” סוף-סוף מקבלת תשובה ישירות על הקנבס.
- לדווח על הכנסות בדשבורדים לצד המדדים החשובים האחרים של האפליקציה, בלי לבנות לוגיקה מותאמת אישית לכל אירוע רכישה.
מצאו את סוג האפליקציה שלכם כאן
אותה הגדרה מתאימה את עצמה לאופן שבו האפליקציה שלכם באמת מרוויחה כסף. מצאו את השורה שדומה למקרה שלכם:
| סוג אפליקציה | אירועים שתמפו או תשלחו | מה תראו בסוף |
|---|---|---|
| E-commerce | מיפוי order_placed + webhook מ-Shopify או Stripe | אילו מסלולי שחזור עגלה מייצרים הזמנות אמיתיות; RFM לפי הוצאה כדי לאתר לקוחות חוזרים |
| גיימינג | שליחת iap_completed, battle_pass_bought מהקוד | האם הצעה לאחר שלב אכן ממירה, ולא רק נפתחת; סגמנטים לפי הוצאה עבור שחקנים בעלי ערך גבוה |
| מנוי (מדיה, סטרימינג) | מיפוי subscription_renewed, plan_upgraded (Stripe, App Store) | האם מסעות win-back מייצרים חידוש מנוי אמיתי; RFM לפי עדכניות החידוש |
| פינטק | מיפוי premium_subscribed, first_trade או webhook תשלום | אילו דחיפות onboarding מובילות לחשבונות ממומנים בפועל; סגמנטים לפי היקף עסקאות |
| משלוחי אוכל | מיפוי 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 כיעד המרה במסע הבא שלכם, וצפו בהכנסה מופיעה לצד הפתיחות והלחיצות.
