ייצוא GA4 ל-BigQuery: מה זה פותח, כמה זה עולה, ואיפה זה נשבר

יש משפט אחד בתיעוד של Google שמסביר למה הכתבה הזו קיימת: "Once you export data from Analytics to BigQuery, you cannot re-export it". כלומר, אין מילוי היסטורי. הנתונים בטבלה מתחילים ביום שבו לחצתם על כפתור החיבור, וכל יום שעבר לפני כן לא יגיע לשם לעולם.

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

קשור לכתבה זו ←

תקציב שיווק 2027: איך מתכננים כשהאורגני נשחק ועלויות ה-AI עולות POAS: איך מודדים מדיה לפי רווח ולא לפי הכנסה

אז הנה מה שהייצוא באמת עושה, מה הוא לא עושה, כמה הוא עולה לפי המחירון עצמו, ומה המצב האמיתי של שכבת ה-AI שמבטיחה לכם לשאול את הנתונים בשפה טבעית.

מה בדיוק יוצא, ומה נשאר מאחורי

יש שני סוגי ייצוא, והם לא אותו דבר במהירות שונה. הייצוא היומי, לפי התיעוד של Google, "מייצא את כל נתוני האירועים הגולמיים והלא דגומים פעם ביום, מהיום הקודם", בדרך כלל אחר הצהריים לפי אזור הזמן של הנכס, ולעיתים באיחור עד למחרת. הוא יוצר טבלה בשם events_YYYYMMDD.

הייצוא בזמן אמת, ה-Streaming, נשמע כמו שדרוג. הוא לא. אותו תיעוד קובע עליו שהוא "פועל ללא התחייבות לשלמות הנתונים ועלול להכיל פערים בנתונים". בנוסף הוא לא מכיל נתוני מקור תנועה של משתמש חדש או סשן חדש, שזו בדיוק הסיבה שרוב אנשי השיווק רוצים את הנתונים מלכתחילה. הכלל הפשוט: ה-Streaming טוב לניטור תפעולי, הייצוא היומי הוא מה שמדווחים ממנו.

הנקודה שהכי חשוב להפנים היא שהייצוא הוא לא גרסה מורחבת של הממשק. הוא גרסה אחרת. דף ההשוואה הרשמי בין משטחי הדיווח מגדיר את תוכן הייצוא כנתוני אירוע ומשתמש, ללא תוספות הערך ש-Google מבצעת בדוחות הסטנדרטיים ובניתוחים. זו לא הערת שוליים, זו הגדרה.

הטיעון החזק, ובניסוח המדויק שלו

הטענה שחוזרת בכל בלוג בנושא היא ש-GA4 מוחק לכם את הנתונים אחרי ארבעה עשר חודשים. זה ניסוח לא מדויק, ואני מעדיפה את הגרסה שבאמת כתובה בתיעוד.

דף שמירת הנתונים קובע שתקופת השמירה לנכס סטנדרטי היא חודשיים או ארבעה עשר חודשים, ברמת משתמש וברמת אירוע. הוא גם קובע במפורש שההגדרה "לא משפיעה על דוחות מצטברים סטנדרטיים, כולל ממדים ראשיים ומשניים", ושהיא "משפיעה רק על Explorations ועל דוחות משפך". כלומר הדוחות הסטנדרטיים שלכם ימשיכו להציג נתונים ישנים. מה שנחסם הוא היכולת לחתוך את אותם נתונים ברמת אירוע או משתמש בכלי הניתוח המפורטים.

זה עדיין מגביל מאוד, כי שם נעשה הניתוח האמיתי. אבל זו מגבלת חיתוך, לא מחיקה גורפת. נכסי Large ו-XL מוגבלים לחודשיים בלבד, ונתוני גיל, מגדר ותחומי עניין מוגבלים תמיד לחודשיים ללא קשר להגדרה. שינוי ההגדרה נכנס לתוקף אחרי המתנה של עשרים וארבע שעות.

