אנליטיקס לאתר עסקי — GA4, Plausible, PostHog ו-Vercel
איזה אנליטיקס לאתר עסקי לבחור ב-2026 — GA4, Plausible, PostHog או Vercel: מה למדוד, איך לא להעמיס על הביצועים, ואיך לכבד פרטיות ותיקון 13.
למי זה מתאים: יש לך אתר עסקי או SaaS. אתה רוצה לדעת מה קורה — מי מגיע, מה הם עושים, איפה הם נופלים — אבל אתה לא רוצה להפוך לאנליסט במשרה מלאה, ואתה לא רוצה שהאתר שלך יהיה משואת מעקב שמאיטה את העמודים ושוברת את חוק הגנת הפרטיות. המדריך הזה נותן לך תמונה ברורה של ארבעת כלי האנליטיקס לאתר עסקי הרלוונטיים ב-2026 — GA4, Plausible, PostHog ו-Vercel — ואיך לבחור ביניהם בלי לטעות.
לפני שמודדים — תשאל את עצמך שאלה אחת
יש פיתוי אדיר להתקין אנליטיקס ביום הראשון של פרויקט חדש. כי ״כולם עושים״. כי גוגל אומר. כי אם אין מספרים זה לא רציני.
תעצור שנייה. מה ההחלטה שאתה מתכוון לקבל מהמספרים?
אם התשובה היא ״לא יודע, אני סתם רוצה לראות״ — אתה לא צריך אנליטיקס. אתה צריך לחזור לעבוד על המוצר עד שיהיו לך מספיק משתמשים שיהיה משהו לראות.
90% מבעלי אתרים קטנים מתקינים GA4, נכנסים לדשבורד פעמיים בחודש הראשון, ואז לעולם לא יותר. הם נכנסים, רואים מספר (״היה לי 47 ביקורים השבוע!״), מרגישים טוב או רע לרגע, וסוגרים. זה לא אנליטיקס — זו תרפיה.
אנליטיקס אמיתי שואל שאלות שאפשר לפעול על התשובה שלהן:
- כמה מבקרים שמגיעים מ-Google Ads ממלאים את טופס יצירת הקשר? — מספר נמוך מדי? תכבה את הקמפיין או תשנה את הקריאייטיב. (אם אתה רץ קמפיינים, כדאי לקרוא קודם את Google Ads לעסקים קטנים בישראל — שם מסבירים איך לחבר את הקליק לליד.)
- כמה משתמשים שנכנסים למסך התמחור לוחצים על ״נסה חינם״? — נמוך? נסה לשנות את הטקסט בכפתור.
- כמה משתמשים שנרשמו לטריאל מגיעים בכלל לרגע הראשון של ערך במוצר? — אם רוב הנרשמים לא מגיעים, ה-onboarding שבור.
זה הסוג של שאלות שאנליטיקס פותר. כל השאר — קישוט.
מטריקות שכן חשובות — ומטריקות שאתה יכול לזרוק
יש שלוש קבוצות של מטריקות שכמעט כל מי שמסתכל בדשבורד מתפתה לעקוב אחריהן, ורובן מטעות.
Bounce Rate. ב-GA4 הישן בגרסת UA, bounce היה אחוז המבקרים שראו דף אחד ועזבו. זה היה מספר מטעה אז, וגרוע יותר היום. בלוג עם פוסט מעולה ידחוף את ה-bounce ל-90%+ — כי הקורא בא, קרא, הסתפק, ועזב מרוצה. ב-GA4 החדש המטריקה הוחלפה ב-״Engagement Rate״, שזה גם לא נהדר אבל יותר ישר: אחוז המבקרים שהקדישו לפחות 10 שניות, או הגיעו ל-2 דפים, או ביצעו אירוע מוגדר. תסתכל על Engagement Rate. תזרוק את Bounce.
Session Duration. כמה זמן מבקר היה באתר. נשמע חשוב. אבל GA4 לא יודע באמת — אם המבקר ראה דף אחד, GA4 לא יודע מתי הוא יצא, ומחשיב את ה-session כ-0 שניות (זאת הסיבה ש-bounce sessions נראים תמיד עם duration אפס). זה אומר שאתר עם הרבה מבקרים שקוראים פוסט בודד יראה session duration ממוצע נמוך — וזה לא ביג דיל. אם הזמן באתר משנה לך, מדוד scroll depth או time on page ספציפיים, לא ממוצע גלובלי.
Page Views. אם אתה מודד הצלחה לפי מספר עמודים שנצפו, אתה תחפש איך להגדיל את המספר — ותפתה ליצור פוסטים גרועים, להוסיף פגינציה לא נחוצה (״לחץ הבא לעמוד 2 מתוך 8״), או להציג אינסוף popups. כל הדברים האלה יקלקלו את האתר. תמדוד ביקור איכותי — מבקר שעשה משהו אחר מלראות עמוד.
Conversion Events — אלה כן חשובים. אירוע המרה זו פעולה ספציפית באתר שיש לה ערך עסקי: הוגש טופס יצירת קשר, נלחץ כפתור WhatsApp, נצפה סרטון הדגמה, נרשם משתמש חדש. GA4 קורא לזה Key Events מ-2026. PostHog קורא לזה Custom Events. Plausible קורא לזה Goal Conversions. עיקרון אחד: תגדיר 3-5 אירועי המרה, לא 50. אם הכל ״המרה״, שום דבר לא המרה.
Source / Medium. המקור שממנו הגיעו המבקרים — חיפוש אורגני, מודעות, רשתות חברתיות, הקלדה ישירה. זאת המטריקה שאומרת לך איפה לשים את המאמץ הבא. אם 80% מההמרות שלך באות מ-Google אורגני ו-15% מ-Instagram, השקעה בלינקדאין היא בזבוז.
המפה — ארבעת הכלים
יש מאות כלי אנליטיקס. בפועל, לעסק ישראלי קטן עד בינוני ב-2026 רלוונטיים ארבעה:
| כלי | סוג | מחיר התחלתי | פרטיות | למי זה |
|---|---|---|---|---|
| Google Analytics 4 | אנליטיקס מסורתי | חינם | בעייתי (US-hosted, GDPR-fragile) | מי שצריך אינטגרציה עם Google Ads |
| Plausible | Privacy-first lightweight | 9$/חודש מ-10K pageviews | מצוין (EU-only, cookieless) | אתרי תדמית, בלוגים, עסקים קטנים |
| PostHog | Product analytics מלא | חינם עד 1M events | טוב (גם self-host) | SaaS, מוצרים עם user flows |
| Vercel Web Analytics | Built-in לאתרי Vercel | חינם ב-Hobby, 10$ ב-Pro | מצוין (cookieless) | מי שכבר ב-Vercel |
הטעות הקלאסית: להתקין את כולם ״ליתר ביטחון״. אל תעשה את זה. כל סקריפט נוסף = ביצועים נופלים + סיכון פרטיות + רעש בדשבורד. תבחר אחד או שניים, ותגדיר אותם נכון. אם אתה מתלבט איפה לארח את האתר עצמו לפני שאתה בכלל מגיע לאנליטיקס, יש לנו השוואה נפרדת ב-Vercel מול Firebase Hosting.
GA4 — חינם, חזק, מורכב, ובעייתי בפרטיות
Google Analytics 4 הוא ברירת המחדל של רוב העולם. UA (Universal Analytics) הישן כובה סופית ביולי 2024, ו-GA4 הוא היורש היחיד. ב-2026 הוא הבשיל למשהו שעובד, אבל לא בלי כאב.
למה כל אחד לוקח אותו: כי הוא חינם, כי הוא של גוגל, כי הוא משתלב עם Google Ads ועם Search Console, וכי כל סוכנות שיווק יודעת לקרוא אותו. אם אתה מריץ קמפיינים בגוגל, אתה כמעט חייב.
מה השתנה ב-2026:
- AI Assistant channel חדש (מאי 2026): מ-13 במאי 2026 GA4 מודד אוטומטית, בלי שום הגדרה, תנועה שמגיעה דרך עוזרי AI תחת ערוץ ייעודי בשם ״AI Assistant״ (medium=
ai-assistant). רשימת המקורות המזוהים התרחבה מאז ההשקה, ונכון ליוני 2026 ה-Default Channel Group מזהה את ChatGPT, Gemini, Deepseek, Copilot ו-Grok. זה רלוונטי במיוחד אם אתה מתחיל לעבוד על GEO — אופטימיזציה למנועי תשובות, כי הערוץ הזה הוא המקום הכי נוח לראות אם מנועי התשובות באמת שולחים לך מבקרים. מלכוד אחד שכדאי להכיר: GA4 מסווג תנועת AI רק אם העוזר מעביר referrer. בדפדפן דסקטופ ה-referrer בדרך כלל שלם, אבל כשמשתמש לוחץ על לינק מתוך אפליקציית ChatGPT/Gemini במובייל, מערכת ההפעלה לרוב מוחקת את ה-referrer והסשן נוחת אצלך כ-Direct. כלומר המספר בערוץ הזה הוא רצפה, לא תקרה. - Cross-channel budgeting (בטא) — תכנון תקציב בין ערוצים עם פרויקציה לתוצאות.
- שינוי במודל ה-attribution — אפריל 2026 הביא שינוי מהותי באיך GA4 משייך המרות לערוצים. אם אתה משווה דוחות בין 2025 ל-2026, תזכור את זה לפני שתסיק מסקנות.
- Auto Key Events — GA4 מנסה לזהות אירועי המרה אוטומטית. זה נחמד אבל לא חוכמה — תגדיר את אירועי ההמרה שלך ידנית.
החיסרון הגדול — פרטיות. GA4 מעלה נתונים לשרתים בארה״ב, משתמש ב-cookies שאינם חיוניים, ואוסף נתונים שנחשבים מידע אישי תחת GDPR וגם תחת תיקון 13 לחוק הגנת הפרטיות הישראלי. באירופה אסור להפעיל GA4 בלי consent banner מפורש, ובחלק מהמדינות (אוסטריה, צרפת, איטליה) הייתה תקופה ש-GA4 הוכרז כלא חוקי בכלל. גוגל פתרו את זה חלקית עם Google Consent Mode v2, אבל ההשלכה היא שאם המבקר לוחץ ״דחה הכל״ — אתה רואה דמויות מקורבות (modelled data), לא נתונים אמיתיים.
חיסרון נוסף — Sampling. ב-Free GA4, ברגע שאתה מריץ דוח מותאם אישית על תקופה ארוכה או עם פילטרים מרובים, גוגל מתחיל לדגום (לוקח רק חלק מהנתונים ומגדיל אותם). למי שיש פחות מ-500K events בחודש זה לא משנה. למי שיש יותר — Sampling הוא הסיבה שדוחות סותרים אחד את השני.
מתי כן GA4:
- אתה מריץ Google Ads ורוצה optimization של קמפיינים
- אתה צריך integration עם Search Console
- יש לך סוכנות שיווק שיודעת לעבוד עם GA4
- האתר שלך לא מקבל תנועה מאירופה (נדיר)
Plausible — נקי, פרטיות-first, EU
Plausible הוא הכלי שבחרת אם המילים ״פרטיות״ ו״פשטות״ שוות לך משהו. הוא קוד פתוח, מתארח באירופה, לא משתמש ב-cookies, לא אוסף מידע אישי, ומציג דשבורד אחד נקי שגם הסבתא שלך תבין.
Pricing 2026: מ-9$/חודש עבור 10,000 pageviews. תוכנית Growth ב-14$ — 3 אתרים + צוות. מי שמשלם שנתי מקבל 2 חודשים חינם. אין overage fees — אם חרגת חודש בודד לא קורה כלום; חריגה רצופה של חודשיים נועלת זמנית את הדשבורד עד שתשדרג. חינם זה לא, אבל זול וצפוי.
מה אתה מקבל:
- דשבורד אחד, אינטואיטיבי, נטען ב-< 1 שנייה
- סקריפט במשקל < 1KB (לעומת ~45KB של GA4)
- מעקב scroll depth אוטומטי
- Goals & conversions בלי קוד נוסף
- מעקב revenue ל-ecommerce
- אינטגרציה עם Search Console (queries אורגניות)
- מעקב UTM אוטומטי
- מעקב AI traffic (ChatGPT, Perplexity)
- ייצוא נתונים אמיתי (CSV, API)
מה אתה מוותר עליו לעומת GA4:
- אין user journeys מעמיקים (אין path analysis)
- אין segments מתקדמים
- אין integration ישיר עם Google Ads (אפשר עם UTM, פחות חלק)
- אין מעקב cross-device (חוסר ב-user ID)
- אין dashboards מותאמים אישית
ההפתעה הנעימה — אין צורך ב-consent banner. רשויות הפרטיות בגרמניה ובצרפת הצהירו במפורש ש-cookieless analytics כמו Plausible לא דורש הסכמה. זה אומר: התקנת סקריפט, מודד, סיימת. אין באנר מעיק, אין הפסד 30% מהנתונים, אין דרישות תיעוד GDPR.
מתי כן Plausible:
- אתר תדמיתי / בלוג / פורטפוליו
- עסק שיווק B2B שרוצה לדעת מאיפה הלידים
- כל מי שלא רוצה consent banner
- מי שמעדיף מספרים נכונים מ-90% מהמבקרים, ולא 60% נכונים + 40% modelled
PostHog — product analytics, לא רק עמודים
PostHog הוא חיה אחרת. הוא לא נועד למדוד ״כמה ביקרו בעמוד״ — הוא נועד למדוד איך משתמשים משתמשים במוצר שלך. זאת הקטגוריה שנקראת Product Analytics, וההצדקה היחידה שלה היא שיש לך מוצר עם משתמשים שעושים דברים. אתר תדמית? PostHog מוגזם. SaaS עם dashboards, flows, פיצ׳רים? PostHog רלוונטי מאוד. אם אתה בונה את ה-SaaS הזה עכשיו, כדאי לקרוא במקביל את בניית SaaS MVP ב-2026 — שם נכנסים לאיזה אירועים בכלל שווה למדוד בשלב מוקדם.
Pricing 2026: Free tier נדיב במיוחד — 1 מיליון events בחודש, 5,000 session recordings, 1 מיליון feature flag requests, 100,000 שגיאות ב-error tracking, ו-1,500 survey responses. רוב החברות הקטנות נשארות בתוך ה-free tier חודשים ארוכים. מעבר לזה התמחור הוא usage-based: כ-0.00005$ לאירוע analytics (בערך 50$ למיליון אירועים נוספים), כ-0.005$ ל-session recording, וכ-0.0001$ ל-feature flag request. בניגוד ל-Mixpanel שצמצם את ה-free tier שלו מ-20M ל-1M events בסוף 2025, PostHog שמר על המכסות האלה יציבות.
מה PostHog נותן שאחרים לא:
- Session Recordings — סרטון של מה משתמש אמיתי עשה באתר. הכי טוב לפיתרון בעיות UX. (יש גם ב-Hotjar / FullStory, אבל כלולים כאן.)
- Funnels — צופים בשלבי ה-conversion ורואים בדיוק איפה משתמשים נופלים. ״מי נרשם → אישר אימייל → השלים onboarding → הגיע ל-AHA moment״.
- Feature Flags — הצגת פיצ׳ר חדש לקבוצה קטנה לפני שאתה משחרר לכולם. A/B testing פנימי.
- Heatmaps — איפה אנשים לוחצים, גוללים.
- Surveys — סקרים בתוך האפליקציה.
- AI insights — שאלות בעברית/אנגלית על הנתונים שלך, תשובות אוטומטיות.
החיסרון: PostHog הוא כלי כבד. הסקריפט הוא ~80KB. הדשבורד מורכב יותר. צריך זמן ללמוד לקרוא funnels ולא לטעות. אם אתה מנהל שיווק שמסתכל פעם בשבוע — PostHog overkill. אם אתה PM/Founder שמסתכל יום יום — PostHog זהב.
טיפ data-residency: PostHog מציעים בחירת אזור בהרשמה (US Cloud או EU Cloud). אם אכפת לך מ-GDPR ומתיקון 13, בחר ב-EU Cloud ונקודת ה-ingestion שלך תהיה בפרנקפורט — נתוני המבקרים לא עוזבים את האיחוד האירופי. למי שצריך שליטה מלאה יש גם גרסת self-host קוד-פתוח שרצה אצלך על Docker, אבל זאת התחייבות תחזוקה אמיתית; לרוב העסקים EU Cloud הוא האיזון הנכון בין פרטיות לבין כאב ראש תפעולי.
מתי כן PostHog:
- SaaS עם משתמשים שעושים דברים (לא רק קוראים תוכן)
- מוצר ב-MVP/early stage שצריך feature flags
- צריך session recordings לתיקון UX
- צריך funnel analysis אמיתי
Vercel Web Analytics + Speed Insights — קל ומיידי
אם הסטאק שלך כבר על Vercel (כמו רוב המדריכים האחרים שלנו ב-nisai), יש לך מתנה שאתה כנראה לא משתמש בה. Vercel נותנים אנליטיקס בנויה לתוך הפלטפורמה, חינם ב-Hobby בכפוף למגבלות, ו-10$/חודש ב-Pro לאחר 25,000 events.
מה אתה מקבל ב-Web Analytics:
- pageviews, visitors, top pages, referrers
- מיקום גיאוגרפי, OS, browser
- Custom events עם API פשוט
- Feature flag tracking
- בלי cookies, בלי מידע אישי — תואם GDPR בלי באנר
Speed Insights זה כלי נפרד: Real User Metrics על Core Web Vitals (LCP, CLS, INP). שים לב ש-FID (First Input Delay) הוצא משימוש רשמית ב-2024 והוחלף ב-INP — אם אתה עדיין רואה אזכורים של FID במדריכים ישנים, הם מיושנים. Speed Insights מודד את החוויה האמיתית של המשתמשים שלך, לא רק score של Lighthouse בלאב. למי שרוצה להבין מה כל מטריקה כזו אומרת ואיך לשפר אותה, יש לנו מדריך נפרד ל-Core Web Vitals ב-2026. עולה ~3$ לפרויקט אם אתה מפעיל באמצע billing cycle, 10$ לחודש בהמשך.
איך זה משתלב:
- Web Analytics טוב לעסק קטן שרוצה מספרים בסיסיים בלי שום עבודה
- לא מחליף Plausible אם אתה רוצה Goals & Funnels
- מצוין כשכבה משלימה — אתה רואה performance אמיתי ליד נתוני visitors
מתי כן Vercel Analytics:
- האתר שלך כבר על Vercel
- אתה רוצה זירו עבודה — שני שורות קוד וסיימת
- אתה רוצה performance + analytics באותו מקום
GDPR + חוק הגנת הפרטיות הישראלי — מה החובות שלך
זה החלק שאף אחד לא רוצה לקרוא, ואז משלם 30K שקל קנס. נשתדל להיות קצרים וברורים.
תיקון 13 לחוק הגנת הפרטיות (ישראל)
תיקון 13 נכנס לתוקף ב-14 באוגוסט 2025. הוא מחיל על אתרים ישראליים שאוספים מידע (cookies, טפסים, אנליטיקס) דרישות חדשות:
- חובת יידוע — להציג למבקר במפורש שאוספים נתונים, איזה, ולאיזה צורך.
- חובת הסכמה — לא די בהודעה גנרית; צריך פאנל ניהול שמאפשר למבקר לבחור אם להסכים לאיסוף, ולאיזה סוג.
- מדיניות פרטיות בעברית — חייבת לכלול: סוגי הנתונים שנאספים, מטרת האיסוף, מי אחראי, עם מי משתפים, זכויות המבקר, ואמצעי אבטחה.
- זכות עיון ותיקון — מבקר צריך להיות מסוגל לבקש לראות מה אוסף עליו ולמחוק אותו.
נקודה שחשוב לדייק בה: תיקון 13 עצמו לא כותב במפורש את המילה ״cookies״ ולא מחייב חד-משמעית באנר בנוסח האירופי. מה שכן קרה — הרשות להגנת הפרטיות, כבר ב-2020 וביתר שאת אחרי שתיקון 13 נכנס לתוקף, דוחפת לסטנדרט הסכמה ברמת GDPR ל-cookies שאינם חיוניים, וההמלצה היא מודל opt-in (הסכמה מראש), לא הסכמה משתמעת (״המשך גלישה = הסכמה״). בפועל, מכיוון שאיסוף נתוני אנליטיקס עם זיהוי הוא איסוף ״מידע״ במובן החוק, מי שמשתמש בכלי שמבוסס cookies צריך לבקש הסכמה, ומי שאוסף מידע אישי דרך טופס חייב יידוע ומדיניות פרטיות בעברית. אם הטופס שלך הוא בעצמו נקודת איסוף מידע (ורוב הטפסים הם), כדאי לוודא שהוא בנוי נכון מההתחלה. ראה טפסי יצירת קשר עם EmailJS ו-Resend לפרטים על אחסון מאובטח ושליחה דרך השרת. אם האתר שלך גם צריך לעמוד בתקן הנגישות הישראלי, יש לנו מדריך נפרד על חוק הנגישות לאתרים בישראל שמשלים את התמונה המשפטית.
GDPR — אם יש לך מבקרים מאירופה
אם האתר שלך נגיש מאירופה (וברירת המחדל זה כן — אלא אם חסמת ב-Cloudflare), אתה תחת GDPR בכל הקשור למבקרים אירופאים. הדרישות העיקריות לבאנר:
- 4 כפתורים שווי-משקל: Accept All / Reject All / Customize / X
- Reject All חייב להיות נגיש כמו Accept All — לא להחביא אותו
- חסימה בפועל של scripts לפני הסכמה — לא להעמיס את GA4 לפני שהמבקר הסכים
- Granular consent — אנליטיקס, שיווק, פונקציונליות הם 3 בקשות נפרדות, לא אחת
- Google Consent Mode v2 — חובה אם משתמשים ב-GA4 או ב-Google Ads ב-2026
השלכה פרקטית — איך נמנעים מבאנר
אם אתה משתמש רק ב-Plausible או רק ב-Vercel Web Analytics — אתה לא צריך באנר. אין cookies, אין מידע אישי, רשויות הפרטיות אישרו את זה.
אם אתה משתמש ב-GA4 או PostHog (עם cookies/PII) — אתה צריך באנר. תשתמש בכלי כמו Cookiebot, OneTrust, או פתרון open-source כמו Klaro. תקפיד שכפתור Reject All זמין מיידית.
קוד התקנה — שלושת הכלים העיקריים
GA4 בתוך Next.js 16
// app/layout.tsx
import { GoogleAnalytics } from "@next/third-parties/google";
export default function RootLayout({ children }) {
return (
<html lang="he" dir="rtl">
<body>{children}</body>
<GoogleAnalytics gaId="G-XXXXXXXXXX" />
</html>
);
}
שליחת אירוע custom:
"use client";
import { sendGAEvent } from "@next/third-parties/google";
export function WhatsAppButton() {
return (
<button
onClick={() =>
sendGAEvent("event", "whatsapp_click", {
location: "header",
})
}
>
שלח הודעה
</button>
);
}
ב-GA4 dashboard → Admin → Events → סמן את האירוע כ-Key Event.
Plausible בתוך Next.js
התקנה:
npm i next-plausible
// app/layout.tsx
import PlausibleProvider from "next-plausible";
export default function RootLayout({ children }) {
return (
<html lang="he" dir="rtl">
<head>
<PlausibleProvider domain="yoursite.co.il" />
</head>
<body>{children}</body>
</html>
);
}
שליחת אירוע:
"use client";
import { usePlausible } from "next-plausible";
export function ContactButton() {
const plausible = usePlausible();
return (
<button onClick={() => plausible("contact_form_submitted")}>
שלח טופס
</button>
);
}
ב-Plausible dashboard → Goals → Add Goal → custom event → contact_form_submitted. זה הכל.
PostHog בתוך Next.js
התקנה (הדרך הרשמית ב-2026 — posthog-js, לא wrapper נפרד):
npm i posthog-js
מ-Next.js 15.3 ואילך מאתחלים בקובץ instrumentation-client.ts בשורש הפרויקט (עובד גם ל-App Router וגם ל-Pages Router):
// instrumentation-client.ts
import posthog from "posthog-js";
posthog.init(process.env.NEXT_PUBLIC_POSTHOG_KEY!, {
api_host: "/ingest", // proxy דרך next.config כדי לעקוף ad blockers
ui_host: "https://eu.posthog.com", // EU Cloud — data residency
defaults: "2026-01-30", // ברירות מחדל עדכניות (כולל pageview אוטומטי ל-SPA)
capture_pageleave: true,
});
עוטפים את האפליקציה ב-Provider כדי שה-hooks של React יעבדו:
// app/providers.tsx
"use client";
import { PostHogProvider } from "posthog-js/react";
import posthog from "posthog-js";
export function Providers({ children }: { children: React.ReactNode }) {
return <PostHogProvider client={posthog}>{children}</PostHogProvider>;
}
שליחת אירוע:
"use client";
import { usePostHog } from "posthog-js/react";
export function PricingCTA() {
const posthog = usePostHog();
return (
<button
onClick={() =>
posthog?.capture("pricing_cta_clicked", {
plan: "pro",
source: "pricing_page",
})
}
>
נסה Pro
</button>
);
}
לזיהוי משתמש מחובר:
posthog?.identify(user.id, {
email: user.email,
plan: user.plan,
});
Vercel Web Analytics בתוך Next.js
npm i @vercel/analytics @vercel/speed-insights
// app/layout.tsx
import { Analytics } from "@vercel/analytics/next";
import { SpeedInsights } from "@vercel/speed-insights/next";
export default function RootLayout({ children }) {
return (
<html lang="he" dir="rtl">
<body>
{children}
<Analytics />
<SpeedInsights />
</body>
</html>
);
}
שליחת custom event:
"use client";
import { track } from "@vercel/analytics";
export function NewsletterForm() {
return (
<button onClick={() => track("newsletter_signup", { source: "footer" })}>
הצטרף
</button>
);
}
זהו. אחרי deploy ב-Vercel, ה-Web Analytics tab בדשבורד הפרויקט מתחיל להציג מספרים תוך דקות.
אירועי המרה — איך מגדירים נכון בעברית
הטעות שאני רואה הכי הרבה: שמות אירועים פנטסטיים בעברית בדשבורד, אבל הקוד מלא ב-event_1, event_2, click_thing. ואז שלושה חודשים אחר כך אף אחד לא זוכר מה זה event_1.
העיקרון: שמות באנגלית, תיאורים בעברית
כללי שמות לאירועים (תואם GA4 + PostHog + Plausible):
- snake_case באנגלית
- פעולה ברורה:
contact_form_submitted,whatsapp_clicked,pricing_viewed - לא
button_click— שום דבר לא ניתן ללמוד מזה - לא
click_5— אתה לא תזכור מה זה
דוגמאות לאתר עסקי טיפוסי
| אירוע (קוד) | תיאור עסקי | מטרה |
|---|---|---|
contact_form_submitted | הוגש טופס יצירת קשר | המרה ראשית |
whatsapp_clicked | נלחץ כפתור WhatsApp | המרה ראשית |
phone_clicked | נלחץ מספר טלפון | המרה ראשית |
pricing_viewed | נצפה דף תמחור | המרה משנית |
case_study_opened | נפתח case study | engagement |
video_watched_50pct | נצפה 50% מסרטון הסבר | engagement |
newsletter_signup | נרשם לניוזלטר | המרה משנית |
3-5 אירועי המרה ראשיים. לא יותר. אם הכל ״המרה״, כלום לא ״המרה״.
דוגמת קוד מלאה (לטופס יצירת קשר)
"use client";
import { useState } from "react";
import { track } from "@vercel/analytics";
import { sendGAEvent } from "@next/third-parties/google";
export function ContactForm() {
const [status, setStatus] = useState<"idle" | "sending" | "done" | "error">(
"idle",
);
async function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
e.preventDefault();
setStatus("sending");
const formData = new FormData(e.currentTarget);
const data = Object.fromEntries(formData);
try {
const res = await fetch("/api/contact", {
method: "POST",
body: JSON.stringify(data),
});
if (!res.ok) throw new Error("Server error");
// נשלח אירוע לכל הכלים הפעילים
track("contact_form_submitted", { source: "homepage" });
sendGAEvent("event", "contact_form_submitted", { source: "homepage" });
setStatus("done");
} catch (err) {
setStatus("error");
}
}
return <form onSubmit={handleSubmit}>{/* ...שדות... */}</form>;
}
שים לב: השליחה היא אחרי שהבקשה הצליחה. לא לפני. אם הטופס נכשל, אתה לא רוצה לראות ״המרה״ בדשבורד.
Server-Side Tracking — למה לא רק client
כל הקוד שראינו עד עכשיו רץ ב-browser. הוא נהדר ל-95% מהמקרים, אבל יש לו שתי בעיות מובנות:
- Ad blockers — בערך 30% מהמבקרים שלך משתמשים ב-uBlock, AdBlock, Brave Shields. הם יחסמו GA4, PostHog, Plausible לפעמים. אתה מאבד נתונים.
- חוסר שליטה — הקוד רץ אצל המבקר. אתה לא יכול לחתוך PII לפני שליחה, אתה לא יכול לעשות validation, אתה תלוי בכך ש-vendor יכבד consent.
הפיתרון: Server-Side Tracking. במקום ש-browser ישלח אירוע ישירות ל-GA4, ה-browser שולח את האירוע ל-server שלך, וה-server שולח הלאה. יתרונות:
- עוקפים ad blockers (זה הסקריפט שלך, לא של גוגל)
- שולטים על הנתונים — מוחקים PII, מוסיפים context
- עקביות — כל הנתונים עוברים דרך מקום אחד
- ביצועים — פחות scripts בדף
ב-2026 רוב הסטאקים הרציניים משתמשים ב-hybrid approach: client tracking לדברים שרק browser יודע (scroll, mouse position), server tracking לאירועי המרה ולכל מה שמגיע מ-backend (signup, payment, subscription_changed).
דוגמה: Vercel Function שמשדרת ל-GA4
// app/api/track/route.ts
import { NextRequest, NextResponse } from "next/server";
const GA_MEASUREMENT_ID = process.env.GA_MEASUREMENT_ID!;
const GA_API_SECRET = process.env.GA_API_SECRET!;
export async function POST(req: NextRequest) {
const { event, params, clientId } = await req.json();
// server-side validation וניקוי
if (!event || !clientId) {
return NextResponse.json({ error: "Invalid" }, { status: 400 });
}
await fetch(
`https://www.google-analytics.com/mp/collect?measurement_id=${GA_MEASUREMENT_ID}&api_secret=${GA_API_SECRET}`,
{
method: "POST",
body: JSON.stringify({
client_id: clientId,
events: [{ name: event, params }],
}),
},
);
return NextResponse.json({ ok: true });
}
עכשיו ה-client קורא ל-/api/track במקום ל-GA4 ישירות. ad-blockers לא חוסמים את הדומיין שלך, גוגל מקבל את הנתונים, ואתה מבעלי הדבר.
אתר React/SPA — הבעיה הסמויה במדידת pageviews
יש מלכוד שתופס הרבה בעלי אתרים שבנו ב-React, Vue או כל SPA אחר: pageviews לא נספרים נכון. ב-SPA, מעבר בין דפים לא טוען עמוד חדש מהשרת — ה-router משנה רק את ה-URL בצד הלקוח. רוב סקריפטי האנליטיקס מודדים pageview רק בטעינה הראשונה, ולכן כל הניווט הפנימי פשוט נעלם מהדשבורד.
הפיתרון תלוי בכלי:
- GA4 — דרך
@next/third-parties/googleב-Next.js זה מטופל אוטומטית. ב-React רגיל צריך לקרוא ידנית ל-gtag('event', 'page_view')בכל שינוי route. - Plausible — מוסיפים את הסקריפט
script.hash.jsאו מפעיליםpageviewProps/hashbasedroutingכדי שיתפוס שינויי history. - PostHog — מגדירים
capture_pageview: "history_change"(כמו בקוד למעלה) וזה תופס מעברי SPA לבד. - Vercel — ה-
<Analytics />של Vercel תופס שינויי route ב-Next.js אוטומטית.
זאת אותה משפחת בעיות שגורמת לאתרי SPA להיכשל גם ב-SEO. אם האתר שלך הוא SPA טהור, שווה לקרוא את SEO לאתרי React/SPA — שם מסבירים למה גוגל ומדידת pageviews נופלים מאותה סיבה (היעדר HTML מוגש מהשרת), ומה לעשות.
מתי לעבור משלב לשלב
Bootstrap (0–100 משתמשים בחודש): אל תתקין כלום. תתמקד במוצר. אם חייבים — Vercel Web Analytics, 2 שורות קוד, ניגמר עניין.
Early Growth (100–1,000 משתמשים בחודש): Plausible (9$/חודש) או PostHog free tier. תגדיר 3 אירועי המרה. תסתכל פעם בשבוע.
Growth (1K–10K משתמשים בחודש): כאן זה משנה. אם אתה SaaS — PostHog (עדיין יכול להיות free). אם אתה אתר תוכן/תדמית — Plausible Growth (14$/חודש). מתחילים לבנות funnels.
Scale (10K+ משתמשים בחודש): GA4 + PostHog. GA4 ל-marketing & SEO insights, PostHog לכל מה שקשור לתוך המוצר. Server-side tracking הכרחי. כנראה מתחיל להיות גם נסיון לשלב CRM (HubSpot, Pipedrive) — כי הערך האמיתי לא בקליק, אלא בעסקה שנסגרת חודש אחר כך.
ההמלצה האישית של nisai
לעסק קטן עד בינוני בישראל, ב-2026:
- אתר תדמית / בלוג / portfolio: Plausible + Vercel Web Analytics. 9$ + חינם. בלי באנר. סיימת.
- SaaS / מוצר עם משתמשים: PostHog (free tier) + Vercel Speed Insights. תוסיף GA4 אם וכאשר אתה משלם על Google Ads.
- חנות e-commerce: GA4 (חובה לרימרקטינג ולאופטימיזציית קמפיינים) + Plausible לקריאה יומיומית נקייה. שני dashboards, כל אחד לקהל אחר.
- עסק שיווק B2B: Plausible + HubSpot CRM. ההמרה האמיתית קורית ב-CRM אחרי 3 שבועות, לא בקליק.
אל תתקין את כולם. כל סקריפט נוסף = 100ms בעמוד = 7% נטישה. תבחר אחד עיקרי, אחד משלים, וזהו.
שאלות נפוצות
איזה אנליטיקס לאתר עסקי הכי טוב ב-2026?
אין תשובה אחת — זה תלוי במה שאתה מודד. לאתר תדמית או בלוג: Plausible (פרטי, קליל, בלי באנר). ל-SaaS עם משתמשים: PostHog (funnels, session recordings). לחנות שמריצה Google Ads: GA4 חובה. הכלל הוא לבחור כלי עיקרי אחד שמתאים לסוג העסק, ולכל היותר כלי משלים אחד — לא להתקין את כולם.
האם GA4 חוקי בישראל אחרי תיקון 13?
כן, GA4 חוקי לשימוש בישראל, אבל הוא דורש מנגנון הסכמה (consent banner) כי הוא משתמש ב-cookies ומעלה מידע אישי לשרתים בארה״ב. תיקון 13 דורש הסכמה מפורשת לאיסוף — הסכמה משתמעת לא מספיקה. אם אתה לא רוצה להתעסק עם באנר, Plausible או Vercel Web Analytics הם cookieless ולא דורשים הסכמה.
האם אני חייב באנר cookies לאתר ישראלי?
לא תמיד. אם אתה משתמש רק בכלי אנליטיקס cookieless כמו Plausible או Vercel Web Analytics — אינך צריך באנר, כי אין איסוף מידע אישי. אם אתה משתמש ב-GA4, PostHog עם זיהוי משתמשים, או כל כלי שמשתמש ב-cookies מעקב — אתה כן צריך באנר עם כפתור ״דחה הכל״ נגיש באותה מידה כמו ״אשר הכל״.
כמה עולה Plausible לעומת PostHog?
Plausible מתחיל ב-9$ לחודש עבור 10,000 pageviews, בלי שכבת חינם. PostHog נותן שכבת חינם נדיבה — מיליון events, 5,000 session recordings ועוד — בחינם בכל חודש, ורק מעבר לזה משלמים לפי שימוש (כ-50$ למיליון אירועים נוספים). לרוב העסקים הקטנים PostHog יוצא חינם בפועל, בעוד Plausible הוא הוצאה קבועה אבל צפויה וזולה.
למה GA4 מראה לי פחות מבקרים מ-Plausible באותו אתר?
זה תופעה מוכרת. GA4 מאבד נתונים בגלל שלושה גורמים: מבקרים שלוחצים ״דחה״ בבאנר ההסכמה (אז הנתונים שלהם מודלים, לא אמיתיים), ad blockers שחוסמים את הסקריפט של גוגל, ו-sampling בדוחות גדולים. Plausible הוא cookieless וקל יותר לחסימה פחות, ולכן בדרך כלל מציג מספרים גבוהים יותר וקרובים יותר למציאות.
מה ההבדל בין pageview ל-conversion event?
Pageview הוא פשוט צפייה בעמוד — מטריקה גסה שלא אומרת אם קרה משהו בעל ערך. Conversion event (אירוע המרה) הוא פעולה ספציפית עם משמעות עסקית: שליחת טופס, לחיצה על WhatsApp, רישום לטריאל. הכלל הזהב — תגדיר 3-5 אירועי המרה ראשיים בלבד, כי אם הכל ״המרה״, שום דבר לא באמת המרה.
צריך server-side tracking לאתר קטן?
לרוב לא. ל-95% מהאתרים הקטנים, client-side tracking מספיק לחלוטין. server-side tracking נכנס לתמונה כשאתה מאבד יותר מדי נתונים ל-ad blockers, כשאתה צריך לחתוך מידע אישי לפני שליחה, או כשאתה מודד אירועים שקורים ב-backend (תשלום, חידוש מנוי). זה שלב Scale, לא שלב התחלה.
לסיכום
הבחירה של אנליטיקס לאתר עסקי ב-2026 היא לא ״איזה הכי חזק״ אלא ״איזה מתאים לשלב ולסוג העסק שלי״. אתר תדמית או בלוג? Plausible לבד, אולי עם Vercel Web Analytics לצדו — קל, פרטי, בלי באנר. SaaS עם משתמשים שעושים דברים? PostHog על ה-free tier הנדיב שלו. חנות או מי שמריץ Google Ads? GA4 הוא כמעט חובה, אבל שווה לצרף לו כלי cookieless נקי לקריאה יומיומית.
שלושת הדברים שצריך לזכור: אל תתקין את כולם (כל סקריפט עולה בביצועים ובפרטיות), תגדיר 3-5 אירועי המרה ולא חמישים, ואם אתה אוסף מידע אישי — תכבד את תיקון 13 ו-GDPR עם באנר תקין. תתחיל פשוט, תוסיף עומק רק כשהמספרים שלך מצדיקים את זה.
CTA
בונה אתר חדש? ואתה לא בטוח איזה אנליטיקס מתאים לך, איך להתקין נכון בלי לפגוע בביצועים, ואיך לעמוד בתיקון 13 בלי לקנות פלאגין יקר — דבר איתי ב-WhatsApp. נסדר setup נקי, 30 דקות שיחה חינם.
מקורות
- Plausible Analytics — דוקומנטציה רשמית
- Plausible pricing and subscription plans
- Plausible Next.js integration
- PostHog Pricing 2026
- PostHog Next.js docs
- Vercel Web Analytics — Limits & Pricing
- Vercel Speed Insights
- Next.js Google Analytics
- GA4 Events Reference
- GA4 2026 Roadmap (ALM Corp)
- GA4 Measurement Protocol
- תיקון 13 לחוק הגנת הפרטיות — מדריך מלא
- הרשות להגנת הפרטיות — הסכמה ל-cookies
- Israel Privacy Protection Law — Cookie Script
- GDPR Cookie Banner 2026 Requirements
- Google Consent Mode v2
- Server-Side Tracking — Usercentrics guide
- Conversion Tracking Best Practices 2026 (Cometly)