אם לפלטפורמת המעורבות לקוחות שלכם אין wallet passes נייטיב, יש 2 דרכים. לחבר כלי pass ולשמור על 2 מערכות מסונכרנות, או לעבור לפלטפורמה שמנפיקה כרטיסי Apple Wallet ו-Google Wallet על אותו פרופיל לקוח. אינטגרציית wallet pass דרך כלי נפרד מהירה יותר להתחלה. הפלטפורמה הנייטיב פשוטה יותר לתפעול ברגע שה-wallet הופך לחלק מה-journeys שלכם.
כתבנו את זה לצוותים על פלטפורמות כמו Braze, OneSignal או CleverTap שרוצים wallet passes בלי להפוך הכול. להשוואה ברמת הספקים, ראו את השוואת ה-Wallet passes.
מאיפה אתם מתחילים
התמיכה ב-wallet משתנה מאוד בין פלטפורמות מעורבות. Braze מוסיפה wallet דרך שותפים כמו PassKit. ל-OneSignal אין wallet passes נייטיב. בדקו את התיעוד העדכני של הפלטפורמה שלכם לפני שאתם מתכננים, כי זה משתנה.
בלי תמיכה נייטיב, הכרטיס חי במערכת 1 והלקוח במערכת אחרת. כל כרטיס שאתם מנפיקים, מעדכנים או מטרגטים צריך נתונים משתיהן.
מסלול A: שומרים על ה-CEP ומוסיפים כלי pass
אתם ממשיכים להשתמש בפלטפורמה הנוכחית ל-push, אימייל ו-segments, ומחברים כלי pass עצמאי ל-Apple Wallet ול-Google Wallet.
כך זה עובד בדרך כלל. ה-CEP או ה-backend שלכם קוראים ל-API של כלי ה-pass כדי להנפיק כרטיסים, לרוב דרך webhooks. אם כלי ה-pass חושף אירועים, הם זורמים חזרה ל-CEP כדי שתוכלו לעשות segmentation למחזיקי הכרטיסים.
היתרון אמיתי. שום דבר לא עובר מיגרציה. הצוות שומר על הכלים ועל ה-journeys שלו, ואפשר להתחיל מתרחיש 1, כמו כרטיס מועדון.
החיסרון מצטבר עם הזמן. 2 מסדי נתונים לסנכרן, 2 מנויים, 2 סקירות אבטחה ו-GDPR. כל תרחיש שמשלב עדכון כרטיס עם הודעה, כמו “הנקודות שלך עומדות לפוג”, נבנה על פני 2 כלים.
בישראל יש לזה לא פעם שכבה שלישית: ספק SMS מקומי שעולה ביוקר לכל הודעה ובלי personalization חכם. במסלול A הוא נשאר עוד מערכת לחבר, ואתם מחזיקים 3 ספקים כדי לשלוח הודעה 1 עם כרטיס 1.
מסלול B: עוברים לפלטפורמה עם wallet נייטיב
אתם מעבירים את המסרים לפלטפורמה שמנפיקה wallet passes נייטיב, על אותו פרופיל של push, in-app, אימייל ו-SMS.
הכרטיסים מונפקים לפי User ID בתוך הפלטפורמה. ה-segments, ה-journeys והערוצים רואים את מחזיק הכרטיס כלקוח 1. שלב 1 ב-journey מנפיק את הכרטיס, והשלב הבא שולח את הקישור.
מקבלים פרופיל 1, journey 1 וחוזה 1. עדכוני כרטיס והודעות יוצאים מאותו טריגר, ואין שכבת סנכרון שצריך לשמור עליה.
המחיר הוא המיגרציה עצמה: שינויי SDK, ייבוא נתונים, בנייה מחדש של journeys ותבניות. זה משתלם כשה-wallet הוא ערוץ לטווח ארוך, לא קמפיין חד-פעמי.
| מסלול A: CEP + כלי pass | מסלול B: wallet נייטיב | |
|---|---|---|
| זמן עד הכרטיס הראשון | מהיר | תלוי במיגרציה |
| מערכות לתחזק | 2 ועוד שכבת סנכרון | 1 |
| Journeys עם עדכוני כרטיס | נבנים על פני 2 כלים | journey 1 |
| Segmentation למחזיקי כרטיסים | דרך נתונים מסונכרנים | אותו פרופיל |
| חוזים וסקירות ספק | 2 | 1 |
| מתאים ל | תרחיש wallet יחיד | wallet כערוץ retention |
מסגרת להחלטה
תנו לעצמכם ציון על 4 שאלות.
-
היקף
ה-wallet הוא קמפיין 1, או ערוץ שתפעילו שנים? קמפיין 1 מצביע על מסלול A.
-
ערוצים
כמה תרחישים משלבים כרטיס עם push, אימייל או SMS? הרבה מצביע על מסלול B.
-
צוות
יש לכם מפתחים שיבנו ויתחזקו שכבת סנכרון? אם לא, מסלול A מתייקר עם הזמן.
-
מיקום הנתונים
אתם צריכים אחסון באיחוד האירופי ופחות מעבדי מידע בשביל GDPR? כל ספק נוסף הוא עוד מעבד מידע לסקור.
אם 2 תשובות או יותר הן “לטווח ארוך”, “הרבה”, “אין מפתחים” או “פחות מעבדי מידע”, בדקו ברצינות את מסלול B. אם אף אחת לא, מסלול A הוא בחירה טובה לגמרי, ואפשר לחזור להחלטה בעוד שנה.
שאלת מיקום הנתונים כבדה במיוחד לסטארטאפים ישראליים שמוכרים לאירופה ולארה”ב מהיום הראשון. כל ספק נוסף בשרשרת הוא עוד שורה בשאלון האבטחה של הלקוח האירופי, ועוד מעבד מידע שצריך להסביר בעסקה. צוות קטן שמתרחב לחו”ל מרגיש את זה מהר יותר מארגון גדול.
כמה באמת עולים 2 כלים
מסלול A נראה זול יותר ביום הראשון, כי שום דבר לא זז. על פני שנה, הוסיפו את מה שאף פעם לא מופיע בחשבונית של ספק ה-pass: בניית האינטגרציה, תחזוקת הסנכרון, עבודת journeys כפולה וסקירת ספק שנייה.
מסלול B מקדים את העלות: עבודת מיגרציה, ואחר כך דמי פלטפורמה 1. השוו את שניהם על פני 12 עד 24 חודשים, לא חודש 1.
צ’קליסט למיגרציה
אם בחרתם במסלול B, תכננו את המעבר סביב הלקוח, לא סביב הכלי.
- מפו מה אתם שולחים. רשמו את קמפייני ה-push, האימייל, ה-SMS וה-in-app, את ה-journeys ואת ה-segments שצריכים לעבור.
- מפו את הנתונים. User IDs, תגיות, אירועים ורשומות הסכמה. ה-User ID הוא מה שקושר כרטיס ללקוח.
- הגדירו wallet פעם אחת. תעודת Apple Pass Type ID (חשבון Apple Developer, $99 לשנה) ו-Google Issuer ID, עם חשבון השירות של Pushwoosh מוזמן ל-issuer שלכם.
- שלבו את ה-SDK. החליפו את ה-SDK הישן באפליקציה ובדקו push לפני שאתם מעבירים תעבורה.
- בנו קודם את ה-journeys המרכזיים. Welcome, עגלה נטושה, win-back, ואז תרחישי ה-wallet החדשים.
- תכננו את השקת הכרטיסים. הנפיקו כרטיסים משלב ב-journey ושלחו את הקישור באימייל, ב-SMS או ב-push.
- הריצו במקביל לזמן קצר. השאירו את הפלטפורמה הישנה לחפיפה קצרה, ואז כבו אותה.
במהלך המעבר, השתמשו ב-API כדי להנפיק כרטיסים מה-backend שלכם.
כדאי לתזמן את המעבר הרחק מפיקי הקניות של השנה. ראש השנה וחגי תשרי בספטמבר–אוקטובר, פסח במרץ–אפריל ו-Black Friday בנובמבר הם בדיוק הרגעים שבהם journeys של עגלה נטושה וקמפיינים עונתיים חייבים לעבוד. תקופת החפיפה בין 2 הפלטפורמות עדיף שתיפול בחודשים שקטים יותר.
פשטו את ה-stack עם Pushwoosh
Pushwoosh מנפיקה כרטיסי Apple Wallet ו-Google Wallet נייטיב על אותם User ID, segments ו-journeys כמו push, in-app, אימייל, SMS ו-WhatsApp, שהוא ערוץ התקשורת הדומיננטי בישראל. זו פלטפורמה 1, שמתארחת על תשתית משלה בגרמניה ובארה”ב, בהתאמה ל-GDPR ועם SOC 2 Type 2. ראו איפה Pushwoosh נכנסת בין אפשרויות ה-wallet.
הוספת wallet לא צריכה להיות עוד כלי שמחברים מהצד. היא צריכה להיות פרופיל לקוח 1 שכל ערוץ יכול לפעול עליו.
