POAS: איך מודדים מדיה לפי רווח ולא לפי הכנסה
השדה שאתם ממלאים כבר שנים מקבל את המספר הלא נכון
אלגוריתם הבידינג של גוגל ושל מטא לא יודע מה הרווח שלכם. הוא יודע מספר אחד: הערך שהטמעתם בפיקסל או שלחתם בשרת. ברוב חנויות המסחר בישראל המספר הזה הוא סכום העסקה, לעיתים כולל מע"מ. כל מה שקורה אחרי זה, עלות הסחורה, עמלת הסליקה, האריזה, ההחזרה שחוזרת שבועיים אחר כך, לא מגיע לאלגוריתם בכלל.
התוצאה צפויה. מערכת שמייעלת למחזור תמצא את המוצרים שמייצרים הכי הרבה מחזור לשקל מדיה, ואלה כמעט תמיד המוצרים עם המרווח הנמוך והמוצרים עם שיעור ההחזרות הגבוה. זו לא תקלה. זו בדיוק המשימה שהגדרתם.
POAS, קיצור של Profit on Ad Spend, הוא החלפת המונה: רווח תרומה חלקי הוצאת מדיה במקום הכנסה חלקי הוצאת מדיה. היישום הוא רצף של החלטות שכל אחת מהן יכולה להרוס קמפיין שעובד.
מה באמת אפשר לשלוח כערך המרה ב-2026
בגוגל אדס, השדה שמזין את הבידינג הוא ערך ההמרה של פעולת ההמרה. גוגל מתעדת שהערך יכול להיות ערך כלכלי אמיתי כמו הכנסה או ערך פרוקסי כמו ציון ליד, ודורשת שיהיו לפחות שני ערכים שונים כדי שבידינג מבוסס ערך יהיה רלוונטי. אין בתיעוד שדה נפרד לרווח. אם אתם רוצים שהאלגוריתם יראה רווח, אתם כותבים רווח בשדה שנקרא ערך .
מה שאי אפשר לעשות: אי אפשר לבקש מ-value rules לנכות עלות. כללי ערך ההמרה של גוגל תומכים בארבעה תנאים בלבד, קהל, מכשיר, מיקום גאוגרפי ומסלול נסיעה, ובשלוש פעולות. התיעוד של ה-API מגדיר במפורש: ADD חייב להיות גדול מאפס, SET חייב להיות גדול מאפס, ו-MULTIPLY מוגבל לטווח 0.5 עד 10. אין תנאי ברמת מוצר ואין אפשרות להגדיר מרווח. מי שקיווה להחיל POAS דרך כללי ערך פשוט לא יכול.
Enhanced Conversions הן לא פתרון לזה ולא נועדו להיות. הן שולחות נתוני לקוח מוצפנים כדי לשפר את דיוק ההתאמה והייחוס. הן לא משנות את הערך הכספי של ההמרה. מי שמוכר לכם אותן כשדרוג לרווחיות מוכר משהו אחר.
בצד של מטא, ה-Conversions מגדיר את value כפרמטר חובה לאירועי רכישה ולכל אירוע שמשתמש בערך לאופטימיזציה, עם קוד מטבע תקני לפי ISO 4217. באותו תיעוד קיים גם פרמטר בשם net_revenue, שמתואר כערך המרווח של אירוע ההמרה. שימו לב להבחנה: value הוא מה שמזין אופטימיזציה, net_revenue הוא שדה נוסף. לא מצאתי תיעוד ציבורי שמגדיר את net_revenue כיעד בידינג בפני עצמו.
אף אחת מהפלטפורמות לא מוכרת לכם בידינג לרווח
זו הנקודה שהשוק הכי מבלבל, ושווה לעצור עליה. גוגל כן אוספת ממכם נתוני עלות סחורה. המאפיין cost_of_goods_sold ב-Merchant Center קיים, והוא אפילו חובה לקידומים אוטומטיים. אבל התיעוד של גוגל אומר עליו דבר אחד ברור: הוא משמש לחישוב אומדן רווח גולמי, כלומר לדיווח. אין בתיעוד שום אמירה שהמאפיין הזה משפיע על דירוג מודעות או על אסטרטגיות בידינג.
אותו דבר לגבי conversions with cart data. הפיצ'ר נותן נתונים ברמת פריט, גודל סל, ערך הזמנה ממוצע ורווח גולמי כשהוא מחובר ל-COGS, וההצדקה שגוגל מנסחת לו היא שהתובנות עוזרות לקבל החלטות טובות יותר. זו הגדרה של שכבת דיווח, לא של יעד אופטימיזציה.
אצל מטא התמונה קצת יותר פתוחה. ביוני 2025 מטא הודיעה על הרחבת פרמטרי היעד למערכות האוטומטיות שלה, כולל היכולת לשתף דרך ה-Conversions API כמה רווח המפרסם מייצר ממוצרים שונים, כדי שהמערכת תוכל לייעל למכירות במרווח גבוה יותר. זו אמירה על כיוון מוצר, לא על פיצ'ר עם תיעוד ציבורי מלא וזמינות כללית. לא מצאתי דף עזרה רשמי ופתוח שמתאר יעד בידינג בשם POAS.
המסקנה המעשית: כל פתרון POAS שאתם רואים בשוק היום, בלי יוצא מן הכלל, עובד באותה שיטה. הוא מחשב רווח ומזין אותו לשדה שהאלגוריתם קורא כהכנסה. הכלים משתנים באיכות החישוב ובאמינות ההעברה, לא בעקרון.
איך מרכיבים רווח ברמת הזמנה
רווח תרומה ברמת הזמנה הוא ההכנסה נטו פחות כל העלויות שמשתנות עם ההזמנה. השאלה המעשית היא מה מהרכיבים בכלל זמין ברגע שבו הפיקסל נורה. ההפרדה הזו קובעת את כל הארכיטקטורה.
| רכיב עלות | זמין ברגע ההמרה | מה עושים איתו |
|---|---|---|
| עלות סחורה (COGS) | כן, אם היא קיימת בקטלוג | מושכים מהמוצר ומחשבים בזמן אמת |
| עמלת סליקה | ברובה כן | אחוז קבוע מסכום העסקה, לפי החוזה עם הסולק |
| משלוח | חלקית | אומדן לפי אזור ומשקל, מדויק בדיעבד |
| איסוף ואריזה | לא ישירות | עלות ממוצעת קבועה להזמנה מתוך נתוני המחסן |
| החזרות וביטולים | לא | אחוז צפוי בזמן אמת, תיקון בדיעבד |
העיקרון שעובד: כל מה שידוע נכנס למספר בזמן אמת, כל מה שלא ידוע נכנס כאומדן שמרני, וכל מה שמתברר אחר כך מתוקן דרך מנגנון תיקון רשמי. מי שמחכה לוודאות מלאה לפני שהוא שולח ערך ישלח אותו באיחור של שבועיים, ואז הוא כבר לא מזין בידינג אלא רק דיווח.
ROAS מול POAS: תרחיש מומחש
הטבלה הבאה היא דוגמה מספרית שבניתי לצורך ההמחשה בלבד. אלה לא נתוני שוק ולא ממוצעי ענף. המטרה היא להראות את נקודת ההיפוך, כלומר את המקרה שבו המוצר עם ה-ROAS הגבוה הוא המוצר שמפסיד כסף. שני המוצרים מקבלים אותה הוצאת מדיה.
| מדד | מוצר א | מוצר ב |
|---|---|---|
| הוצאת מדיה | 10,000 ₪ | 10,000 ₪ |
| הכנסה | 30,000 ₪ | 22,000 ₪ |
| ROAS | 3.0 | 2.2 |
| מרווח גולמי | 18% | 55% |
| רווח גולמי | 5,400 ₪ | 12,100 ₪ |
| עמלת סליקה (2%) | 600 ₪ | 440 ₪ |
| משלוח ואריזה | 1,200 ₪ | 750 ₪ |
| אובדן בגין החזרות | 650 ₪ | 480 ₪ |
| רווח תרומה | 2,950 ₪ | 10,430 ₪ |
| POAS | 0.30 | 1.04 |
לפי ROAS מוצר א מנצח בפער של 36 אחוז. לפי POAS מוצר א מחזיר שלושים אגורות על כל שקל מדיה, ומוצר ב הוא היחיד שעובר את נקודת האיזון. אלגוריתם שמקבל הכנסה יזיז תקציב למוצר א בעקביות, כי מנקודת המבט שלו הוא עושה בדיוק את מה שביקשתם. זו הסיבה שהמעבר הוא שינוי בהגדרת המשימה, לא אופטימיזציה נוספת מעל מה שיש.
החזרות, וחלון 54 הימים של גוגל
החזרות הן הרכיב שמפיל את רוב היישומים. הן לא ידועות ברגע ההמרה, הן לא מתפלגות אחיד בין מוצרים, והן ההבדל בין POAS מדויק ל-POAS שנשמע טוב.
לגוגל יש מנגנון רשמי לתיקון בדיעבד. conversion adjustments כוללות שני סוגים: RESTATE שמשנה את ערך ההמרה בלי לשנות את הספירה, ו-RETRACT שמסיר את ההמרה לגמרי ומאפס את ערכה. שניהם דורשים מזהה הזמנה שנשלח כבר עם ההמרה המקורית, או צמד GCLID ותאריך, כאשר גוגל ממליצה במפורש על מזהה הזמנה.
המגבלות מתועדות ושווה להכיר אותן לפני שבונים תהליך. גוגל כותבת שתיקון שמנסים להעלות בתוך יום מהקליק עלול פשוט לא להיקלט, שמומלץ להעלות תיקונים לפחות 24 שעות אחרי ההמרה המקורית, ושהחלון הכולל לתיקון הוא 54 יום. נקודה שדורשת דיוק: המספר של שבעה ימים שמסתובב בשוק בהקשר של בידינג מתועד אצל גוגל ספציפית לקמפיינים של Hotel Ads, לא כחוק כללי. אל תבנו תהליך על ההנחה שיש לכם שבעה ימים, ואל תבנו אותו על ההנחה שיש לכם 54 יום להשפיע על הבידינג. מה שמתועד הוא שהתיקון נקלט, לא באיזה עומק הוא חוזר לאלגוריתם.
בצד של מטא לא מצאתי תיעוד ציבורי רשמי למנגנון תיקון ערך בדיעבד שמקביל ל-conversion adjustments. פרמטרי ה-Original Event Data של ה-CAPI מתועדים כמנגנון למניעת כפילויות בין הפיקסל לשרת, לא ככלי לעדכון ערך של אירוע שכבר נשלח. מי שעובד מול מטא נאלץ בפועל לשקלל את ההחזרות מראש, כלומר לשלוח ערך רווח שכבר מנוכה באחוז ההחזרות הצפוי של אותה קטגוריה. זו פשרה, וצריך לקרוא לה בשמה. היא מחייבת עבודה מסודרת של מדידה בצד השרת מול מטא כדי שלפחות ההעברה עצמה תהיה אמינה.
מה קורה ללמידה של האלגוריתם
החלפת ערך ההמרה היא לא שינוי טכני שקוף. גוגל כותבת במפורש שאחרי כל שינוי ביעדי המרה או בפעולות המרה, בידינג חכם לוקח זמן ללמוד, בדרך כלל מחזור המרה אחד עד שניים, וממליצה לוודא שהתקציבים מוגדרים לסכום שבאמת מתכוונים להוציא לפני שמשנים משהו במעקב ההמרות. ב-תיעוד של Target ROAS יש הנחיה מקבילה: אחרי שינוי באופן שבו הערך מדווח, כדאי לחכות מחזור המרה אחד עד שניים לפני שמאמצים אותו.
הסיכון השני הוא נפח. Target ROAS בחיפוש ובשופינג דורש לפי התיעוד לפחות 15 המרות ב-30 הימים האחרונים ברמת מעקב ההמרות. אם אתם מפצלים את מעקב ההמרות לפעולת המרה חדשה שנושאת רווח, הפעולה החדשה מתחילה מאפס. חנות שעמדה על 25 המרות בחודש יכולה למצוא את עצמה בלי מספיק אותות לאסטרטגיה שהיא כבר מריצה. זה אותו סוג מלכודת שנוגעת גם בשינויים בהתנהגות בידינג חכם מול תקציב, ומשם היא בדרך כלל מתגלה מאוחר מדי.
הסיכון השלישי הוא הערכים עצמם. כללי ערך ההמרה של גוגל לא מאפשרים לקבוע ערך שאינו חיובי, ו-RETRACT מאפס את ההמרה ומסיר אותה מהספירה. אין ברשותכם דרך מתועדת לבטא הזמנה שהפסידה כסף כערך שלילי. הרצפה המעשית היא אפס, כלומר הזמנה מפסידה נראית לאלגוריתם כמו הזמנה חסרת ערך ולא כמו נזק. זה מגביל את עוצמת האות, וכדאי להביא את זה בחשבון לפני שמצפים שהמערכת תברח מקטגוריה מפסידה לבד.
מתי POAS לא שווה את זה
לא כל חשבון צריך את זה, ורוב החשבונות שמנסים נכשלים על אחד מארבעת המקרים הבאים.
- מודל מנוי. אין מחיר עסקה יחיד שמייצג את הערך. הרווח נפרש על פני חודשי שימוש, ושיעור הנטישה קובע אותו יותר מכל דבר אחר. כאן הדיון האמיתי הוא ערך חיים חזוי, לא POAS.
- B2B בלי מחיר עסקה. בשלב הליד אין הכנסה ואין עלות סחורה. אפשר להחזיר ערך מה-CRM בדיעבד, אבל אז אתם במדידת ייחוס, לא ב-POAS.
- מוצר יחיד או מרווח אחיד. אם כל המוצרים באותו מרווח, POAS הוא ROAS מוכפל בקבוע. הדירוג בין קמפיינים לא משתנה. הרווחתם עבודה, לא החלטות.
- נפח המרות נמוך. מתחת לסף שהתיעוד דורש לאסטרטגיית הערך שאתם מריצים, החלפת השדה תפגע בלמידה יותר ממה שהדיוק ישפר.
כלל החלטה: עברו ל-POAS רק אם מתקיימים שלושת התנאים יחד. פיזור המרווח הגולמי בין המוצרים הנמכרים ביותר הוא לפחות פי שניים בין הגבוה לנמוך, נפח ההמרות עומד בנוחות בדרישת המינימום המתועדת של אסטרטגיית הבידינג שלכם, ויש לכם מקור נתוני עלות שמתעדכן אוטומטית. חסר אחד מהשלושה, תישארו ב-ROAS ותנהלו את הרווחיות ברמת מבנה הקמפיינים ובחירת המוצרים.
קטגוריית הכלים, בלי המלצה
קיימת קטגוריית כלים שעוסקת בדיוק בזה. ProfitMetrics, Tracklution, פתרונות מבית Smarter Ecommerce, ומספר יישומים עצמאיים בצד השרת. מבחינה טכנית כולם עושים וריאציות על אותו רצף: מתחברים לפלטפורמת החנות דרך אפליקציה או API, מושכים עלות סחורה ונתוני הזמנה, מחשבים רווח תרומה ברמת ההזמנה, ומעבירים את המספר לפלטפורמות המדיה כערך המרה. חלקם מוסיפים שכבת מעקב בצד השרת משלהם כדי לשלוט באיכות ההעברה, וחלקם מטפלים גם בתיקונים בדיעבד מול גוגל.
אני לא ממליצה על ספק, ובמכוון לא מצטטת אף מספר שיפור שמופיע באתרי הספקים. אלה מספרים שיווקיים שלא עברו בדיקה חיצונית. מה שכן שווה לבדוק: האם הכלי מזין את הערך דרך מעקב בצד הלקוח או בצד השרת, האם הוא מטפל ב-conversion adjustments או רק בערך הראשוני, ומה קורה כשהחנות משנה מחירים או עלויות. מי שעדיין בונה את התשתית שמתחת, כדאי שיתחיל ממעקב בצד השרת. שכבת רווח על גבי מדידה דולפת מייצרת מספר מדויק על בסיס נתון חסר.
הזווית הישראלית
ארבעה דברים משנים את החישוב כאן. הראשון הוא מע"מ. מע"מ בישראל עומד על 18 אחוז, וגוגל מחייבת שהמחיר בפיד יכלול מע"מ במדינות שמחוץ לארצות הברית וקנדה. המשמעות היא שאם אתם שולחים את סכום העסקה כערך המרה, אתם שולחים מספר שכולל 18 אחוז שלעולם לא יהיו שלכם. ברווח תרומה מע"מ יורד ראשון. זה לבדו משנה את התמונה.
השני הוא החזרות מול החלון של גוגל. תקנות הגנת הצרכן בישראל מאפשרות ביטול עסקת מכר מרחוק תוך 14 ימים מקבלת המוצר, עם דמי ביטול מוגבלים ל-5 אחוז מערך העסקה או 100 שקל, הנמוך מביניהם. זו דווקא בשורה טובה למדידה: רוב הביטולים ייפלו בתוך חלון 54 הימים של conversion adjustments, ולכן תיקון בדיעבד בגוגל הוא ריאלי כאן לרוב המוצרים הפיזיים.
השלישי הוא סליקה. העמלה משתנה בין סולקים, בין סוגי כרטיס ובין עסקאות תשלומים, ואי אפשר להתייחס אליה כמספר אחד. קחו את האחוז מהדוח החודשי של הסולק שלכם, לא מהערכה כללית, ואם אתם מוכרים בתשלומים בדקו אם העמלה שונה.
הרביעי הוא מכירה בחו"ל ומטבע. תיעוד גוגל מדגיש שערכי המרה מדווחים תמיד במטבע החיוב של החשבון, ולכן חשוב לשייך מטבע לערך כשמדובר בעסקאות במטבעות שונים, ומטא דורשת קוד מטבע תקני לפי ISO 4217 בכל אירוע רכישה. חנות שמוכרת בשקל ובדולר ולא מטפלת בזה נכון מקבלת רווח תרומה שגוי במקורו, ואז מחליטה על תקציב לפי מספר שבור. כאן גם נכנסת שאלת התשתית: הרבה חנויות ישראליות עובדות על פלטפורמות מקומיות עם גישה מוגבלת לצד השרת, ובמקרה כזה מסלול העבודה המעשי הוא ייצוא ההזמנות לשכבת נתונים מסודרת וממנה העלאה מתוזמנת, במקום לדחוף חישוב חי דרך פלטפורמה שלא בנויה לזה.
סדר הפעולות להטמעה
הסדר כאן חשוב לא פחות מהתוכן. רוב הכישלונות שראיתי נובעים מכך שמישהו החליף את הערך ביום הראשון במקום ביום השלושים.
- בנו מקור אמת לעלויות. עלות סחורה ברמת מוצר, אחוז עמלת סליקה, עלות משלוח ממוצעת לפי אזור, עלות איסוף ואריזה להזמנה. אם זה גיליון ידני שמתעדכן פעם ברבעון, זה יישבר תוך חודשיים.
- חשבו רווח תרומה היסטורי על שישה עד שנים עשר חודשי הזמנות אחורה, לפני שאתם נוגעים בקמפיינים. אם התרגיל הזה לא מייצר פיזור מרווח משמעותי בין המוצרים, עצרו כאן. POAS לא ישנה לכם דבר.
- ודאו שמזהה הזמנה נשלח עם כל המרה בגוגל. בלעדיו אין conversion adjustments, ובלי תיקונים אין טיפול אמיתי בהחזרות.
- צרו פעולת המרה חדשה לרווח, במקביל לקיימת, והגדירו אותה כמשנית. אספו נתונים בלי שהיא משפיעה על בידינג. אל תחליפו כלום בשלב הזה.
- הריצו תקופת צל של ארבעה עד שישה שבועות. השוו יום יום את הערך שהמערכת החדשה מייצרת מול הרווח בפועל בספרים. פער עקבי בשלב הזה יהפוך להחלטות תקציב שגויות בשלב הבא.
- הפעילו את זרימת התיקונים בדיעבד להחזרות ולביטולים, בתוך החלון המתועד, עם RESTATE לשינוי ערך ו-RETRACT לביטול מלא.
- החליפו את פעולת ההמרה לראשית בקמפיין אחד בלבד, עדיף כזה עם נפח גבוה יחסית. הגדירו יעד ROAS חדש שמותאם לסקאלה החדשה של הערך, כי יעד 400 אחוז על הכנסה הוא לא אותו יעד על רווח.
- המתינו מחזור המרה אחד עד שניים לפי המלצת גוגל לפני שאתם מסיקים משהו, ורק אז הרחיבו לשאר החשבון.
מה עושים עם זה
אל תתחילו מהפלטפורמה. התחילו מטבלה. קחו את חמישים המוצרים הנמכרים ביותר בשנה האחרונה, חשבו לכל אחד רווח תרומה ממוצע להזמנה אחרי סחורה, סליקה, משלוח והחזרות, והשוו את הדירוג הזה לדירוג לפי מחזור. אם שני הדירוגים דומים, POAS לא ישנה לכם את התקציב ולא כדאי לגעת בכלום. אם הדירוגים שונים מהותית, קיבלתם את הצדקה למעבר, וגם רשימה מוכנה של המוצרים שהאלגוריתם שלכם מממן כרגע בלי סיבה.
שאלות נפוצות
האם גוגל או מטא מציעות בידינג ל-POAS?
לא כפיצ'ר מתועד וזמין. גוגל אוספת עלות סחורה ב-Merchant Center אבל מגדירה אותה כנתון לחישוב אומדן רווח גולמי, כלומר לדיווח. מטא הודיעה ביוני 2025 שאפשר לשתף נתוני רווח דרך ה-Conversions API כדי שהמערכת תייעל למכירות במרווח גבוה יותר, בלי תיעוד עזרה פומבי של יעד בידינג בשם POAS. בפועל כל פתרון קיים מזין רווח לשדה שהאלגוריתם קורא כהכנסה.
אפשר לשלוח ערך המרה שלילי על הזמנה מפסידה?
אין לכך דרך מתועדת. כללי ערך ההמרה של גוגל מחייבים ערכים חיוביים, ופעולת RETRACT מאפסת את ההמרה ומסירה אותה מהספירה. הרצפה המעשית היא אפס, כלומר הזמנה מפסידה נראית לאלגוריתם כחסרת ערך ולא כנזק.
כמה זמן אחורה אפשר לתקן ערך המרה בגוגל?
התיעוד מציין חלון של 54 יום לתיקוני המרות, ממליץ להעלות תיקון לפחות 24 שעות אחרי ההמרה המקורית, ומזהיר שתיקון בתוך יום מהקליק עלול לא להיקלט. המספר של שבעה ימים שמצוטט לעיתים בהקשר של בידינג מתועד ספציפית לקמפיינים של Hotel Ads ואינו כלל כללי.
מה קורה ל-ROAS המדווח אחרי המעבר?
הוא יירד, וזה צפוי. אם שלחתם קודם הכנסה ועכשיו אתם שולחים רווח תרומה, הערך המדווח קטן בשיעור שווה למבנה העלויות שלכם. יעדי ROAS קיימים צריכים להיות מוגדרים מחדש לסקאלה החדשה באותו יום, אחרת המערכת תקצץ תקציב מיד. שווה להסביר את זה להנהלה לפני השינוי ולא אחריו, ולתאם ציפיות מול מדידת התרומה השולית ומול הדיווח בGA4 שימשיך להראות מחזור.
5 עדכונים שחשוב לדעת + ניתוח אחד. אימייל אחד בשבוע, בלי ספאם.