נקודה אחת שאני חייבת לסמן בכנות: רבים כותבים שברירת המחדל בנכס חדש היא חודשיים. לא הצלחתי לאמת את המילה "ברירת מחדל" בדף הרשמי. הדף מציג את שתי האפשרויות בלי לציין איזו מהן מוגדרת מראש. לכן במקום להסתמך על ההנחה, פשוט פתחו את ההגדרות ובדקו מה מוגדר אצלכם עכשיו. מי שרוצה להעמיק בשאר ההגדרות שמשפיעות על איכות המדידה ימצא את זה במדריך GA4 המלא למשווקים.

מה הייצוא באמת פותר

שתי בעיות, ושתיהן מתועדות במספרים. הראשונה היא דגימה. Google מתעדת שדגימה עשויה להתרחש כשמספר האירועים בשאילתה עובר את המכסה, ושהמכסה לנכס סטנדרטי היא עשרה מיליון אירועים. אתר ישראלי בינוני לא מתקרב למיליון אירועים ביום, אבל הוא בהחלט עובר עשרה מיליון אירועים בשאילתה שמשתרעת על חצי שנה. זו הבעיה האמיתית של רוב הקוראים שלי, לא נפח.

השנייה היא קרדינליות. שורת (other) מופיעה כשמספר השורות בטבלה עובר את מגבלת השורות שלה, ו-Google מגדירה כהנחיה שכל ממד עם יותר מחמש מאות ערכים ייחודיים נחשב ממד בעל קרדינליות גבוהה. הדוגמה הרשמית בתיעוד: דוח עם מגבלה של מאה אלף שורות ונכס עם מאה חמישים אלף עמודים ייחודיים, חמישים אלף העמודים הפחות נפוצים מקובצים תחת (other). חשוב להבין שזו דוגמה להמחשה. המספרים בפועל למגבלות השורות בנכס סטנדרטי מול 360 לא מפורסמים.

מה שמשכנע כאן הוא לא הניתוח שלי אלא ההמלצה של Google עצמה. בדף ההסבר על אחסון והצגת נתונים היא כותבת שאפשר "לייצא את הנתונים מנכס ה-Analytics אל BigQuery כדי לקבל תוצאות לא דגומות, או לצמצם את טווח התאריכים". כשהיצרן ממליץ על המעקף, זה בדרך כלל אומר שהמגבלה אמיתית.

מה הייצוא לא פותר, וכדאי לדעת מראש

כאן רוב התוכן בנושא מטעה. הטענה שהייצוא "מחזיר לכם את הנתונים שהוסתרו בסף גילוי" הפוכה מהמציאות. התיעוד קובע במפורש: "Analytics doesn't export data from Google signals to BigQuery". לא תראו שורות מוסתרות כי אין שם נתונים להסתיר. מי שצריך דמוגרפיה נשאר בממשק.

אותו דבר לגבי מידול. Minhaz Kazi, Developer Advocate ב-Google Analytics, כתב על זה מאמר שלם באפריל 2023, ומשפט אחד בו מסכם את הכל: "None of the modeled data is available in the BigQuery event export". מידול הסכמות ומידול התנהגותי לא עוברים. גם ייחוס מבוסס נתונים לא עובר, מה שמשנה לגמרי את הדרך שבה בונים דוח ערוצים. מי שעובד היום על מדידת ייחוס ימצא את ההקשר הרחב במדריך הייחוס בעידן שאחרי העוגיות.

שלוש נקודות נוספות מאותו מאמר שכדאי לשמור לפני ההשוואה הראשונה בין המספרים. הממשק משתמש באלגוריתם HyperLogLog++ כדי להעריך קרדינליות של משתמשים פעילים וסשנים, כלומר המספר בממשק הוא קירוב. המילה "משתמשים" בממשק מתייחסת בדרך כלל למשתמשים פעילים, ולכן חישוב מ-BigQuery מחייב סינון מתאים כדי להיות בר השוואה. והטבלאות היומיות ממשיכות להתעדכן עד שבעים ושתיים שעות אחרי התאריך שלהן, כך שהשוואה שנעשית למחרת בבוקר תיכשל גם אם עשיתם הכל נכון.

