מה צריך להיות מקושר כדי לייבא המרות?
הטעות הנפוצה היא לחפש כפתור של קישור ישיר בין Firebase ל-Google Ads. לפי מרכז העזרה של Firebase, כדי לקשר את Google Ads צריך קודם לקשר את פרויקט Firebase לנכס GA4, כי הקישור ל-Google Ads עצמו מוגדר ומנוהל בתוך Google Analytics. כלומר GA4 הוא החוליה האמצעית ואי אפשר לדלג עליה.
שרשרת הקישורים
מהאירוע באפליקציה ועד פעולת המרה ב-Google Ads
מה הקישור נותן, לפי התיעוד: נתוני הקמפיינים של Google Ads נגישים בנכס ה-Analytics, בעוד נתוני Analytics של פרויקט Firebase, כמו אירועי מפתח וקהלים, משותפים עם Google Ads. אחרי הקישור אפשר לבחור אילו אירועים של Firebase יימדדו כפעולות המרה, כש-Google Ads משתמש בקוד של Firebase שכבר מותקן באפליקציה.
יש קישור רביעי שרלוונטי רק לחלק מהאפליקציות. לפי התיעוד, אם אתם משתמשים באירועי in_app_purchase צריך לקשר גם את Google Play, מתוך Google Analytics או מתוך הגדרות הפרויקט ב-Firebase. אחרי הקישור מוודאים שהסטטוס הוא Linked.
אילו הרשאות צריך בכל מערכת?
רוב העיכובים בפרויקטים כאלה הם לא טכניים: הם נובעים מכך שלאדם שמבצע את הקישור חסרה הרשאה באחת המערכות. לפי התיעוד של Google אלה הדרישות:
| המערכת | ההרשאה שנדרשת | למה היא נדרשת |
|---|---|---|
| פרויקט Firebase | Owner של הפרויקט | קישור הפרויקט לנכס GA4 ול-Google Ads |
| נכס GA4 | Administrator או Editor בנכס | יצירת הקישור ל-Google Ads |
| Google Ads | גישה ניהולית לחשבון או לחשבון המנהל | אישור הקישור ויצירת פעולות המרה |
| Google Play Console | בעלות על החשבון, לאפליקציות Android | דרישה מקדימה של Google לאפליקציות Android |
אם ההמרות נמדדות ברמת חשבון מנהל (MCC), או שכמה חשבונות מנוהלים צריכים גישה לקהלים, התיעוד ממליץ לקשר את הנכס או את הפרויקט לחשבון המנהל עצמו.
איך מגדירים את הייבוא שלב אחרי שלב?
- מוודאים שה-SDK מותקן ומעודכן. ה-SDK של Google Analytics for Firebase צריך להיות באפליקציה. התיעוד ממליץ על הגרסה העדכנית, בין השאר כדי שאותות הסכמה יועברו כראוי.
- מטמיעים את האירועים שרוצים למדוד. לפי התיעוד ה-SDK אוסף אוטומטית את first_open ואת in_app_purchase בלי קוד נוסף. כל פעולה אחרת, כמו הרשמה או השלמת שלב, דורשת אירוע משלה.
- מקשרים את פרויקט Firebase ל-Google Analytics. בקונסולה של Firebase נכנסים ל-Project settings ופותחים את הלשונית Integrations. שם לוחצים Link בכרטיס של Google Analytics.
- מקשרים את Google Play אם יש רכישות. ב-GA4 תחת Admin, Google Play links, או ב-Firebase באותה לשונית Integrations.
- מסמנים אירועי מפתח. ב-GA4 תחת Admin, Events, מפעילים את המתג Mark as key event לאירועים שמתכוונים להשתמש בהם לבידינג בקמפייני האפליקציה.
- מקשרים את הנכס ל-Google Ads. ב-GA4 תחת Admin, Google Ads links, לוחצים Link ובוחרים את החשבונות. לפי התיעוד פרסום מותאם אישית מופעל כברירת מחדל בקישור.
- יוצרים פעולות המרה ב-Google Ads. במסך Goals, Summary יוצרים conversion action חדש ובוחרים להשתמש בנכס המקושר למדידת פעילות באפליקציה. אירועי המפתח של הנכס הם הנתונים שמשותפים עם Google Ads.
- מפעילים auto-tagging. ב-Google Ads תחת Admin, Account settings. לפי התיעוד auto-tagging נדרש כדי למדוד המרות אפליקציה בקמפייני engagement ובקמפיינים לאתר.
- מגדירים את הבידינג. רק עכשיו בוחרים בקמפיין את פעולת ההמרה שהוא יעבוד לפיה.
פרט שחוסך בלבול: לפי התיעוד קטגוריית היעד והגדרת האופטימיזציה של פעולת המרה מיובאת נערכות רק ב-Google Ads ולא ב-Google Analytics. את סימון אירועי המפתח עצמו פירטנו באירועי מפתח ב-GA4.
אילו אירועים כדאי לייבא?
לא כל אירוע מפתח צריך להפוך לפעולת המרה לבידינג. יש שלוש קבוצות שכדאי לשקול.
הראשונה היא first_open, שמייצג התקנה. לפי התיעוד של GA4 התקנות נמדדות כ-first_open כי ה-SDK לא רץ עד שהאפליקציה נפתחת. זה אירוע הבסיס לקמפיין שמטרתו התקנות.
השנייה היא in_app_purchase לאפליקציות עם רכישות דרך החנות. היא דורשת את הקישור ל-Google Play שתיארנו.
השלישית היא פעולות בתוך האפליקציה שאתם מגדירים: הרשמה, השלמת onboarding, הזמנה ראשונה. כאן השיקול הוא עסקי: אירוע עמוק במשפך קרוב יותר להכנסה אבל קורה פחות, בעוד אירוע רדוד קורה הרבה אבל מנבא פחות. אני ממליץ ללקוחות לבחור אירוע אחד לבידינג ולייבא את השאר לצורכי דיווח בלבד. כדי שזה יעבוד השמות והפרמטרים צריכים להיות יציבים בין גרסאות, כפי שהסברנו במילון אירועים לאפליקציה.
מה שונה באפליקציית iOS?
התיעוד מציין שתי דרישות נוספות לאירועי מפתח של iOS: להוסיף App Store ID לפרויקט ב-Firebase ולהפעיל את ה-framework בשם AdSupport כדי לאפשר גישה ל-IDFA. בנוסף, לפי התיעוד של GA4 auto-tagging אינו נתמך להתקנות של אפליקציות iOS. המשמעות היא שמדידת קמפיינים ב-iOS נשענת על מנגנונים אחרים, שאותם פירטנו בATT ו-SKAdNetwork ב-iOS.
מה קורה כשיש גם AppsFlyer או מקור המרות נוסף?
הרבה חשבונות מגיעים למצב שבו אותה פעולה מיובאת פעמיים: פעם דרך כלי ייחוס של צד שלישי ופעם דרך Firebase. אין בעיה ששני המקורות קיימים בחשבון. הבעיה מתחילה כששניהם משמשים לבידינג.
מדריך המעבר של Google קובע את העיקרון: קמפיינים שעובדים לפי המרות של צד שלישי וקמפיינים שעובדים לפי המרות של Firebase לא צריכים לפנות לאותם משתמשים. אחרת, לפי התיעוד, הם עלולים להציע מחיר זה מול זה ולפגוע בביצועים של שניהם. במעבר מסודר הופכים את יעדי הצד השלישי מ-primary ל-secondary, מעלים את יעדי GA4 מ-secondary ל-primary ועוקבים אחרי הביצועים במשך שבוע.
לכן התיעוד ממליץ למי שמגיע ממקור אחר להגדיר פעולות המרה שיובאו זה עתה כ-secondary. לפי התיעוד של Google Ads פעולה שמוגדרת primary מדווחת בעמודה Conversions ומשמשת לבידינג. פעולה שמוגדרת secondary היא לתצפית בלבד: היא מופיעה בעמודה All conversions ואינה משפיעה על הבידינג, אלא אם היא חלק מיעד מותאם. את השיקולים בבחירה בין הכלים עצמם פירטנו בAppsFlyer מול Firebase.
מה בודקים אחרי הייבוא?
| הבדיקה | איפה | מה מחפשים |
|---|---|---|
| הפעולה יובאה | רשימת ההמרות ב-Google Ads | לפי התיעוד, פעולה שלא מופיעה ברשימה לא יובאה |
| הקישורים פעילים | GA4 ו-Firebase | סטטוס Linked ל-Google Play, קישור פעיל ל-Google Ads |
| primary או secondary | הגדרות פעולת ההמרה | רק פעולות שנבחרו בכוונה משמשות לבידינג |
| ספירה וחלונות המרה | עמודות Count וחלונות click-through, view-through ו-engaged-view | הגדרות שתואמות את מה שמשווים אליו |
| ערך ומטבע | האירוע באפליקציה | אותו סוג מטבע ואותם קודי מטבע בכל המקורות |
| auto-tagging | Account settings ב-Google Ads | מופעל |
לפני שבודקים ב-Google Ads כדאי לוודא שהאירוע בכלל נשלח נכון מהמכשיר. את זה עושים ב-DebugView, כמו שתיארנו בבדיקת אירועים באפליקציה לפני שחרור.
למה המספרים ב-Google Ads לא זהים ל-Firebase או לחנות?
לפי התיעוד של Google Ads הבדלים בהגדרות ההמרה הם סיבה מרכזית לפערים. מעבר לזה התיעוד מונה כמה מקרים ספציפיים לאפליקציות. הראשון: לא להשוות התקנות של Google Play ל-first_open. משתמש יכול להתקין ולפתוח את האפליקציה מאוחר יותר, כך ששני המספרים מודדים רגעים שונים. השני: Firebase סופר התקנה מחדש כהתקנה כברירת מחדל, בעוד חלק מספקי הצד השלישי סופרים אותה רק אחרי חלון ייחוס מחדש. השלישי: Google Play לא כולל רכישות שנכשלו, בעוד כלים אחרים עשויים לספור רכישה כבר בלחיצה על הכפתור.
התיעוד גם ממליץ להשוות מספר המרות ולא ערכים, כי המרה חסרה אחת יכולה לעוות את סך הערך. את הסיבות הכלליות לפערים בין שתי המערכות פירטנו בלמה מספר ההמרות ב-GA4 שונה מ-Google Ads.
שאלות נפוצות
איך מייבאים המרות מ-Firebase ל-Google Ads?
מקשרים את פרויקט Firebase לנכס GA4, מסמנים ב-GA4 את האירועים הרלוונטיים כאירועי מפתח ומקשרים את הנכס לחשבון Google Ads. אחר כך יוצרים ב-Google Ads פעולת המרה שמבוססת על הנכס המקושר. לפי מרכז העזרה של Firebase הקישור ל-Google Ads מוגדר ומנוהל בתוך Google Analytics. לכן אי אפשר לדלג על שלב ה-GA4.
האם צריך להוסיף קוד לאפליקציה כדי למדוד המרות ב-Google Ads?
לא מעבר ל-SDK של Firebase. לפי התיעוד של Google Ads אפשר לייבא המרות של Firebase בלי להוסיף קוד חדש לאפליקציה, כי Google Ads משתמש בקוד של Firebase שכבר מותקן. האירועים first_open ו-in_app_purchase נאספים אוטומטית. פעולות אחרות, כמו הרשמה, צריכות אירוע שהוטמע באפליקציה.
אילו הרשאות צריך כדי לקשר Firebase ל-Google Ads?
לפי התיעוד של Google צריך להיות Owner של פרויקט Firebase, Administrator או Editor בנכס GA4 ובעל גישה ניהולית לחשבון Google Ads או לחשבון המנהל. לאפליקציות Android נדרשת גם בעלות על חשבון Google Play Console. חסר באחת ההרשאות האלה הוא הסיבה הנפוצה לכך שהקישור נתקע.
למה מספר ה-first_open לא שווה למספר ההתקנות ב-Google Play?
כי שני המספרים מודדים רגעים שונים. לפי התיעוד התקנות נמדדות ב-Firebase כ-first_open, כי ה-SDK לא רץ עד שהאפליקציה נפתחת. משתמש יכול להתקין ולפתוח מאוחר יותר. לכן Google ממליצה לא להשוות התקנות של Google Play ל-first_open. בנוסף, Firebase סופר התקנה מחדש כהתקנה כברירת מחדל.
מה עושים אם כבר מודדים המרות דרך AppsFlyer או כלי צד שלישי אחר?
אפשר להחזיק את שני המקורות בחשבון, אבל לא להשתמש בשניהם לבידינג על אותם משתמשים. לפי מדריך המעבר של Google קמפיינים כאלה עלולים להציע מחיר זה מול זה ולפגוע בביצועים. ההמלצה היא להגדיר את פעולות ההמרה החדשות כ-secondary. במעבר מסודר מחליפים בין primary ל-secondary ועוקבים במשך שבוע.
מה צריך להגדיר במיוחד לאפליקציית iOS?
לפי התיעוד של Google Ads, לאירועי מפתח של iOS צריך להוסיף App Store ID לפרויקט ב-Firebase ולהפעיל את ה-framework בשם AdSupport כדי לאפשר גישה ל-IDFA. בנוסף, לפי התיעוד של GA4 auto-tagging אינו נתמך להתקנות של אפליקציות iOS. לכן הייחוס שם נשען על מנגנונים אחרים.
מה השורה התחתונה?
ייבוא המרות מ-Firebase ל-Google Ads הוא בעיקר עניין של קישורים והרשאות, לא של קוד. מי שמקים אותו נכון מקבל קמפיין אפליקציה שעובד לפי הפעולה שחשובה לעסק ולא רק לפי התקנות. שלוש הנקודות שבהן זה נשבר: חוליה חסרה בשרשרת בין Firebase, GA4 ו-Google Ads, שני מקורות המרה שמשמשים לבידינג במקביל והשוואה בין מספרים שמודדים רגעים שונים. אנחנו מקימים את המדידה, מייבאים את ההמרות ובודקים אותן מול הנתונים באפליקציה כחלק משירות אנליטיקס וניטור אפליקציות. אם הקמפיינים שלכם מדווחים על התקנות ואתם לא יודעים מה קורה אחריהן, כתבו לנו.
מקורות
Google Ads Help: Measure and optimize your App campaign performance using Google Analytics data, Firebase Help: Link Google Ads to Firebase, Google Ads Help: About primary and secondary conversion actions, Google Ads Help: About comparing app conversions in Google Ads, Google Ads Help: [GA4] Migrate App campaigns to use Google Analytics 4, Google Analytics Help: How app key events are attributed
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי