אם האפליקציה שלכם נשענת על Amazon Pinpoint ל-Push ולהודעות In-App, יש לכם דדליין קשיח ומעבר לא פשוט לפניכם. ב-30 באוקטובר 2026 AWS מפסיקה לתמוך ב-Amazon Pinpoint. מהתאריך הזה ואילך, הקונסולה וכל מה שבניתם בתוכה — endpoints, segments, campaigns, journeys ואנליטיקס — הופכים לבלתי נגישים.
Pinpoint גם הפסיקה לקבל הרשמות חדשות עוד ב-20 במאי 2025, כך שהשירות נמצא בספירה לאחור כבר תקופה. AWS פורסת את לוח הזמנים המלא במדריך סיום התמיכה הרשמי.
הסגירה עצמה קלה להבנה. החלק המסובך הוא לאן AWS שולחת אתכם משם, כי אין מוצר יורש אחד. תלוי במה השתמשתם ב-Pinpoint, העומס שלכם מתפצל בין 4 שירותי AWS שונים. ולשני הדברים שרוב צוותי המובייל הכי אכפת להם מהם — Push ו-In-App — הנתיב המומלץ לא מעביר אותם 1:1.
במדריך הזה: מה בדיוק נסגר, לאן AWS מנתבת כל חלק ולמה זו לא החלפה שווה-ערך, ותוכנית ב-4 צעדים להעביר את תוכנית ה-Push וה-In-App שלכם ל-Pushwoosh במקום. עם מספרים אמיתיים, כדי שתוכלו לתקצב את המעבר בפועל — נקודה קריטית לכל צוות ישראלי שרגיל לבדוק תמורה מול עלות לפני שהוא זז.
מה בדיוק נסגר
ה-API של ערוצי המסרים לא נעלם. מה שנעלם זו שכבת ה-engagement — החלק שאליו נכנסים צוותי השיווק והמוצר שלכם.
אחרי 30 באוקטובר 2026 תאבדו גישה למשאבי ה-Pinpoint שלכם: endpoints (רשומות המשתמשים והמכשירים השמורות), segments (קהלים דינמיים), campaigns (שליחות מתוזמנות), journeys (בנאי האוטומציה הרב-שלבי), ולוחות האנליטיקס המובנים שעקבו אחרי delivery, פתיחות ומעורבות ב-journey.
מה ששורד, תחת שם אחר, היא שכבת הערוץ הגולמית. SMS, voice, push למובייל, OTP ואימות מספרי טלפון ממשיכים לעבוד דרך AWS End User Messaging — השם ש-AWS נתנה מחדש ל-API של ערוצי Pinpoint עוד ברבעון השלישי של 2024. אז אם השתמשתם ב-Pinpoint רק כ”צינור טיפש”, כשה-backend שלכם מחזיק את הלוגיקה וקורא ל-API רק כדי לירות push טרנזקציוני או SMS, יש לכם פחות מה לדאוג. אתם מפנים מחדש את קריאות ה-API וממשיכים הלאה.
אבל אם הצוות שלכם בנה קהלים, campaigns ו-journeys בתוך ממשק ה-Pinpoint, זה בדיוק ה-workflow שנשבר. לבנות אותו מחדש בתוך AWS זה המקום שבו העבודה האמיתית מתחילה.
לאן AWS שולחת אתכם, ולמה זו לא תחליף 1:1
מדריך ההגירה של AWS עצמו לא נותן לכם תחליף אחד. הוא נותן לכם 4, אחד לכל יכולת:
- Engagement (endpoints, segments, campaigns, journeys) → Amazon Connect outbound campaigns + Customer Profiles
- אירועים ואנליטיקס מובייל → Amazon Kinesis
- Email → Amazon SES (Simple Email Service)
- SMS, push, voice, OTP → AWS End User Messaging
עדיין ספק אחד, טכנית. אבל עכשיו זה 4 מוצרים נפרדים, 4 קונסולות ו-4 סטים של תיעוד שמייצגים את המערכת האחת שהייתה לכם. לצוות בלי קבוצת platform-engineering ייעודית, זה נטל הרבה יותר כבד ממה ש”עברו לכלי חדש” בדרך כלל מרמז.
ולצוותי מובייל, יעד ה-engagement הזה הוא המקום שבו זה מסתבך. ל-Amazon Connect יש פערים שקל לפספס עד שאתם כבר באמצע ההגירה.
- הודעות In-App לא נמצאות ב-Connect בכלל. AWS אומרת את זה בעצמה: תיעוד ההגירה מפרט את זה תחת תכונות לא זמינות, בכתב. אם onboarding ב-in-app, feature prompts או paywalls הם חלק מאיך שהאפליקציה שלכם עובדת, אין להם בית טבעי בנתיב המומלץ.
- Push היא לא ערוץ campaign native. Push (GCM, APNS, Baidu וכל השאר) לא נתמך באופן native ב-campaigns של Connect. המדריך של AWS אומר שאפשר עדיין לשלוח אותו, אבל רק דרך journey, עם Lambda action שמחובר ל-push templates של Connect. בפועל זה אומר שאתם כותבים ומתחזקים קוד רק כדי לשחזר מה ש-Pinpoint עשה out of the box.
- Custom Channel קיים רק חצי. הוא זמין ב-journeys אבל לא ב-campaigns. עוד תפר אחד ב-stack מובייל ש-Connect משאיר לכם לתקן בעצמכם.
- ה-templates חולקים מנוע אבל לא syntax. ה-templates של Connect משתמשים באותו מנוע רינדור Handlebars כמו Pinpoint, כך שהלוגיקה שלכם עוברת. אבל ה-placeholders של האטריביוטים כתובים אחרת: מה שהיה
{{User.UserAttributes.PurchaseHistory}}ב-Pinpoint הופך ל-{{Attributes.Customer.Attributes.PurchaseHistory}}ב-Connect. כל template צריך להישלף ולהיכתב מחדש ידנית. - הגירת endpoints היא עבודת scripting. כדי להעביר את המשתמשים שלכם, AWS מבקשת מכם לייצא segment ללא פילטר ל-S3, ואז להריץ סקריפט Python כדי לעצב מחדש את ה-endpoints האלה ל-Customer Profiles, שבהם פרופיל בודד מוגבל ל-3 כתובות אימייל ו-4 מספרי טלפון. זה עובד. זה גם קוד שאתם כותבים, בודקים ומחזיקים.
שום דבר מזה לא הופך את נתיב AWS ללא נכון. אם אתם כבר all-in על Connect לתרחישי contact-center, זה יכול להיות בדיוק הנתיב הנכון בשבילכם. אבל אם Push ו-In-App הן הסיבה שבגללה הייתם על Pinpoint מלכתחילה, ההגירה המומלצת מעבירה את 2 הערוצים האלה ישר למהנדסים שלכם לבנייה מחדש. זה החלק ששווה לדעת לפני שמתחילים, לא אחרי 3 ספרינטים.
מעבירים את תוכנית ה-Push וה-In-App ל-Pushwoosh ב-4 צעדים
Pushwoosh היא פלטפורמת מעורבות לקוחות שנבנתה mobile-first: Push, In-App ו-web push הם הערוצים המרכזיים, עם email ו-SMS לצידם. במקום לפצל את התוכנית שלכם בין 4 שירותי AWS, אתם בונים אותה מחדש פעם אחת, במקום אחד. הנה איך נראית ההגירה.
-
מייצאים את נתוני ה-Pinpoint
מושכים את ה-endpoints, ה-segments, ה-campaigns והגדרות ה-journey דרך ה-API של AWS עצמה, כל עוד הקונסולה עדיין חיה. חכות עד קרוב לדדליין רק מקשה על השליפה, ותצטרכו את הייצוא הזה בכל מקרה, לא משנה לאן תעברו — אז כדאי לעשות את זה מוקדם.
-
מחליפים את ה-SDK במובייל
מחליפים את ה-SDK של Pinpoint או Amplify ב-SDK של Pushwoosh, ואז מוודאים שהמכשירים נרשמים והאירועים זורמים לפני שמעבירים משהו שפונה למשתמש. זה הצעד שמחבר מחדש את האפליקציה שלכם ל-backend מסרים חי.
-
בונים מחדש segments ו-journeys
מייבאים את המשתמשים, ממפים את האטריביוטים מ-Pinpoint אל מודל ה-tags וה-segmentation של Pushwoosh, ובונים מחדש את האוטומציות שלכם בבנאי ה-journey הוויזואלי. זו עבודה like-for-like: אתם מיישמים מחדש לוגיקה שכבר מכירים, לא מתכננים מאפס. זה גם בדיוק החלק שהיה נופל על המהנדסים שלכם בנתיב Connect.
-
מחברים מחדש אירועים, ואז מריצים פיילוט
מחברים מחדש את ה-custom events כדי שטריגרים התנהגותיים יופעלו, מריצים שליחת פיילוט ל-segment קטן כדי לוודא parity, ורק אז עוברים לנפח מלא. משאירים זמן לוח שנה אמיתי לאימות דומיין ולכל רישום שולח, כי שום דבר מזה לא מתקדם מהר יותר רק כי הדדליין קרוב.
ההבדל מנתיב AWS מופיע במקומות הקטנים והמעצבנים. איפה שהמדריך של AWS מבקש מכם לכתוב ולהריץ סקריפט Python כדי לעצב מחדש endpoints ל-Customer Profiles, Pushwoosh מייבאת משתמשים דרך ה-UI או ה-API, בלי סקריפט לכתוב ולתחזק. איפה ש-Connect מבקש מכם לנתב Push דרך journey מגובה-Lambda, Push הוא פשוט ערוץ שבוחרים. ההנדסה שהייתם מתקצבים בשביל נתיב AWS נעלמת ברובה.
כמה זה עולה
תמחור הוא החלק שרוב מדריכי ההגירה משאירים מעורפל, אז הנה זה בפשטות. Pushwoosh מחייבת לפי משתמשים פעילים חודשיים (MAU) — ראו את פירוט התמחור המלא — ולעומס עבודה של Push ו-In-App נקודת הכניסה נמוכה בכוונה:
- Push Only — 7$ ל-1,000 MAU. אם Push ו-In-App הם כל התוכנית, זו המדרגה שמתאימה, בלי תוספת omnichannel שלא תשתמשו בה.
- Omnichannel — 13$ ל-1,000 MAU. מוסיף email, SMS ואת שאר תמהיל הערוצים כשרוצים הכול מתחת לקורת גג אחת.
- Custom — החל מ-2,000$ לחודש. תמחור נפח, תמיכה ייעודית ותנאי enterprise לשליחות גדולות יותר.
לצוות ישראלי שבעיקר צריך להחליף את ה-Push וה-In-App של Pinpoint, נקודת הכניסה של 7$ היא הרבה פחות חיכוך מהתחייבות לחבילת marketing-automation מלאה. בדיוק ה-trade-off ש-Braze, Customer.io ו-Iterable מבקשות מכם לעשות — ובשוק ישראלי מלא בסטארטאפים שרגישים לעלות, זה לא שיקול שולי.
אל תחכו לאוקטובר
ההגירה עצמה היא כמות ידועה: ייצוא, החלפה, בנייה מחדש, בדיקה. הלוח שנה הוא האילוץ הקשיח. 30 באוקטובר 2026 הוא דדליין קבוע, והצעדים שאוכלים זמן שעון אמיתי (מעבר SDK, מיפוי אירועים, הגדרת דומיין ושולח) מתקדמים בקצב שלהם, לא משנה כמה קרוב התאריך.
אפשר להתחיל עם הנתונים האמיתיים שלכם על מסלול חינם של 1,000 MAU, שמספיק כדי לייבא segment אמיתי, לבנות מחדש journey ולהריץ שליחת פיילוט כדי לראות parity בעצמכם לפני התחייבות למעבר מלא. העצה שלנו, אחרי שראינו מספיק מעברים כאלה נגררים: תמדדו את זה מול ה-MAU והלוח זמנים האמיתיים שלכם עכשיו, כל עוד הקונסולה של Pinpoint עדיין שם לייצוא ממנה. הצוותים שמשאירים את זה לספטמבר הם אלה שמגלים את הפערים 3 שבועות לפני שהאורות כבים.