ולבסוף המגבלה התפעולית. נכס סטנדרטי מוגבל למיליון אירועים ביום בייצוא היומי, ול-Streaming אין מגבלת נפח. מה קורה כשעוברים את מיליון האירועים? Google לא מתעדת את זה. חיפשתי, ואין בדף שום משפט שמסביר אם הייצוא נעצר, אם אירועים נשמטים, או אם הקישור מושהה. כל תיאור ספציפי שתמצאו בבלוגים הוא השערה. ההמלצה המעשית היחידה שאפשר לגזור מזה: אל תתכננו לעבוד קרוב לגבול.

כמה זה עולה, עם ההנחות גלויות

מחירון BigQuery נותן שכבה חינמית של טרה-בייט אחד של עיבוד שאילתות בחודש, ועשרה ג'יגה-בייט אחסון בחודש. שאילתות On-demand מעבר לכך מתומחרות ב-6.25 דולר לטרה-בייט. אחסון לוגי פעיל מתומחר ב-0.000031507 דולר לגיגה-בייט לשעה, ואחסון לטווח ארוך, שמוחל אוטומטית אחרי תשעים ימים רצופים ללא שינוי בטבלה, ב-0.000021918 דולר לגיגה-בייט לשעה.

המחירון נוקב בשעות, לא בחודשים, אז הנה החישוב עם ההנחה גלויה. בהנחה של 730 שעות בחודש, אחסון פעיל יוצא בקירוב 0.023 דולר לגיגה-בייט לחודש, ואחסון לטווח ארוך בקירוב 0.016 דולר. המספרים האלה הם חישוב שלי, הם לא מופיעים ככה בדף.

הייצוא בזמן אמת הוא הפריט היחיד שמייצר עלות קבועה ומיידית. GA4 עצמה מציינת שהוא עולה חמישה סנט לכל ג'יגה-בייט שנקלט, וזה תואם למחיר ה-streaming inserts במחירון BigQuery, סנט אחד לכל מאתיים מביבייט. הייצוא היומי, לעומת זאת, נכנס דרך טעינת batch, שמופיעה ברשימת הפעולות החינמיות.

שתי הערות שחייבות להיאמר. הראשונה: המחירון כולל בורר אזורים, ולא הצלחתי לאמת את השורה הספציפית של me-west1 בתל אביב. המספר 6.25 דולר לטרה-בייט הוא המחיר המוצג, ואני לא יכולה לאשר שהוא זהה באזור הישראלי. בדקו בבורר לפני שאתם בונים תקציב. השנייה: ה-sandbox נראה כמו דרך לנסות בלי חשבון חיוב, אבל כל הטבלאות בו פגות אוטומטית אחרי שישים יום, ואין בו תמיכה ב-Streaming. מי שמחבר ייצוא כדי לשמור נתונים לטווח ארוך ומשתמש ב-sandbox עושה בדיוק את ההפך ממה שהתכוון.

ההקמה: חמישה שלבים

ההקמה עצמה קצרה, והיא בעיקר שאלה של הרשאות. הנה מה שהתיעוד הרשמי מגדיר, לפי הסדר.

שכבת ה-AI ב-2026: מה באמת זמין

השכבה הזו התבגרה השנה, וכדאי להפריד בין מה שזמין באופן כללי לבין מה שעדיין ב-Preview. לפי הערות הגרסה הרשמיות, ה-Conversational Analytics API הגיע לזמינות כללית ב-23 ביוני 2026 עבור BigQuery ו-Looker, יחד עם תמיכה ברזידנציית נתונים, CMEK ויומני ביקורת. בספטמבר 2026 נוספו תצפיתיות על סוכנים ותאימות HIPAA. מצב Deep Dive עבור BigQuery נשאר ב-Preview.

דף הסקירה של Gemini ב-BigQuery מסמן כזמינים באופן כללי את data canvas, את הניתוח השיחתי, את הפקת התובנות ואת סיוע כתיבת ה-SQL. לעומת זאת יצירת שאילתות דרך Gemini Cloud Assist, השלמת שאילתה, והמרת הערות ל-SQL מסומנות כ-Preview. מבחינת עלות, תכונות הליבה זמינות ללא חיוב נוסף, אבל סוכני ה-Conversational Analytics מריצים שאילתות אמיתיות ולכן יוצרים עלות שאילתה רגילה. Google ממליצה שם על מכסות יומיות ברמת פרויקט ועל הגדרת big_query_max_billed_bytes, שגורמת לשאילתה חורגת להיכשל בלי חיוב.

