חלופה ל-Firebase Dynamic Links לאפליקציות וקמפיינים

אם אתם מחפשים חלופה ל-Firebase Dynamic Links, אל תתחילו מהשאלה "איזה מוצר מחליף את Firebase אחד לאחד". התחילו מהמיפוי של ההתנהגות שהקישורים שלכם באמת צריכים: פתיחת אפליקציה מותקנת, שליחה ל-App Store או Google Play, fallback ל-web, שמירת UTM, קישורי QR, וקישורים שמופיעים כבר באימיילים, WhatsApp, ads או affiliate pages.

לפי Firebase Dynamic Links FAQ, Dynamic Links הוצאו משימוש ונקבעו לסגירה ב-25 באוגוסט 2025. ב-2026 זה כבר לא פרויקט "נזכור לטפל בו". אם יש עדיין קישורים פעילים, צריך שכבת קישורים שנמצאת בשליטתכם: דומיין ממותג, HTTPS, כללי הפניה ברורים, native app links כאשר צריך, ויעדי fallback שנבדקו בפועל.

מה רוב הצוותים באמת צריכים

בפועל, רוב צוותי SaaS, ecommerce ואפליקציות בישראל השתמשו ב-Dynamic Links לאחת מההתנהגויות הבאות:

• iOS -> App Store.
• Android -> Google Play.
• desktop -> דף web או QR handoff.
• URL ממותג וקצר יותר מקישור חנות ארוך.
• שמירת UTM ופרטי קמפיין.
• פתיחת אפליקציה מותקנת דרך Universal Links או Android App Links.

אלה לא אותה בעיה.

Device routing הוא בעיקר redirect problem. פתיחת אפליקציה מותקנת היא עבודה של Universal Links ו-App Links. Deferred deep linking או attribution אחרי התקנה הם תחום אחר, ולעיתים דורשים SDK או מערכת attribution ייעודית. אם מערבבים את כל הדרישות יחד, קל לקנות פתרון כבד מדי או לבנות פתרון חסר.

מודל החלטה קצר

אתם צריכים רק routing לפי מכשיר

אם ה-flow הוא:

go.brand.example/sale
  -> iPhone: App Store
  -> Android: Google Play
  -> Desktop: landing page

אז שכבת smart links כמו Device targeting יכולה להספיק. זו בחירה נקייה לקמפיינים, QR, דפי download, לינקים מ-WhatsApp וקישורי שותפים.

אתם צריכים לפתוח אפליקציה מותקנת

אם משתמש שכבר התקין את האפליקציה צריך להיפתח למסך מסוים, אתם צריכים גם:

• Universal Links ל-iOS.
• Android App Links.
• association files בדומיין שלכם.
• app-side routing שמבין את ה-path.
• fallback ברור למי שלא התקין.

שכבת redirect יכולה להוביל תנועה נכון, אבל היא לא מחליפה את העבודה בתוך האפליקציה.

אתם צריכים attribution או deferred deep linking

אם צוות growth מודד install attribution, post-install routing או matching בין קליק להתקנה, שמרו על גבולות ברורים. UrlEdge יכול להיות שכבת ניתוב ממותגת ויציבה, אבל attribution עמוק שייך לכלי attribution או לקוד האפליקציה. זה צריך להופיע במסמך דרישות, לא להתגלות אחרי cutover.

ארכיטקטורה מומלצת לקישור ממותג

הבסיס הפשוט:

go.brand.example/app
  -> בדיקת device ברמת ה-Edge
  -> iOS: App Store או Universal Link target
  -> Android: Google Play או App Link target
  -> Desktop: דף landing, דף QR או web fallback

למה דומיין כמו go.brand.example עדיף על דומיין של ספק:

• הוא נשאר בשליטתכם גם אם ספק משתנה.
• קל להפריד בין קישורי marketing, app ו-docs.
• אפשר לבדוק SSL ו-DNS באופן עצמאי.
• אפשר להוסיף geo routing, analytics או overrides זמניים בלי לשנות את האפליקציה.

אל תשתמשו בדומיין אזורי אמיתי בתיעוד ציבורי. השתמשו ב-.example, במיוחד כשכותבים מדריכים או מסכים שמישהו יכול להעתיק.

תוכנית מיגרציה מעשית

1. אספו את כל הקישורים הפעילים

אל תסמכו על רשימה אחת מ-Firebase. חפשו קישורים ב:

