UrlEdge
חזרה לבלוג
2026-04-30 צוות UrlEdge4 min read

איך להגדיר Universal Links ו-App Links אחרי Firebase

Firebase Dynamic Links כבר מאחורינו. כך בונים מחדש Universal Links, Android App Links ו-fallback ברור בלי לשבור קישורי קמפיין וקישורים ציבוריים לאפליקציה.

קישור ממותג שמפנה לאפליקציה, לחנות או ל-web לפי סוג המכשיר

אם עדיין יש לכם קישורי page.link ישנים בתוך QR, קמפיינים, מיילים, דפי download או flows של referral, אתם כבר לא מחפשים רק "תחליף ל-Firebase". אתם מנסים להחזיק שכבת קישורים ציבורית יציבה בלי לשבור פתיחת אפליקציה, fallback ומדידת קמפיין.

לכן כדאי לפרק את מה ש-Firebase Dynamic Links איחדו לתוך מוצר אחד:

  1. ה-URL הציבורי הממותג
  2. פתיחת אפליקציה מותקנת
  3. fallback ל-App Store, Google Play או web
  4. שמירת UTM ופרמטרים של קמפיין

לפי Firebase Dynamic Links FAQ, השירות נסגר ב-25 באוגוסט 2025. אם קישורים ישנים עדיין חיים בתוך קמפיינים, QR, onboarding או דפי תמיכה, עדיף לבנות שכבת קישורים מסודרת יותר מאשר לחפש clone כמעט זהה.

מה Universal Links ו-App Links באמת עושים

Apple Universal Links מאפשרים לפתוח אפליקציית iOS מותקנת מתוך קישור HTTPS רגיל, בתנאי ש:

  • הדומיין משויך נכון לאפליקציה
  • ה-capability מוגדרת
  • יש apple-app-site-association תקין
  • האפליקציה יודעת לטפל ב-path שמתקבל

Android App Links עושים את אותו הדבר ב-Android. בשביל זה צריך:

  • דומיין מאומת
  • manifest מוגדר נכון
  • assetlinks.json תקין
  • path handling בתוך האפליקציה

מה זה לא פותר לבד

Universal Links ו-App Links לא פותרים מעצמם:

  • fallback לדסקטופ
  • יעד למשתמשים בלי אפליקציה מותקנת
  • URL ממותג להפצה בקמפיינים
  • ניתוב לפי device
  • שמירת UTM
  • overrides זמניים בזמן השקה או קמפיין

לכן עדיין צריך שכבת redirect / routing.

הארכיטקטורה הכי בריאה אחרי Firebase

עבור רוב הצוותים, המבנה הכי תחזוקתי נראה כך:

go.yourbrand.com/promo
  -> זיהוי device ברמת ה-Edge
  -> iPhone עם אפליקציה: Universal Link
  -> iPhone בלי אפליקציה: App Store
  -> Android עם אפליקציה: App Link
  -> Android בלי אפליקציה: Google Play
  -> Desktop: landing page, docs או עמוד QR

היתרונות ברורים:

  • הדומיין נשאר בשליטתכם
  • ה-fallback מפורש
  • השיווק מפיץ URL אחד נקי
  • mobile, growth והמוצר בודקים את אותו flow אמיתי

איפה צוותים נתקעים בפועל

התקיעות הנפוצה היא סביב קבצי האימות:

  • apple-app-site-association
  • assetlinks.json

במיוחד כשהאתר הראשי יושב על Shopify, Wix, Webflow או CMS שמקשה על root path ו-.well-known.

כאן UrlEdge נכנסת בצורה מעשית. עם custom response אפשר להחזיר את הקבצים האלה מה-Edge בלי לבנות תהליך פריסה נפרד רק בשביל כמה קבצי אימות.

איך ניגשים למיגרציה

1. ממפים את כל הקישורים הציבוריים

בודקים:

  • קמפיינים בתשלום
  • QR codes
  • כפתורי download
  • מיילי lifecycle
  • דפי תמיכה
  • social bio links
  • referral flows

2. מפרידים בין פתיחת אפליקציה ל-fallback

לכל קישור חשוב עונים:

  1. אם האפליקציה מותקנת, האם צריך לפתוח אותה?
  2. אם היא לא מותקנת, האם הולכים ל-store או ל-web?
  3. מה רואה משתמש desktop?
  4. האם צריך לשמור UTM או פרמטרי קמפיין?

3. בוחרים דומיין ציבורי קנוני

למשל:

  • go.yourbrand.com
  • app.yourbrand.com
  • links.yourbrand.com

כך שכבת הקישורים הציבורית לא תלויה ב-hostname של ספק צד שלישי.

4. מאמתים את קבצי הקישור

עובדים מול התיעוד הרשמי:

אם השלב הזה לא מדויק, פתיחת האפליקציה תישאר לא יציבה גם אם ה-redirect הכללי נראה תקין.

5. מגדירים fallback מפורש

למשל:

  • iOS עם אפליקציה -> app
  • iOS בלי אפליקציה -> App Store
  • Android עם אפליקציה -> app
  • Android בלי אפליקציה -> Google Play
  • desktop -> landing או QR handoff

לא משאירים את זה לניחוש.

6. בודקים בהקשר אמיתי

מומלץ לבדוק לפחות:

  • iPhone Safari
  • Android Chrome
  • דפדפני in-app מתוך social apps
  • desktop
  • QR scan מהטלפון
  • קישורים עם UTM

כאן רואים את ההבדל בין "הקישור מחזיר תשובה" לבין "החוויה באמת נכונה".

טעויות נפוצות

לא. routing בוחר יעד. Universal Links ו-App Links אחראיים לפתיחה native ברמת מערכת ההפעלה.

לשכוח את הדסקטופ

fallback חלש לדסקטופ שובר מהר מסלולי תמיכה, docs, enablement ומקרי שימוש של QR.

לאבד UTM

אם הקישורים חיים באימייל, QR, paid social או שותפים, צריך לשמור את הפרמטרים בצורה מכוונת.

להעמיס שכבות

ככל שיש יותר shorteners, redirects ביניים ודפי מעבר, כך troubleshooting נהיה איטי יותר.

איפה UrlEdge משתלבת

UrlEdge מתאימה כשצריך לרכז:

  • URL ציבורי ממותג
  • routing לפי device
  • fallback ל-store או web
  • שמירת UTM
  • analytics לקליקים
  • הגשת קבצי אימות מה-Edge

היא לא מחליפה לבדה attribution mobile מתקדם, אבל היא מחזירה שליטה על השכבה הכי גלויה: הקישור הציבורי והתנהגות ה-fallback.

לסיכום

אחרי Firebase Dynamic Links, הפתרון הנכון הוא בדרך כלל לא "עוד קופסה שחורה", אלא מבנה ברור יותר:

  • דומיין ממותג
  • routing לפי device
  • Universal Links ו-App Links מוגדרים נכון
  • fallback מפורש
  • פרמטרי קמפיין שנשמרים

פחות קסם. יותר שליטה.

נהלו הפניות וקישורי קמפיין ב-UrlEdge

חברו דומיין, בדקו redirect chain ופרסמו כללי ניתוב ברמת ה-Edge.

התחלה

מאמרים קשורים

הצגת הכל