המחסנית הראשונה של אוגוסט נוחתת בצד האנליטיקס: Pushwoosh אוספת עכשיו הכנסה כאירוע (event) עצמאי, וניתוח control group מראה כמה מההכנסה הזו המסרים שלכם בפועל הביאו. גם הודעות in-app native השתחררו.
הנה מה שחדש 👇
עקבו אחרי הכנסה ב-Pushwoosh עם conversion event 🤑
Pushwoosh אוספת עכשיו הכנסה כסוג אירוע עצמאי. כל רכישה, חידוש או תשלום מתועד כ-PW_Conversion — מספר אחד נקי שאפשר לבנות עליו.
ההגדרה קלה: שלחו אותו מהקוד שלכם אחרי רכישה, או מפו אירוע שאתם כבר מפעילים — כולל webhooks של Stripe ו-Shopify — בלי קוד בכלל. העניין האמיתי הוא מה אפשר לעשות כשההכנסה כבר בפנים.
איך זה נראה בפועל:
- סגמנטו לפי הוצאה אמיתית. בנו סגמנט RFM של קונים בעלי ערך גבוה לפי סכומי רכישה ותדירות אמיתיים — בלי לוגיקת הכנסה מותאמת לכל אירוע. מסלול ה-VIP שלכם מכוון למי שמוציא כסף, לא רק למי שפותח הודעות.
- ראו אילו journeys מכניסים כסף. ייחסו הכנסה ל-Customer Journey או לקמפיין, ומסלול שחזור העגלות הנטושות שלכם מפסיק לדווח רק קליקים ומתחיל להראות את ההכנסה שהוא בפועל השיב.
- מספר הכנסה אחד לכל המקורות. שלבו רכישות in-app ותשלומי webhook מ-Stripe או Shopify במערך נתונים אחד, במקום לחבר כל מקור בעצמכם ביד.
לחברות B2B SaaS ו-e-commerce ישראליות שמוכרות החוצה מהיום הראשון, מספר הכנסה נקי אחד לכל הערוצים הוא בדיוק סוג הנתון שצוותי גדילה סקפטיים דורשים לפני שהם מצדיקים תקציב קמפיין — לא הערכה, נתון אמיתי מהרכישה.
אתם כבר מחליטים מה לשלוח, למי ובאיזו תדירות. אתם רק מקבלים את ההחלטות האלה על בסיס פתיחות וקליקים, כי זה כל מה שאנחנו מחזירים לכם. שלחו
PW_Conversionואותן החלטות מתקבלות על בסיס כסף: אילו קמפיינים לשמור, אילו לסגור, אילו סגמנטים מצדיקים יותר שליחות — ואילו עולים לכם בהסרות מרשימת תפוצה בלי שום תמורה.
כמה דרכים שצוותים משתמשים בזה:
- E-commerce. מפו את webhook הצ’ק-אאוט של Shopify שלכם ל-
PW_Conversion, ומסלול שחזור העגלות הנטושות מפסיק לדווח בפתיחות — אתם רואים את ההכנסה שהוא בפועל משיב, ואם השליחות משתלמות. - אפליקציות מנוי (subscription). הפנו אותו לאירוע החידוש שלכם ב-Stripe כדי לראות אילו journeys של win-back ותזכורות חידוש מחזירים מנויים שנשרו לתשלום, במקום לנחש מה-click-through.
- גיימינג ואפליקציות עם רכישות in-app. הזרימו רכישות in-app לתוך המערכת ובנו סגמנטי RFM שמעלים על פני השטח את המוציאים הגדולים שלכם — ואז שלחו להם הצעות שלא הייתם שולחים לכל הבסיס.
מדדו את ההשפעה האמיתית של המסרים שלכם 📊
הכנסה שנכנסת היא רק חצי מהסיפור. החצי השני הוא להוכיח שהמסרים שלכם הם אלה שהביאו אותה — ולזה בדיוק עונה עכשיו ניתוח control group.
Global control group מחזיק בצד פלח קבוע מהמשתמשים שלכם, בלי לשלוח לו הודעות שיווקיות, בזמן שהודעות transactional עדיין מגיעות אליו כרגיל. האנליטיקס החדשה משווה את הקבוצה המוחזקת בצד לכל מי שקיבל את הקמפיינים שלכם, כך שאתם רואים את ה-lift שהמסרים שלכם בפועל הפיקו.
למה זה חשוב: זו התשובה הנקייה לשאלה — כמה מההכנסה הזו באמת קשורה לשיווק? כמה שהאודיינס שלכם גדול יותר, ההשוואה הזו שווה יותר.
לצוותי גדילה ישראליים שמורגלים למספרים מגובים ולא לסיפורים, זו בדיוק ההוכחה שמצדיקה תקציב שיווק מול הנהלה סקפטית — לא הערכת attribution, אלא השוואה נקייה בין קבוצה שקיבלה מסרים לקבוצה שלא.
שלבו את זה עם conversion events שלמעלה והמעגל נסגר. עקבו אחרי ההכנסה, ואז מדדו כמה ממנה הקמפיינים שלכם באמת אחראים לה.
עצבו הודעות in-app native 📱
הודעות in-app native זמינות עכשיו ב-Pushwoosh — תוכן in-app שנבנה כדי לרנדר כחלק מהממשק של האפליקציה שלכם, ולא כשכבת web שמוצגת מעליו. הן נפתחות מהר יותר, מתאנימות בצורה חלקה יותר, ואתם בונים אותן בלי צוות design או development.
יש 3 סוגי תצוגה:
- Modal — כרטיס ממורכז, לפי בחירה על גבי רקע מוכהה. מתאים להצעה או prompt בודדים.
- Fullscreen — תמונת כיסוי מקצה לקצה עם הכותרת, ההודעה והכפתורים שלכם מעליה.
- Stories — רצף שקופיות מלאות-מסך עם progress bars, בדיוק כמו פורמט ה-stories שמשתמשים כבר מכירים מרשתות חברתיות.
תרחישי שימוש: in-apps native מתאימים באופן טבעי לטיפים ב-onboarding, נודג’ים לתכונות, או סקר קצר בתוך session.
בישראל, שבה חדירת ה-iOS גבוהה יחסית לממוצע העולמי, רנדור native שעובד באופן זהה בשתי הפלטפורמות חשוב במיוחד — אין צורך להתפשר על חוויית ה-iOS כדי לתמוך גם ב-Android, ולהפך.
עורך האימייל נהיה חכם יותר ✏️
מחסנית שיפורים שגורמת לעורך ה-drag-and-drop לעשות יותר עבודה בשבילכם:
- תוכן מותנה (Conditional content) — תנאי התצוגה של בלוק מקבלים עכשיו כל ביטוי Liquid, ולא רק תג שנבחר מרשימה. ואפשר לשרשר IF / ELSE IF / ELSE כדי להציג variant אחר לכל קבוצת נמענים, במקום רק להציג או להסתיר בלוק בודד. למידע נוסף →
- קטלוג מוצרים באימיילים — בלוקי Product מושכים עכשיו נתונים חיים ישירות מ-feed מחובר (Google Merchant XML או JSON), כך שהרשימות נשארות מעודכנות בלי עריכה ידנית. למידע נוסף →
- Image fit — קבעו את הגודל והחיתוך של תמונה בתוך בלוקי Card ו-Column ישירות בעורך, בלי צורך בהתאמת קוד. למידע נוסף →
- שמירה על עותקים מסונכרנים — ערכו בלוק בשימוש חוזר פעם אחת, והשינוי חל בכל מקום שהוא מופיע, כולל אימיילים שכבר מתוזמנים לשליחה. למידע נוסף →
- Brand book — שמרו את הצבעים, הפונטים והלוגו של המותג שלכם פעם אחת, ואז השתמשו בהם מחדש בכל אימייל למראה עקבי. למידע נוסף →
עוד שיפורי גימור ל-in-app ול-web popups 🔧
3 עדכונים קטנים יותר שעולים הרבה בשימוש יומיומי:
- תצוגה מקדימה של in-apps לפני שליחה. בדקו איך תבנית נראית ומתנהגת על מכשיר ישירות בלוח הבקרה, לפני שהיא יוצאת. למידע נוסף →
- Corner radius לכפתור הסגירה ב-in-app. סליידר בין 0 ל-16px הופך את כפתור הסגירה מעגול מלא לריבועי, כדי להתאים לעיצוב שלכם. למידע נוסף →
- טפסי הרשמה ב-web popups. הציגו טופס הרשמה קיים בתוך web popup במקום banner — חפשו את הטופס לפי שם והכניסו אותו. למידע נוסף →
נסו את העדכונים בעצמכם
כל התכונה שמופיעה למעלה פעילה כבר בחשבון שלכם. עוד עדכוני אוגוסט בדרך — עד אז, היכנסו ושימו אותן לעבודה.
לרשימה המלאה, בדקו את הערות הגרסה שלנו.
