טיקט נוחת אצלכם בתור: “תוסיפו כפתור Apple Wallet למייל האישור.” נשמע פשוט, עד שבודקים לעומק ונתקלים בחוקי הבאדג’ של Apple, ב-.pkpass חתום, ובשאלה לאן בכלל הכפתור מקשר. הכפתור עצמו הוא החלק הקל; החיבור שלו ל-pass אמיתי והמיקום הנכון הם המקום שבו נתקעים.
זו הגרסה הקצרה למי שצריך לשלוח את הכפתור הזה ל-production: איפה הוא צריך לשבת במייל, באתר ובאפליקציה, אילו חוקים Apple ו-Google אוכפים, וכיצד לחבר אותו לקישור התקנה חי שבאמת שומר pass. עשוי נכון, הכפתור מעלה את שיעור ההתקנה שלכם במקום לשבת בלי שימוש בתבנית.
לחברות ישראליות שמוכרות לעולם מיום הראשון, זה לא סעיף שוליים: אם האפליקציה או האתר שלכם משרתים משתמשים בארה”ב ובאירופה לצד ישראל, שני הכפתורים — Apple ו-Google — חייבים לעבוד מהיום הראשון, לא רק ה-iOS.
איפה הכפתור באמת צריך לשבת (מייל, אתר, אפליקציה)
הכפתור עובד בשלושה מקומות, ולכל אחד יש בית טבעי שקשור לרגע שבו ל-pass יש ערך.
במייל, הוא נכנס להודעת האישור או ההצעה: קבלה על הזמנה, אישור כרטיס, הרשמה למועדון לקוחות. שימו לב: לקוח עשוי לפתוח את המייל במחשב נייד, שם הכפתור לא יעבוד, אז הוסיפו שורה כמו “פתחו את המייל הזה באייפון כדי להוסיף את ה-pass.”
באתר, הוא שייך לעמודי אישור והצעות, ליד הדבר שנשמר: מיד אחרי checkout, בעמוד אישור הזמנה, בעמוד קופון ייעודי.
בתוך האפליקציה, הוא נכנס לכל מקום שבו מידע ה-pass כבר מופיע, מיד אחרי הפעולה שיוצרת אותו: רכישה, הרשמה, הנפקת כרטיס. אפליקציות native משתמשות בפקד הכפתור של Apple עצמו ולא בתמונה.
הנחיות הכפתור הרשמיות של Apple
Apple מתייחסת לבאדג’ כאמנות מסחרית רשומה, אז החוקים מחמירים וכדאי לעמוד בהם כדי להימנע מדחייה בבדיקת האפליקציה או מכפתור שנראה שבור.
השתמשו ב-SVG הניתן להורדה של Apple לאתר ומייל, ובגרסת EPS לחומרים מודפסים עם קוד QR. אל תיצרו גרסה משלכם, ואל תשנו צבע, תסובבו, תנפישו או תוסיפו צללים לבאדג’. באפליקציות native, השתמשו בפקד PKAddPassButton, שמרנדר את המראה והשפה הנכונים אוטומטית.
בעיצוב, שמרו על רווח פנוי מינימלי סביב הבאדג’ של עשירית מגובהו, ומקמו אותו על רקע לבן או בהיר. לרקעים כהים, Apple מספקת גרסת מתאר (outline). הבאדג’ צריך להישאר משני לתוכן הראשי שלכם, לא לשלוט בפריסה.
בשמות, כתבו “Apple Wallet” באזכור הראשון ו-”Wallet” אחריו, וכללו את שורת הקרדיט המסחרי של Apple בכל מקום שבו מוצג טקסט משפטי. חוקי השמות האלה הם חלק ממה ש-Apple בודקת.
כמה טעויות גורמות לכפתורים להידחות או להיכשל בשקט. באדג’ בעיצוב אישי במקום הרשמי נכשל בבדיקה, ובאדג’ מוסתר במקום שהמטרה שלו לא ברורה מתעלמים ממנו.
קישור ל-pass לא חתום או פגום לא מוסיף כלום כשלוחצים עליו, ושמות לא עקביים כמו “שמרו לארנק האייפון” מפרים את חוקי המותג. כולם ניתנים למניעה עם האמנות הניתנת ו-pass חתום כראוי.
כפתור Add to Google Wallet: אותה עבודה, חוקים שונים
אם אתם תומכים בשני הארנקים — ורוב העסקים הצרכניים צריכים — תמקמו כפתור Google לצד כפתור Apple. העבודה זהה; הפרטים שונים.
הכפתור של Google מגיע ב-Android XML, SVG ו-PNG, בשחור בלבד, בגרסאות primary ו-condensed. הרווח הפנוי הוא 8dp קבוע מכל צד, והכפתור צריך גובה מינימלי של 48dp. חוק אחד קל לפספס: אם כפתורים אחרים חולקים את העמוד, כפתור Add to Google Wallet חייב להיות שווה או גדול מהם, לעולם לא קטן יותר.
הכפתור חייב לקרוא לתהליך Google Wallet API, שפותח את אפליקציית Google Wallet כדי שהמשתמש יוכל לשמור את ה-pass למכשיר האנדרואיד ולחשבון Google שלו. בשמות, כתבו “Google Wallet” באות גדולה ב-G וב-W, והשתמשו בטקסט הכפתור המקומי של Google ולא בטקסט משלכם.
אז זה שני כפתורים ושתי מערכות חוקים במקום אחד בתבנית שלכם. בנו את ה-pass לשני הסטנדרטים, הניחו את שני הבאדג’ים זה לצד זה, והמכשיר של הלקוח מטפל בשאר. בישראל, שבה חדירת ה-iOS גבוהה במיוחד לעומת שווקים אחרים אך Android עדיין מהותי, אין “ברירת מחדל” — שני הכפתורים חייבים לעבוד באותה רמה.
חיבור הכפתור לקישור התקנה חי
באדג’ הוא רק תמונה עד שהוא מצביע על pass אמיתי וחתום. שלושה דברים מחברים אותו למשהו שהלקוח באמת יכול לשמור.
-
יצירת קישור התקנה לכל משתמש
הכפתור מקשר ל-URL התקנה שנפתח ל-pass חתום. אפשר להפיק את ה-pass בשתי דרכים: לבנות אותו בעצמכם עם framework ה-PassKit של Apple, כלומר ליצור ולחתום על ה-.pkpass ולהריץ שירות שמארח את הקישור, או להשתמש בפלטפורמת pass שעושה את החתימה והאירוח בשבילכם. האפשרות הראשונה נותנת שליטה מלאה ומתאימה לצוותים עם משאבי backend; השנייה מהירה יותר לרוב צוותי השיווק והמוצר. עבור pass משותף, כמו קופון גנרי, קישור אחד משרת את כולם. עבור pass אישי, כמו כרטיס נאמנות עם נקודות של לקוח ספציפי, אתם מייצרים קישור ייחודי לכל משתמש כך שה-pass שנשמר נושא את הנתונים שלו. עם פלטפורמה כמו Pushwoosh Wallet passes, בונים את ה-pass פעם אחת ומייצרים את קישור ההתקנה בלי לטפל בחתימת .pkpass בעצמכם.
-
הכניסו את הכפתור לתבנית ה-ESP שלכם
בפלטפורמת המייל שלכם, מקמו את באדג' ה-SVG של Apple (ואת כפתור Google, אם אתם תומכים בשניהם) והגדירו את הקישור שלו ל-URL ההתקנה. עבור pass אישי, רוב פלטפורמות המייל מאפשרות להכניס את הקישור הייחודי כמשתנה פרסונליזציה, כך שהכפתור של כל נמען מצביע על ה-pass שלו. הוסיפו את ההערה "פתחו באייפון", ושמרו על הבאדג' על רקע בהיר לפי חוקי Apple.
-
עקבו אחרי שמירות, לא רק אחרי קליקים
קליק על הבאדג' הוא לא שמירה; הלקוח עדיין צריך לאשר הוספת ה-pass. עקבו אחרי ההוספה עצמה כאירוע נפרד, כך שאתם מודדים שיעור התקנה ולא רק click-through. המספר הזה אומר לכם אם המיקום וההצעה עובדים, וזה המדד לאמטב, כי pass שנשמר הוא זה שנשאר על הטלפון.
קישור אחד, כל ערוץ
ייצור קישור התקנה ייחודי לכל משתמש והדבקה שלו ידנית בכל ערוץ לא מתרחב מעבר לכמה קמפיינים. הקישור הוא אותו asset בין אם הוא רוכב על מייל, push או SMS, ובישראל — גם WhatsApp, ולכן הדרך היעילה היא לייצר אותו פעם אחת ולהשתמש בו בכל מקום.
עם Pushwoosh Wallet passes, בונים את ה-pass, מייצרים את קישור ההתקנה, ומפיצים אותו על פני push, מייל, SMS ו-WhatsApp ממקום אחד. כפתורי Apple ו-Google מצביעים על אותו pass, ומנהלים שמירות ועדכונים בלי לגעת בקובץ .pkpass.
הגדילו את שיעור ההתקנה של ה-wallet pass שלכם עם Pushwoosh
שלחו את הכפתור פעם אחת והשתמשו בקישור בכל מקום. Pushwoosh Wallet passes מייצר את קישור ההתקנה ל-Apple ו-Google Wallet ומפיץ אותו על פני push, מייל, SMS ו-WhatsApp מדשבורד אחד.