במקביל יש שני שרתי MCP שונים, וחשוב לא לבלבל ביניהם. שרת ה-MCP של BigQuery חושף כלים כמו list_table_ids, get_table_info ו-execute_sql, והוא ניגש לנתונים הגולמיים. שרת ה-MCP של Google Analytics, לעומת זאת, מוגדר במפורש כזמין "לבקשות קריאה בלבד" והוא פונה ל-API של Analytics. כלומר הוא כפוף בדיוק לאותה דגימה, לאותו סף גילוי ולאותה שורת (other) שיש בממשק. שני דברים שונים לגמרי שנמכרים תחת אותה הבטחה. מי שרוצה להבין את הפרוטוקול עצמו ימצא הסבר במדריך MCP לפלטפורמות שיווק.

למה "פשוט תשאלו את הנתונים" עדיין לא עובד על GA4

יש כאן מגבלה מתועדת שמתאימה במדויק לסכימה של GA4, וכמעט אף אחד לא מצטט אותה. תיעוד data canvas מפרט שפקודות בשפה טבעית "עלולות לא לעבוד טוב" עם שדות מקוננים וחוזרים, ועם טיפוסי נתונים מורכבים. תמיכת ה-JOIN בשפה טבעית מתועדת כפעולות על שתי טבלאות.

ועכשיו תסתכלו על סכימת הייצוא של GA4. השדות המרכזיים שלה, event_params, user_properties ו-items, כולם מסוג RECORD ו-REPEATED. זאת אומרת שהמגבלה המתועדת של Google חלה בדיוק על מבנה הנתונים שאנחנו מייצאים. אפילו שאילתה בסיסית של שם עמוד דורשת פירוק:

SELECT (SELECT value.string_value FROM UNNEST(event_params)
        WHERE key = 'page_location') AS page, COUNT(*) AS events
FROM `project.analytics_XXXXX.events_*`
GROUP BY page

זה לא מסובך לאנליסט, אבל זה בדיוק סוג המבנה שהמודלים מתקשים איתו. ולמספרים יש גיבוי. Spider 2.0, מחקר שהוצג ב-ICLR 2025, בדק שש מאות שלושים ושתיים משימות text-to-SQL מעולם ארגוני אמיתי, על מסדי נתונים עם למעלה מאלף עמודות, כולל BigQuery. סוכן מבוסס o1-preview פתר 21.3 אחוז מהמשימות, לעומת 91.2 אחוז על הגרסה הפשוטה יותר של אותו מבחן.

אני מצטטת דווקא את המספר הזה ולא את לוח התוצאות העדכני, שמציג ציונים גבוהים בהרבה, כי ההגשות ללוח הן דיווח עצמי של ספקים ולא הערכה בלתי תלויה. המספר מהמאמר המבוקר עמיתים הוא מה שאפשר להסתמך עליו. Google עצמה מנסחת את זה בצורה ברורה בתיעוד: מוצרי Gemini "עלולים לייצר פלט שנראה סביר אך שגוי עובדתית", ויש לאמת כל פלט לפני שימוש. שאילתה שמחזירה מספר תקין תחבירית ושגוי מבחינת ההגדרה העסקית היא הסיכון האמיתי, לא שאילתה שנכשלת.

ארבע נקודות ישראליות שכדאי לסדר מראש

הנקודה השנייה ראויה להרחבה נפרדת, ויש לנו אותה במדריך תיקון 13 לנתוני שיווק. כאן מספיק לומר שהמעבר מאגרגציה לרמת משתמש הוא שינוי מעמד של הנתונים, ושכדאי לשתף את מי שאחראי על זה אצלכם עוד לפני שמחברים.

שאלות נפוצות

האם כדאי להפעיל גם Streaming וגם ייצוא יומי?

