מה זה OneLink ומה ההבדל בין תבנית לקישור?
לפי התיעוד של AppsFlyer, OneLink הוא חבילת הכלים ליצירת קישורים שגם מודדים קמפיינים וגם מנתבים משתמשים ליעד הנכון בכל מכשיר, מערכת הפעלה וערוץ, בין אם האפליקציה מותקנת ובין אם לא. יש בו שני רכיבים שקל לבלבל ביניהם.
OneLink template היא לוגיקת הניתוב שעומדת מאחורי כל הקישורים. משתמשי קצה לא לוחצים עליה. לפי התיעוד, מעבר לבדיקות, כמעט אף אפליקציה לא צריכה יותר מתבנית אחת או שתיים. OneLink custom link הוא הקישור שלוחצים עליו או קוד ה-QR שסורקים: יוצרים אותו מתוך תבנית ומוסיפים לו פרמטרים של ייחוס ושל deep linking.
השימושים שהתיעוד מונה רחבים: מרשתות חברתיות לאפליקציה, מאתר מובייל לאפליקציה, ממייל, מ-SMS, מקוד QR על חומר מודפס ומהזמנות של משתמשים קיימים. סייג אחד שכדאי לדעת מראש: התיעוד מציין שקמפיין התקנות אפליקציה ב-Meta מקבל רק Meta App Links, כך ש-OneLink לא נתמך שם.
את השאלה מתי בכלל צריך AppsFlyer ומתי מספיק Firebase לא נפתח כאן, כי היא מפורטת במדריך AppsFlyer מול Firebase.
מה ההבדל בין deep linking ל-deferred deep linking?
ההבדל הוא מצב המשתמש ברגע הקליק. לפי התיעוד למפתחים של AppsFlyer, שני המצבים מטופלים באותו API, אבל הם מחזירים כמות שונה של מידע.
| מה משווים | Deep linking ישיר | Deferred deep linking |
|---|---|---|
| מצב המשתמש | האפליקציה מותקנת | האפליקציה לא מותקנת |
| מה קורה אחרי הקליק | מערכת ההפעלה פותחת את האפליקציה דרך Universal Link, App Link או URI scheme | המשתמש נשלח לחנות, מתקין ופותח. ה-SDK מתאים את ההתקנה לקליק |
| מה חוזר לאפליקציה | deep_link_value, deep_link_sub1-10 וכל הפרמטרים של הקישור | רק deep_link_value ו-deep_link_sub1-10 |
| איך מזהים בקוד | isDeferred מחזיר false | isDeferred מחזיר true |
השורה השלישית היא החשובה. לפי התיעוד, למשתמשים חדשים UDL מחזיר רק את פרמטרי ה-deep linking, בעוד פרמטרים אחרים כמו media_source ו-campaign חוזרים כ-null. מי שבנה את מסך הפתיחה על שם הקמפיין יגלה שלמשתמש חדש הוא ריק.
מהקליק ועד המסך
מה קורה בין לחיצה על OneLink לבין המסך שהמשתמש רואה
איך האפליקציה נפתחת מקישור?
לפני שמדברים על מסך מסוים, הקישור צריך בכלל לפתוח את האפליקציה. לפי התיעוד של AppsFlyer יש שלוש שיטות, כשכל פלטפורמה משתמשת בשתיים מהן.
| שיטה | פלטפורמה | מה צריך להגדיר |
|---|---|---|
| Universal Links | iOS 9 ומעלה | Associated Domains ב-Xcode עם applinks ותת-הדומיין של OneLink |
| App Links | Android 6.0 ומעלה | שיוך דומיין וחתימת SHA256 של האפליקציה |
| URI scheme | שתי הפלטפורמות | סכמה ייחודית, זהה ב-Android וב-iOS, שנקבעת יחד עם המשווק |
Universal Links ו-App Links דורשים קובץ שיוך דומיין: קובץ AASA ב-iOS וקובץ Assetlinks ב-Android. לפי התיעוד AppsFlyer מארחת את הקבצים האלה בעצמה, אחרי שהוגדר בתבנית הניתוב למשתמשים קיימים. URI scheme משמש כגיבוי כשהשיטות האחרות נכשלות. התיעוד מזכיר ש-Apple ו-Google לא אוכפות ייחודיות של סכמה, לכן כדאי לבחור שם שמזוהה עם המותג.
שתי נקודות שעולות ביוקר כשמגלים אותן מאוחר. הראשונה: Universal Links ו-App Links מוגדרים בתוך האפליקציה עצמה, ב-Associated Domains ב-Xcode וב-intent filter בקובץ ה-manifest של Android, כך שהם מגיעים למשתמשים רק עם גרסה חדשה בחנות. השנייה: לפי התיעוד, שינוי של תת-הדומיין של OneLink גורם לכל הקישורים הקיימים שנוצרו עם תת-הדומיין המקורי להפסיק לעבוד. בנוסף, אם לא הוגדרה אף שיטת פתיחה, משתמשים קיימים מקבלים את ההתנהגות של משתמשים חדשים, כלומר חנות או כתובת אתר.
מי עושה מה, המשווק או המפתח?
התיעוד של AppsFlyer מחלק את ההקמה בין שני בעלי תפקידים. כך נראה הסדר בפועל, כולל שלב התיאום שהתיעוד למפתחים מדגיש.
- המשווק יוצר תבנית. בתבנית נקבע לאן נשלח מי שאין לו את האפליקציה ואיך היא נפתחת אצל מי שיש לו. ל-iOS המשווק צריך מהמפתח את ה-prefix ID ואת ה-bundle ID של האפליקציה.
- המפתחים מגדירים את שיטות הפתיחה. ב-iOS מגדירים Universal Links ו-URI scheme, ב-Android מגדירים App Links ו-URI scheme. את תת-הדומיין של OneLink המפתח מקבל מהמשווק.
- מסכמים את המבנה של deep_link_value. התיעוד ממליץ בחום על ערכים דינמיים, למשל מק"ט, מזהה פוסט או נתיב, כדי שהמשווק יוכל ליצור קישורים לתוכן חדש בלי עדכון גרסה.
- המשווק יוצר קישורים. לכל קישור בוחרים את החוויה ומוסיפים פרמטרים של ייחוס ושל deep linking.
- המפתחים מממשים את UDL. השלב הזה נדרש רק אם רוצים deep linking. בלי הקוד הזה הקישור יפתח את האפליקציה במסך הבית.
השלב השלישי הוא זה שמדלגים עליו. כשאין הסכם כתוב על הערכים, כל קמפיין חדש הופך לבקשת פיתוח. חלק הפרמטרים של קישור לדוגמה נראה כך:
?c=summer_sale&deep_link_value=product_1234&deep_link_sub1=promo20הערכים כאן הם להמחשה בלבד. האפליקציה קוראת את deep_link_value, מזהה שמדובר במוצר 1234 ופותחת את עמוד המוצר. deep_link_sub1 נושא מידע נוסף, בדוגמה הזאת קוד הטבה.
איך UDL מחזיר את הנתונים לאפליקציה?
Unified Deep Linking, או UDL, הוא ה-API שמטפל גם במשתמשים קיימים וגם בחדשים. לפי התיעוד הוא דורש SDK של AppsFlyer בגרסה 6.1 ומעלה, ב-iOS וב-Android. הזרימה זהה בשתי הפלטפורמות: פתיחת האפליקציה מפעילה את ה-SDK, ה-SDK מריץ את UDL, UDL מביא את נתוני הקישור משרתי AppsFlyer וקורא לפונקציה שהמפתח מימש. ב-iOS זו didResolveDeepLink, ב-Android זו onDeepLinking.
הפונקציה מקבלת אובייקט DeepLinkResult עם סטטוס אחד משלושה: נמצא קישור, לא נמצא קישור או שגיאה. כשנמצא קישור קוראים ממנו את deep_link_value ואת deep_link_sub1 עד deep_link_sub10 ומעבירים אותם לנתב הפנימי של האפליקציה. שני פרטים מהתיעוד של Android שחוסכים שעות דיבוג: את subscribeForDeepLink קוראים לפני start. כשהאפליקציה רצה ברקע וה-LaunchMode שלה אינו standard, הפונקציה onDeepLinking לא נקראת עד שמוסיפים setIntent בתוך onNewIntent.
מתי deferred deep linking לא יעבוד?
זה החלק שהכי חשוב למשווקים להכיר, כי הוא נראה כמו באג אבל הוא התנהגות מתועדת. לפי התיעוד של AppsFlyer, UDL לא יפעיל deferred deep linking בשלושה מצבים: כשהקליק הגיע מרשת שמדווחת בעצמה (Self Reporting Network), למשל מודעות של Meta, כשבקישור אין פרמטרים כמו deep_link_value או כשעברו יותר מ-15 דקות בין הקליק להתקנה. 15 הדקות האלה הן חלון ה-lookback של UDL.
כדי לכסות את המצבים האלה התיעוד ממליץ לממש גם extended deferred deep linking, דרך הפונקציה onConversionDataSuccess. מי שמממש את שתי הדרכים צריך לוודא שרק אחת מהן מטפלת בניתוב, אחרת המשתמש ינותב פעמיים. חלון של 15 דקות הוא קצר בהרבה מחלונות הייחוס של ההתקנה עצמה. את אלה פירטנו במדריך אטריבוציה של התקנות אפליקציה.
למה הקישור נפתח בדפדפן ולא באפליקציה?
דף פתרון התקלות של AppsFlyer מונה כמה סיבות קבועות:
| הסיבה | למה זה קורה | מה עושים |
|---|---|---|
| הדבקה בשורת הכתובת | Universal Links ו-App Links עובדים רק בלחיצה על קישור, למשל מעמוד אינטרנט או ממייל | בודקים בלחיצה ולא בהדבקה בדפדפן |
| קיצור או עטיפה חיצוניים | מקצר קישורים חיצוני או מערכת דיוור שרושמת קליקים מחליפים את הקישור המקורי | מכבים את רישום הקליקים במערכת הדיוור או מוסיפים את הפרמטר af_esp=true |
| דפדפן פנימי של אפליקציה אחרת | אפליקציות חברתיות פותחות קישורים בדפדפן משלהן, בשיטות שונות | social app landing page, או URI scheme עם הפרמטר af_force_deeplink=true |
| תג קישור עם המאפיין target | לפי התיעוד, קישור שנפתח בלשונית חדשה מציג עמוד ריק ב-Chrome, ב-iOS וב-Android | מסירים את המאפיין target מהתג |
התיעוד מזהיר גם מפני שימוש לא זהיר בכתובת גיבוי (fallback URL): היא שולחת לאתר גם את מי שאין לו את האפליקציה, במקום לחנות. לכן היא מתאימה בעיקר לקמפיינים למשתמשים קיימים.
איך בודקים קישור לפני שהקמפיין עולה?
לפי התיעוד, לכל אחד משני המצבים יש בדיקה נפרדת. לבדיקת deferred deep linking רושמים את מכשיר הבדיקה ב-AppsFlyer, מפעילים debug mode, מוודאים שהאפליקציה לא מותקנת, לוחצים על הקישור ורק אז מתקינים. לבדיקת פתיחה ישירה האפליקציה צריכה להיות מותקנת עם Universal Links או App Links מוגדרים. את הקישור לוחצים מתוך המכשיר עצמו. ב-Android, כשמופיע חלון בחירת אפליקציה או שהקישור מוביל לחנות, התיעוד מפנה לבדיקת חתימת ה-SHA256 בפקודה הבאה, עם שם החבילה של האפליקציה במקום PACKAGE_NAME:
adb shell pm get-app-links PACKAGE_NAMEההמלצה שלי: לבדוק כל קישור בערוץ שבו הוא באמת יופץ. קישור שעובד מאפליקציית הפתקים יכול להיכשל בתוך אפליקציה חברתית או אחרי שמערכת הדיוור עטפה אותו.
שאלות נפוצות
מה ההבדל בין deep linking ל-deferred deep linking?
ב-deep linking ישיר האפליקציה כבר מותקנת. הקישור פותח אותה במסך מסוים. ב-deferred deep linking האפליקציה לא מותקנת: המשתמש עובר לחנות, מתקין ורק בפתיחה הראשונה מגיע למסך היעד. לפי התיעוד של AppsFlyer, במצב השני חוזרים לאפליקציה רק deep_link_value ו-deep_link_sub1 עד deep_link_sub10.
מה ההבדל בין OneLink template ל-custom link?
התבנית היא לוגיקת הניתוב: לאן נשלח מי שאין לו את האפליקציה ואיך היא נפתחת אצל מי שיש לו. משתמשים לא לוחצים עליה. ה-custom link הוא הקישור או קוד ה-QR שמופיע בקמפיין. הוא נוצר מתוך תבנית בתוספת פרמטרים של ייחוס ושל deep linking. לפי התיעוד רוב הצוותים לא צריכים יותר מתבנית אחת או שתיים.
למה deferred deep linking לא עובד בקמפיין שלי?
לפי התיעוד של AppsFlyer, UDL לא מפעיל deferred deep linking בשלושה מצבים: הקליק הגיע מרשת שמדווחת בעצמה כמו Meta, בקישור אין deep_link_value או שעברו יותר מ-15 דקות בין הקליק להתקנה. כדי לכסות את המצבים האלה מממשים גם extended deferred deep linking דרך onConversionDataSuccess.
למה OneLink נפתח בדפדפן ולא באפליקציה?
הסיבות הנפוצות לפי דף פתרון התקלות של AppsFlyer: הקישור הודבק בשורת הכתובת במקום שילחצו עליו, מקצר קישורים חיצוני או מערכת דיוור עטפו אותו או שהוא נפתח בדפדפן פנימי של אפליקציה חברתית. Universal Links ו-App Links עובדים רק בלחיצה על הקישור המקורי.
מה זה deep_link_value ומי קובע אותו?
deep_link_value הוא הפרמטר בקישור שאומר לאפליקציה איזה תוכן לפתוח. המשווק מגדיר את הערך בכל קישור. המפתח כותב את הקוד שקורא אותו ומנתב למסך. התיעוד של AppsFlyer ממליץ לסכם מראש מבנה דינמי, למשל מק"ט או מזהה פוסט, כדי שקישורים חדשים לא ידרשו עדכון גרסה.
האם צריך גרסה חדשה של האפליקציה כדי להפעיל OneLink?
להגדרה הראשונית כן: Universal Links ו-App Links מוגדרים בתוך האפליקציה עצמה, כך שהם מגיעים למשתמשים רק עם גרסה חדשה בחנות. גם מימוש Unified Deep Linking הוא קוד באפליקציה, שלפי התיעוד של AppsFlyer דורש SDK בגרסה 6.1 ומעלה. יצירת קישורים חדשים מתבנית קיימת לא דורשת גרסה.
מה השורה התחתונה?
OneLink עובד כשיש חלוקת עבודה ברורה: המשווק אחראי על התבנית והקישורים, המפתח על שיטות הפתיחה ועל UDL. המסמך שמחבר ביניהם הוא רשימת הערכים של deep_link_value. שלושת הדברים שכדאי לסגור לפני הקמפיין הראשון: מבנה דינמי לערכים, מימוש של extended deferred deep linking למצבים ש-UDL לא מכסה ובדיקה של כל קישור בערוץ שבו הוא יופץ. אנחנו מלווים הקמות כאלה, מהאפיון ועד הבדיקה מול המפתחים, כחלק משירות אנליטיקס וניטור אפליקציות. אם הקישורים שלכם פותחים את האפליקציה במסך הבית או לא פותחים אותה בכלל, כתבו לנו.
מקורות
AppsFlyer Help Center: OneLink guide, AppsFlyer Dev Hub: Deep Linking work flow, AppsFlyer Dev Hub: iOS Unified Deep Linking, AppsFlyer Dev Hub: Android Unified Deep Linking, AppsFlyer Dev Hub: iOS initial setup, AppsFlyer Help Center: OneLink troubleshooting and FAQ
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי