עדכון wallet pass נעשה בכלי שבו בניתם את הכרטיס או דרך API. הפלטפורמה מרעננת את הכרטיס בכל מכשיר ששמר אותו, בלי התקנה מחדש. ב-Apple הלקוח רואה התראה במסך הנעילה רק על שדות שיש להם change message. ב-Google, ההתראה של Google עצמה מגיעה רק בכרטיסי loyalty, event ticket ו-flight.
זה הצד המעשי של העדכונים. את המנגנון שמתחת תמצאו באיך עובדים עדכונים של wallet pass. הדוגמאות לקוחות מ-Wallet passes של Pushwoosh, שבו כל כרטיס קשור ל-User ID ואפשר לעדכן אותו מה-builder, מקמפיין או מה-API. בישראל, שבה חדירת ה-iPhone גבוהה ו-Android עדיין חזק, כדאי לתכנן את העדכונים לשתי הפלטפורמות כבר מהיום הראשון.
מה אפשר לשנות
כמעט הכול. בכרטיסי Apple Wallet ב-Pushwoosh אפשר לערוך את שם הכרטיס והתיאור, ערכי שדות ותוויות, change messages, צבעים, הודעת הברקוד, expiration ו-status, מיקומים ו-beacons. התמונות נעולות. בכרטיסי Google אפשר להחליף גם את הלוגו ואת תמונת ה-hero, הברקוד, הקישורים וקישור האפליקציה.
דבר 1 נשאר קבוע: הסגנון או הסוג של הכרטיס. store card לא יכול להפוך לקופון, ו-loyalty pass של Google לא יכול להפוך ל-offer. אם צריך פורמט אחר, מנפיקים כרטיס חדש.
| שינוי | דוגמה | מה הלקוח רואה |
|---|---|---|
| ערך שדה | נקודות מ-120 ל-180 | הכרטיס מתרענן, ועוד התראה אם הוגדר change message |
| תאריך או שעה | ההופעה הוזזה ל-20:00 | הכרטיס מתרענן, ועוד התראה אם הוגדר change message |
| שער, מושב, רציף | שער B12 הוחלף ל-B20 | הכרטיס מתרענן, ועוד התראה אם הוגדר change message |
| צבעים (ותמונות ב-Google) | עיצוב עונתי לחגי תשרי | הכרטיס מתרענן, בלי התראה |
| מיקומים | נפתח סניף חדש | ה-relevance במסך הנעילה משתנה, בלי התראה |
| פקיעה או ביטול | המנוי הסתיים | הכרטיס הופך לאפור או עובר ל-expired |
כרטיס 1 או כל הכרטיסים בבת אחת
כל כרטיס ב-Pushwoosh שייך ל-User ID 1. זה נותן 2 דרכים לעדכן.
כרטיס 1 בכל פעם הוא המקרה היומיומי: רכישה משנה את היתרה של לקוח 1, ולכן הכרטיס שלו משתנה. כמעט תמיד תעשו את זה באוטומציה דרך ה-API או סנכרון tags, לא בקליקים ידניים.
המקרה הגורף הוא כל התוכנית: תנאים חדשים או עיצוב עונתי לכל המחזיקים, למשל לקראת ראש השנה או פסח. ב-Pushwoosh זה רץ דרך Wallet Pass Campaign. שדות שמסומנים כ-shared מתעדכנים בכל כרטיס שהונפק מהקמפיין, שדות personal שומרים את הערכים של כל לקוח, והקמפיין מראה כמה כרטיסים העריכה תשנה לפני שאתם שומרים.
בלוח השנה הישראלי יש 2 חלונות ברורים לעדכון גורף כזה: חגי תשרי בספטמבר–אוקטובר ופסח במרץ–אפריל, ואליהם מצטרף Black Friday בנובמבר. הכינו את העיצוב העונתי בקמפיין מראש, והחליפו אותו בעריכה 1 כשהעונה מתחילה. כשהחג נגמר, עריכה נוספת מחזירה את העיצוב הרגיל לכל המחזיקים, בלי להנפיק כרטיס חדש לאף אחד.
בכרטיסי Google Wallet, שדות יכולים להכיל user tags. Pushwoosh ממלאת את ערכי ה-tags כשהכרטיס נוצר ומרעננת אותם בכל עדכון, כך שהכרטיס מציג את מה שכתוב בפרופיל עכשיו. בקמפיין, tag sync עושה את זה בשתי הפלטפורמות בלי עריכה: כשה-tag שמאחורי שדה משתנה, הכרטיס מקבל את הערך החדש בבדיקה הבאה, כל 60 דקות כברירת מחדל.
Change messages: את מי מפריעים
לא כל עדכון צריך להפריע ללקוח. אתם מחליטים אילו כן.
ב-Apple מצמידים change message לשדה, למשל “Your gate is now %@”. כשהשדה משתנה, iOS מציג את ההודעה במסך הנעילה. שדות בלי הודעה מתעדכנים בשקט.
ב-Google הסוג קובע אם Google שולחת התראה משלה על שדות שהשתנו: רק כרטיסי loyalty, event ticket ו-flight מקבלים אותה, ו-Google כותבת את הטקסט. בכרטיסים לאירועים ולטיסות היא יוצאת רק כשמועד ההתחלה במרחק של פחות מ-3 שעות. בכל סוג אפשר במקום זה להצמיד לעדכון התראה מותאמת דרך ה-API או קמפיין. Google מתירה עד 3 התראות לכל כרטיס ב-24 שעות, ומעבר לזה הכרטיס מתעדכן בשקט.
כלל האצבע שלנו: התראה רק על שינויים שהלקוח צריך לפעול לפיהם, כמו שער חדש, שעה שהוזזה או נקודות שעומדות לפוג. עיצוב חדש או סניף חדש לא צריכים התראה אף פעם. ולקהלים מסורתיים, עדכון שמוציא התראה כדאי לתזמן כך שלא ייפול בשבת או בחג.
Change messages הם לא ערוץ שיווקי
מפתה להעביר מבצע דרך שינוי שדה. אל תעשו את זה. Apple ו-Google מתירות רק התראות שקשורות לכרטיס, כמו יתרה, סטטוס או לוח זמנים, והפרת הכלל הזה היא הדרך המהירה ביותר לגרום ללקוח למחוק את הכרטיס.
למבצעים, הגיעו לאותם לקוחות ב-push, במייל, ב-SMS או ב-WhatsApp, שהוא ערוץ התקשורת הדומיננטי בישראל: כל כרטיס יושב על User ID, כך שהמחזיק שלו כבר נמצא בקהל שלכם. כשהמחזיקים צריכים לשמוע על הכרטיס עצמו, למשל הטבה שמחכה להם, האפשרויות מפורטות ב-תיעוד על מסרים למחזיקי כרטיסים.
עדכון דרך ה-API
כשהשינוי מגיע מהמערכות שלכם, כמו קופה, מנוע הזמנות או ספר נקודות, השתמשו ב-API במקום ב-builder. ה-flow זהה בשתי הפלטפורמות: מזהים את הכרטיס, שולחים את הערכים החדשים, ונותנים לפלטפורמה לסנכרן. לצוותי פיתוח בסטארטאפים ובאפליקציות FinTech, שבהם היתרה מגיעה ממערכת ליבה, זו בדרך כלל הדרך היחידה שהגיונית.
רוב הסטארטאפים הישראליים מוכרים מהיום הראשון ללקוחות באירופה ובארה”ב, ולכן ה-flow של העדכון צריך לעבוד לכל השווקים בבת אחת. אותן מתודות מעדכנות כרטיס של לקוח בתל אביב ושל לקוח בברלין, והתיעוד באנגלית, כמו שהמפתחים רגילים.
המתודות והפרמטרים מפורטים ב-Apple Wallet PassKit API וב-Google Wallet API.
פקיעה, ביטול ושחזור
לכרטיסים יש מחזור חיים, ולסיים אותו נכון חשוב כמו להתחיל. כרטיס לא עדכני בארנק של מישהו גרוע יותר מאין כרטיס.
ב-Apple מגדירים expiration date, והכרטיס הופך לאפור אחריו. אפשר גם לסמן כרטיס כ-voided, למשל אחרי שקופון מומש. ב-Google, ביטול (invalidate) מעביר את הכרטיס ל-Expired passes של הלקוח, ואפשר להפעיל אותו שוב מאוחר יותר. מחיקת כרטיס Google מבטלת אותו ב-Google ומוחקת את הרשומה שלו ב-Pushwoosh.
כשעדכון לא מגיע
4 סיבות מכסות את רוב המקרים.
תעודת Apple פגה. כרטיסי Apple חתומים בתעודת ה-Pass Type ID שלכם, ואחרי שהיא פגה אי אפשר לחתום או לעדכן כרטיסים. רשמו את תאריך החידוש ביומן ביום שבו אתם מעלים אותה.
הלקוח הסיר את הכרטיס. עדכונים מגיעים רק למכשירים שבהם הוא עדיין שמור.
העדכון הגיע, אבל בלי התראה. ב-Apple בדקו שלשדה יש change message. ב-Google בדקו את סוג הכרטיס, את תיבת הסימון Notify about changed fields ואת המגבלה היומית.
הלקוח מעולם לא הוסיף את הכרטיס. כרטיס שהונפק ולא נשמר לא מקבל עדכונים. שלחו שוב את קישור ההתקנה.
כל כרטיס עדכני עם Pushwoosh
Pushwoosh מעדכנת כרטיסי Apple Wallet ו-Google Wallet נייטיב מה-builder, מקמפיין או מה-API, וכל כרטיס קשור לאותו User ID של ה-push, האימייל וה-SMS שלכם. משנים יתרה 1 או את כל התוכנית, ובוחרים אילו שינויים מצדיקים התראה.
לעדכן לקוחות זה לא לשלוח יותר. זה לדאוג שהכרטיס בארנק שלהם תמיד יהיה נכון.
