חיבור קטלוג לפיקסל: התאמת מזהי מוצר שסוגרת את המעגל
למה קמפיין דינמי לא נבנה גם כשהפיקסל משדר והקטלוג מלא, ואיך מאתרים את הנקודה שבה מזהי המוצר מפסיקים להתאים.
יש שלב מוכר בכל חנות מקוונת שמתחילה לפרסם: הפיקסל מותקן ומדווח אירועים, הקטלוג הועלה ומכיל את כל המוצרים, ובכל זאת הקמפיין הדינמי מציג מוצרים אקראיים, או שהוא בכלל לא יוצא לאוויר. שני הרכיבים קיימים, אבל הם לא מדברים זה עם זה.
הסיבה כמעט תמיד זהה, והיא לא באמת טכנית: המזהה שהאירוע שולח אינו המזהה שרשום בקטלוג. המאמר הזה עוסק בדיוק בנקודת התפר הזאת — מה מחבר בין קטלוג המוצרים לבין הפיקסל, אילו פרמטרים חייבים לצאת מכל עמוד, למה ההתאמה נשברת בחנויות עם וריאציות, ואיך בודקים את זה בלי לנחש. את ההתקנה הבסיסית של הפיקסל עצמו אפשר להשלים במדריך על הגדרה נכונה של Meta Pixel; כאן מתחילים מהנקודה שבה הוא כבר משדר.
חיבור קטלוג לפיקסל: איך מזהי המוצר נפגשים ומה שובר את ההתאמה
המנגנון פשוט יותר משנדמה. הקטלוג הוא רשימה של פריטים, ולכל פריט יש מזהה — מחרוזת שהחנות קובעת. הפיקסל, בכל פעם שמישהו צופה במוצר או מוסיף אותו לעגלה, שולח אירוע שנושא בתוכו רשימת מזהים. השיוך בין מקור הנתונים לקטלוג אומר למערכת איפה לחפש, ומשם ההתאמה נעשית על ידי השוואת מחרוזות. אם המחרוזות אינן זהות, אין התאמה — גם אם מדובר באותו מוצר בדיוק.
שלושה חלקים שצריכים להתקיים במקביל
- פיקסל שמשדר מהעמודים הנכונים. לא מספיק שהוא טעון בכל האתר; הוא צריך לשלוח אירוע ייעודי בעמוד המוצר, בעגלה ובדף התודה.
- קטלוג תקין. פריטים עם מזהה, מחיר, זמינות וקישור לעמוד המוצר, שמתעדכן כשהמלאי משתנה. פיד שנתקע לפני חודש מייצר מודעות למוצרים שאזלו.
- שיוך מוצהר בין השניים. בממשק ניהול המסחר מגדירים שמקור הנתונים של הקטלוג הוא הפיקסל הזה. בלי ההצהרה הזאת האירועים ממשיכים להיאסף, אבל אף אחד לא משווה אותם לקטלוג.
אילו אירועים חייבים לצאת, ומה חייב להיות בתוכם
המזהים לבדם אינם מספיקים. לכל אירוע יש פרמטרים שבלעדיהם הוא נספר, אבל לא שימושי:
| אירוע | מתי נשלח | מה חייב להישלח איתו | מה נשבר בלעדיו |
|---|---|---|---|
| צפייה במוצר | בטעינת עמוד מוצר | רשימת מזהים, סוג התוכן, מחיר ומטבע | אין קהל של מתעניינים במוצר מסוים, ולכן אין ממה לבנות מודעה דינמית |
| הוספה לעגלה | בלחיצה על הכפתור, גם כשאין רענון עמוד | אותם פרמטרים, בתוספת כמות | אין קהל של עגלות נטושות — הקהל שנוטה להחזיר את ההוצאה |
| רכישה | בעמוד התודה או באישור ההזמנה | מזהים, סכום ומטבע בפועל | אין ייחוס הכנסה למוצר, והמערכת מיטבת לכיוון עיוור |
שימו לב לשורה השנייה. בחנויות רבות ההוספה לעגלה מתבצעת בלי טעינת עמוד חדש, ולכן האירוע פשוט לא נורה. זו אחת התקלות שחוזרות, והיא נראית בממשק בדיוק כמו חנות שאיש לא מוסיף בה מוצרים לעגלה. אם אתם מנהלים את הקודים דרך Google Tag Manager, אפשר לתלות את האירוע בלחיצה על הכפתור במקום בטעינת דף.
הטעות שחוזרת: מזהה אחד בקטלוג, מזהה אחר באירוע
זה השורש של רוב המקרים שבהם הכול מוגדר ואחוז ההתאמה נמוך. כמה דפוסים מוכרים:
- וריאציות. הקטלוג מכיל שורה נפרדת לכל וריאציה — מידה, צבע, נפח — ולכל אחת מזהה משלה, בעוד עמוד המוצר שולח את מזהה מוצר האב. שתי הרשימות נכונות בפני עצמן ואינן נפגשות.
- מזהה מול מק״ט. הפיד נבנה סביב המק״ט הפנימי, והאירוע שולח את המזהה שמערכת החנות מייצרת. שניהם מספרים אמיתיים, ואינם אותו מספר.
- קידומת שנוספה בדרך. תוספים ומחוללי פידים מוסיפים לעיתים קידומת קבועה לפני המזהה. ההפרש הוא כמה תווים בתחילת המחרוזת, וההשוואה נכשלת במלואה.
- אפסים מובילים ורווחים. מזהה שנשמר כטקסט שומר אפס בהתחלה; אותו מזהה שעבר דרך גיליון וחזר כמספר איבד אותו. רווח נסתר בסוף המחרוזת עושה את אותו דבר.
הבדיקה המעשית לוקחת דקות: פתחו עמוד מוצר, הסתכלו במזהה שהאירוע שולח, ואחר כך מצאו את אותו פריט בקטלוג והשוו את שתי המחרוזות תו מול תו. אם הן נבדלות, מצאתם את הבעיה — והתיקון נעשה בצד שקל יותר לשנות בו, בדרך כלל אופן בניית הפיד.
סוג התוכן, ולמה הוא משנה בחנויות עם וריאציות
לצד רשימת המזהים נשלח גם שדה שמצהיר על סוג התוכן: פריט בודד או קבוצת פריטים. חנות שמדווחת על מוצר אב אבל מצהירה עליו כפריט בודד יוצרת אי-התאמה שנראית בדיוק כמו מזהה שגוי, וזו הסיבה שכדאי לבדוק את שני השדות יחד ולא רק את המזהים. הכלל הפשוט: מה שנשלח צריך להתאים לרמה שבה הקטלוג בנוי.
איך בודקים בלי לנחש
- בממשק ניהול האירועים, פתחו את כלי הבדיקה החי וגלשו בעצמכם בחנות: עמוד מוצר, הוספה לעגלה, ורכישת בדיקה אם אפשר. האירועים אמורים להופיע בזמן אמת עם הפרמטרים שלהם.
- בממשק הקטלוג, פתחו את מסך האבחון. הוא מציג כמה פריטים הותאמו לאירועים וכמה לא, וזהו המספר שמסביר למה קמפיין דינמי לא מצליח להיבנות.
- בדקו שהפיד מתעדכן. פיד ידני שהועלה פעם אחת יתיישן; חיבור אוטומטי או פיד מתוזמן פותר את זה. אותם עקרונות שמתוארים במדריך על הגדרת פיד מוצרים תקפים גם כאן.
- ודאו שזמינות ומחיר בקטלוג תואמים למה שמופיע בעמוד. פער ביניהם פוגע בביצועים גם כשההתאמה עצמה תקינה.
מה זה פותח אחרי שההתאמה עובדת
ברגע שהאירועים והקטלוג מדברים באותה שפה, נפתחות שלוש יכולות שלא היו קיימות קודם. הראשונה היא מודעה שמציגה למשתמש את המוצר שהוא עצמו צפה בו, במקום תמונה כללית של המותג. השנייה היא קהלים שנבנים מהתנהגות ברמת המוצר — מי צפה ולא הוסיף, מי הוסיף ולא רכש — וזה בסיס טוב לעבודה על שחזור עגלות נטושות. השלישית היא דיווח הכנסה ברמת הפריט, שמאפשר לראות אילו מוצרים באמת מחזירים את ההוצאה ולא רק אילו מהם קיבלו הקלקות.
הצד שנשכח: מי מחזיק את הקטלוג ואת הפיקסל
הקטלוג והפיקסל אינם נכסים של חשבון פרסום אלא של החשבון העסקי שמחזיק אותם. כשסוכנות או פרילנסר מקימים אותם תחת החשבון העסקי שלהם, העסק מקבל גישה ולא בעלות — וביום שהקשר מסתיים, ההיסטוריה שנצברה בפיקסל, שהיא הנכס האמיתי כאן, נשארת בצד השני. הסידור הנכון הוא הפוך: העסק מחזיק את החשבון העסקי, את הפיקסל ואת הקטלוג, ומעניק לספק גישת שותף שאפשר לבטל בלחיצה.
שתי הרגלים משלימים את זה. ראשית, כשספק מסיים פרויקט, הסירו את הגישה שניתנה לו — הרשאה נשארת פעילה עד שמישהו מבטל אותה ביוזמתו. שנית, הפעילו אימות דו-שלבי על החשבונות שמנהלים את הנכסים האלה, כי גישה לחשבון עסקי שולטת גם בתקציב הפרסום. שווה גם להכיר את דפוס ההונאה שרודף אחר מנהלי חנויות: הודעה שנראית כאילו הגיעה מהפלטפורמה, מודיעה שהקטלוג עומד להימחק או שהחשבון הוגבל, ומצרפת קישור להתחברות דחופה. פלטפורמות אינן מבקשות סיסמה דרך קישור בהודעה, והתגובה הנכונה זהה תמיד: לא ללחוץ, להיכנס דרך הכתובת הרגילה, ולבדוק אם ההתראה מופיעה גם שם.
סדר עבודה שמונע את רוב התקלות
אם אתם מתחילים מאפס, הסדר הזה חוסך חזרות: קודם מוודאים שהפיקסל משדר את שלושת האירועים עם הפרמטרים שלהם, אחר כך בונים את הפיד סביב אותו מזהה בדיוק שהאירועים שולחים, ורק בסוף מגדירים את השיוך ומריצים בדיקה חיה. חנות שכבר רצה עושה את אותו מסלול בסדר הפוך — מתחילה ממסך האבחון, שמצביע ישירות על החלק השבור.
בשורה התחתונה, חיבור קטלוג לפיקסל הוא בדיקת התאמה ולא הגדרה מסובכת. שתי רשימות צריכות להשתמש באותן מחרוזות, ורוב הזמן שמושקע כאן הולך לאיתור המקום שבו הן התפצלו.
שאלות נפוצות
התקנתי פיקסל והעליתי קטלוג, ולמה הקמפיין הדינמי עדיין לא נבנה?
בדרך כלל חסר אחד משניים. או שלא הוגדר שיוך בין הקטלוג לבין הפיקסל בממשק ניהול המסחר, ואז האירועים נאספים אך אינם מושווים לאף רשימת פריטים; או שהשיוך קיים אבל המזהים אינם זהים, ולכן אחוז ההתאמה אפסי. מסך האבחון של הקטלוג מפריד בין שני המקרים תוך דקות.
החנות שלי מוכרת מוצרים עם מידות וצבעים. איזה מזהה צריך לשלוח?
את המזהה שקיים בקטלוג ברמה שבה הקטלוג בנוי. אם לכל וריאציה יש שורה משלה, עמוד המוצר צריך לשלוח את מזהה הווריאציה שנבחרה ולא את מזהה מוצר האב. במקביל, שדה סוג התוכן צריך להצהיר אם מדובר בפריט בודד או בקבוצת פריטים — הצהרה שאינה תואמת לרמת הקטלוג נראית בדיוק כמו מזהה שגוי.
אחוז ההתאמה נמוך אבל המזהים נראים זהים. מה עוד לבדוק?
שלושה הבדלים שקשה לראות בעין. אפס מוביל שנעלם כשהמזהה עבר דרך גיליון וחזר כמספר; רווח נסתר בסוף המחרוזת; וקידומת קבועה שמחולל הפיד מוסיף לפני המזהה. העתיקו מזהה אחד מכל צד להשוואה תו מול תו, ואם מצאתם הפרש, תקנו אותו באופן בניית הפיד ולא פריט אחר פריט.
מי צריך להחזיק את הקטלוג ואת הפיקסל, העסק או הסוכנות?
העסק. הפיקסל צובר היסטוריית התנהגות שאי אפשר לשחזר, וכשהוא מוקם תחת החשבון העסקי של ספק חיצוני, ההיסטוריה הזאת נשארת שם בסיום ההתקשרות. הסידור הנכון הוא שהעסק מחזיק את החשבון העסקי, את הפיקסל ואת הקטלוג, ומעניק לספק גישת שותף שאפשר לבטל. כשההתקשרות מסתיימת, מסירים את הגישה.