תלוי למה אתם צריכים את הנתונים. הייצוא היומי הוא מה שמדווחים ממנו, כי הוא מלא, לא דגום, וכולל את נתוני ייחוס המשתמש. ה-Streaming מוגדר בתיעוד כפועל ללא התחייבות לשלמות ועלול להכיל פערים, והוא גם לא כולל מקור תנועה של משתמש חדש או סשן חדש. הוא גם הפריט היחיד שמייצר עלות מיידית, חמישה סנט לכל ג'יגה-בייט שנקלט. ההמלצה שלי לרוב הצוותים: להתחיל עם יומי בלבד, ולהוסיף Streaming רק כשיש שימוש תפעולי אמיתי שמצדיק את העלות, למשל ניטור של קמפיין בהשקה.

אם אני מחברת היום, האם אקבל את הנתונים של השנה שעברה?

לא, ואין דרך לעקוף את זה. התיעוד של Google קובע שאחרי שנתונים יוצאו מ-Analytics ל-BigQuery אי אפשר לייצא אותם שוב, ולכן גם אין מנגנון שמושך אחורה נתונים שלא יוצאו מלכתחילה. הטבלה מתחילה מהיום שבו הקישור נוצר, ונתונים אמורים להופיע תוך עשרים וארבע שעות. זו בדיוק הסיבה שאני ממליצה לחבר את הייצוא גם לצוותים שאין להם היום יכולת לשאול SQL. העלות בשכבה החינמית אפסית עבור רוב האתרים הישראליים הבינוניים, והנכס שנצבר הוא נכס שלא ניתן לשחזר בדיעבד.

למה המספרים ב-BigQuery לא מתאימים למה שאני רואה בממשק?

כי הם לא אמורים להתאים. שלוש סיבות מתועדות, וכולן מכוונות. הממשק משתמש באלגוריתם HLL++ להערכת קרדינליות של משתמשים וסשנים, כלומר המספר שם הוא קירוב. המילה "משתמשים" בממשק מתייחסת בדרך כלל למשתמשים פעילים, ולכן חישוב פשוט מ-BigQuery יחזיר מספר גבוה יותר. ונתונים מבוססי מידול, כולל מידול הסכמות וייחוס מבוסס נתונים, פשוט לא נמצאים בייצוא. בנוסף, הטבלאות היומיות ממשיכות להתעדכן עד שבעים ושתיים שעות אחרי התאריך שלהן, אז השוואה שנעשית מוקדם מדי תיכשל גם כשהכל מוגדר נכון.

האם אפשר לתת לאיש שיווק לשאול את הנתונים בשפה טבעית בלי אנליסט?

חלקית, ועם בקרות. ה-Conversational Analytics API זמין באופן כללי מיוני 2026, ו-data canvas זמין אף הוא. אבל התיעוד של Google מציין במפורש ששאילתות בשפה טבעית עלולות לא לעבוד טוב עם שדות מקוננים וחוזרים, וזו בדיוק הסכימה של GA4. במחקר Spider 2.0 סוכן מתקדם פתר 21.3 אחוז ממשימות ה-SQL הארגוניות. מה שכן עובד היום: להגדיר טבלאות ביניים שטוחות עם המדדים שהצוות באמת שואל עליהם, ולתת לשכבת השפה הטבעית לעבוד מולן ולא מול הטבלה הגולמית. בנוסף, הגדירו מכסות תקציב לפני שנותנים גישה. מי שבונה תשתית כזו ימצא מסגרת מלאה במדריך בניית תשתית נתונים מוכנה ל-AI.

מה עושים עם זה

פעולה אחת, השבוע: פתחו את הגדרות הנכס, בדקו מה מוגדר בשמירת הנתונים, וחברו את הייצוא היומי ל-BigQuery בשכבה החינמית. בלי Streaming, בלי sandbox, עם בחירה מודעת של האזור. זה לוקח פחות משעה ולא עולה כסף ברוב המקרים. את שכבת ה-AI, את הטבלאות המעובדות ואת הדוחות תבנו אחר כך, כשיהיה מה לבנות עליו. מה שלא ניתן לעשות אחר כך זה להחזיר את הימים שלא חוברו.