פיד מוצרים ב־ChatGPT Ads: איך מעלים קטלוג בלי לפרסם מוצר שגוי

מהו קמפיין Product Feed ב־ChatGPT Ads?

קמפיין Product Feed מחבר קטלוג מוצרים ל־Ads Manager. במקום לבנות מודעה נפרדת לכל SKU, מעלים נתוני מוצר, בוחרים אילו מוצרים קבוצת מודעות יכולה להשתמש בהם, ומגדירים תבנית שממלאת את פרטי המוצר בזמן הצגת המודעה. לפי התיעוד של OpenAI, הפורמט מיועד במיוחד לקמעונאים עם קטלוג רחב או כזה שמשתנה לעיתים קרובות.

מודעת מוצר יכולה להציג פרטים כמו תמונה, כותרת, דירוג כוכבים, מחיר, מחיר מבצע ומותג. המוצרים שבפיד כשירים לשימוש במודעות בתקופת הבטא; עצם העלאתם אינה גורמת להם להופיע בשיחות אורגניות ב־ChatGPT. זו הבחנה מהותית: פיד פרסום, פיד לגילוי אורגני וחיבור checkout הם שימושים שונים עם דרישות והרשאות שונות.

נכון ל־23 בספטמבר 2026, OpenAI מתעדת העלאה ידנית של CSV או TXT, כתובת Hosted URL וחיבור SFTP. היא גם מציינת שפריטים פוקעים לאחר שבועיים, ולכן קטלוג פעיל אינו יכול להישען על העלאה חד־פעמית שנשכחת. ההמלצה המעשית שלי היא להתייחס לפיד כאל מערכת מלאי פרסומית, לא כאל קובץ שיווקי.

שרשרת האמת: מהקטלוג ועד הרכישה

ברוב החנויות נתוני מוצר כבר עוברים בין כמה מערכות: Shopify או פלטפורמת מסחר אחרת, מערכת מלאי, ERP, פיד ל־Merchant Center, schema בעמוד ו־GA4. הוספת פיד ל־ChatGPT יוצרת יעד נוסף, אך אינה יוצרת מקור אמת חדש. צריך להחליט איזו מערכת מוסמכת לקבוע מזהה, מחיר, מלאי, כתובת ותמונה, ואיך השינוי עובר לכל היעדים.

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

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

מוצר או וריאנט: מה צריכה לייצג כל שורה?

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

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

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

אילו נתונים צריך להכין לפני ההעלאה?

המפרט הרשמי כולל שדות בסיס חובה ושדות נוספים לתיאור מוצרים, וריאנטים, תמונות, מחיר, משלוח והחזרות. בקובץ לדוגמה מופיעים item_id, title, description, url, brand, image_url, price, availability, seller_name, seller_url, return_policy, מדינות יעד ושדות כשירות. אין להעתיק את שורת הדוגמה כמפרט קבוע; בודקים את גרסת ה־Stable העדכנית בזמן היישום.

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

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

CSV, Hosted URL או SFTP: איך בוחרים דרך עדכון?

CSV או TXT ידני מתאים לבדיקת היתכנות ולחנויות עם קטלוג קטן ויציב. היתרון הוא התחלה מהירה; החיסרון הוא שכל שינוי מלאי או מחיר תלוי באדם. Hosted URL מתאים כאשר המערכת יכולה לייצר קובץ עדכני בכתובת HTTPS קבועה. SFTP מתאים לצוות שצריך העלאות אוטומטיות ושליטה בתהליך שרת־לשרת.

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

OpenAI מתעדת גם Delta API לעדכון מחיר וזמינות של מוצרים קיימים. שינויים אחרים, הוספת מוצרים ורענון מלא נעשים באמצעות קטלוג מעודכן. תשובת accepted מה־API מאשרת שהבקשה התקבלה, לא שהשינוי כבר עובד באספקה; העיבוד מתרחש באופן אסינכרוני.

Product Sets ו־ads_metadata: לא כל מוצר צריך להיות בכל Ad Group

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

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

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

חמש משפחות כשל: למה מוצר לא מופיע?

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

כדי לאבחן נכון, מפרידים בין חמש משפחות: הקובץ לא נקלט; השורה נדחתה; המוצר נקלט אך אינו כשיר; המוצר כשיר אך אינו עובר את פילטר הקבוצה; המוצר נבחר אך טרם קיבל אספקה או דיווח. כל משפחה דורשת ראיה אחרת.

Upload History מציג סטטוסים, ספירות ואבחונים. completed_with_errors אומר שחלק מהנתונים עובדו אך נותרו שגיאות; completed אינו מבטיח שכל מוצר יכול לשרת. שדות חסרים, ערך לא תקין, סוג קובץ שאינו נתמך או מבנה תיקיות שגוי הם כשלים ברמת הקליטה. מחיר, זמינות, ביקורות, פילטרים וכשירות קמפיין עדיין יכולים להשפיע לאחר מכן.

איך מודדים קמפיין פיד בלי לעצור ב־ROAS כללי

קמפיין פיד צריך להימדד ברמת המוצר או קבוצת המוצרים, לא רק בסך החשבון. מוסיפים UTM עקבי ליעדים כאשר המימוש מאפשר זאת, מוודאים שאירועי view_item, add_to_cart, begin_checkout ו־purchase נשלחים עם item_id שתואם לזהות העסקית, ומשווים רכישות למערכת ההזמנות.

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

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

סדר יישום לחנות קיימת

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

לאחר מכן מעלים את הפיד, מחכים לסטטוס סופי, בודקים rejected ו־ads-eligible, ובונים Product Set אחד שקל להסביר. פותחים את תצוגת המוצר ואת דף היעד בכל וריאנט. רק אחרי שהזהות והנחיתה נכונות, משיקים תקציב מוגבל ובודקים אספקה, קליקים ואירועים.

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

• הגדרת מקור אמת ומזהים יציבים
• מדגם QA שמכסה וריאנט, מבצע ומלאי חסר
• העלאה ובדיקת Upload History
• אימות כשירות וספירת המוצרים
• Product Set אחד עם היגיון מסחרי
• בדיקת דף, סל ואירועי איקומרס
• פיילוט תקציבי לפני הרחבת הקטלוג
• אוטומציה, ניטור ופיוס קבוע

מתי לא כדאי להתחיל מפיד מוצרים?

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

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

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