• קמפיינים פעילים ב-Google, Meta ו-LinkedIn.
• lifecycle emails.
• QR codes בדפוס, מצגות או כנסים.
• WhatsApp messages וקבוצות מכירה.
• social bios.
• affiliate או partner pages.
• onboarding flows בתוך האפליקציה.

טבלת העבודה צריכה להיראות בערך כך:

old_link,owner,use_case,ios_destination,android_destination,desktop_destination,keep_query,notes
https://xyz.page.link/sale,growth,app download,https://apps.apple.com/app/...,https://play.google.com/store/apps/...,https://brand.example/sale,true,active QR campaign

2. סווגו לפי התנהגות, לא לפי ערוץ

קישור מ-email וקישור מ-QR יכולים לדרוש בדיוק אותו routing. קישור מ-App Store campaign וקישור referral יכולים לדרוש tracking אחר לגמרי. חלקו את הרשימה לפי:

• store fallback בלבד.
• web fallback בלבד.
• app open עם fallback.
• קמפיין עם UTM שחייב להישמר.
• כלל מיוחד לפי מדינה, device או שותף.

3. הגדירו fallback לכל פלטפורמה

אל תשאירו "fallback" כמילה כללית. כתבו יעד לכל מצב:

4. שמרו query parameters במודע

אם קישור ישן כולל utm_source, utm_campaign, coupon או affiliate ID, החלופה צריכה לשמור אותם כאשר אין סיבה להסיר. מצד שני, tokens רגישים לא צריכים לעבור אוטומטית. קבעו מדיניות במקום לסמוך על default.

אם זה החלק המרכזי בפרויקט, קראו גם את המדריך לשמירת path, query ו-UTM.

5. בדקו על מכשירים אמיתיים

סימולטור לא מספיק. בדקו לפחות:

• iPhone Safari.
• iPhone in-app browser מתוך WhatsApp או LinkedIn.
• Android Chrome.
• Android in-app browser.
• desktop Chrome.
• desktop Safari.
• מצב app installed ומצב app not installed.
• QR scan אמיתי.

השתמשו ב-בודק ההפניות כדי לראות את ה-hop בפועל, אבל אל תוותרו על בדיקה במכשירים. mobile link failures נראים לעיתים רק בתוך in-app browser.

טעויות נפוצות במעבר

מחליפים URL בלי inventory

קישורים חיים בדפוס, באימיילים ובפרופילים חברתיים. אם אין redirect map מלא, חלקם יישברו בשקט.

שוכחים desktop

פרויקט שנולד סביב iOS ו-Android עדיין מקבל קליקים מדסקטופ. דף web fallback טוב יכול להציג QR, הסבר קצר או deep link מתאים.

מאבדים UTM

הקישור עובד, אבל attribution נשבר. זה מסוג הבעיות שרואים רק אחרי שהדוחות נראים מוזר.

מבטיחים deferred deep linking בלי scope

פתיחת app store והחזרת משתמש למסך ספציפי אחרי install היא לא אותה עבודה כמו redirect. אם זה נדרש, תנו לזה בעלים ברור בצוות mobile.

איפה UrlEdge מתאים

UrlEdge מתאים כאשר צריך לשלוט בשכבת הקישורים:

• דומיין ממותג.
• device routing ל-App Store, Google Play ו-web.
• שמירת UTM ו-query.
• בדיקה לפני פרסום.
• analytics ברמת redirect.
• rollback בלי להמתין לגרסת אפליקציה.

אם אתם צריכים attribution עמוק או התאמת מסך אחרי התקנה, השתמשו ב-UrlEdge לשכבת התנועה וחברו אליה את ה-mobile stack שאחראי על attribution.

FAQ

אפשר לשמור URL אחד לכל המכשירים?

כן. זה אחד השימושים המרכזיים של smart links: URL אחד שמנתב לפי device.

האם UrlEdge מחליף Universal Links?

לא. Universal Links ו-Android App Links מטפלים בפתיחת אפליקציה מותקנת. UrlEdge מטפל בשכבת הניתוב וה-fallback.

מה אם השתמשנו ב-Firebase רק לדפי download?

אז המיגרציה יכולה להיות פשוטה יחסית: דומיין ממותג, device routing, יעדי store ברורים ושמירת UTM.

האם צריך להעביר קישור קישור ידנית?

לא אם יש inventory מסודר. ייבוא bulk של redirect map עדיף על תיקונים נקודתיים.

מקורות עזר

• Firebase Dynamic Links FAQ
• Android App Links documentation
• Apple Universal Links documentation