הפעלת מעקב המרות

מדידת השיוך להמרות יכולה לכלול כמה גורמים, החל מבעלי האתר, המפרסם, טכנולוגיית הפרסום הדיגיטלי שדרכה המודעות מוצגות (הישות שמציגה את המודעה), ספק המדידה ועוד. במסמך הזה נסביר על תרחישים נפוצים למעקב המרות, אבל באופן כללי, כל צד שרוצה לקבל דוח שיוך מ-Attribution Reporting API‏ (ARA) צריך לוודא שהוא פועל לפי שלבי השילוב שמפורטים במסמך הזה.

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

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

Attribution Reporting API מאפשר למספר טכנולוגיות פרסום לרשום מקורות שיוך (Attribution) ומפעילים לאותה חשיפת מודעה או המרה, ולקבל דוחות נפרדים מה-API. לדוגמה, פלטפורמת ניהול רשתות המודעות יכולה לקבל דוחות שיוך משלה מ-Attribution Reporting API, וגם לאפשר דיווח נפרד לספק המדידה של המפרסם מצד שלישי. כדי לקבל דוחות מה-API, ספקי טכנולוגיות הפרסום צריכים לרשום גם את מקורות השיוך וגם את הטריגרים. השיוך מתבצע בין מקורות השיוך והטריגרים שספקי טכנולוגיות הפרסום רשמו בנפרד ב-API.

תרחישים נפוצים למעקב המרות

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

תרחיש 1: גם פלטפורמת הפרסום וגם ספק המדידה של הצד השלישי צריכים לקבל דוחות מ-Attribution Reporting API

מפרסם רוצה לשייך המרות במלאי שטחי הפרסום באמצעות ספק מדידה של צד שלישי, וחברת טכנולוגיית הפרסום שמארחת את הקריאייטיב רוצה לשייך המרות במלאי שטחי הפרסום. המצב הזה נפוץ בפלטפורמות DSP או בשרתי מודעות של מפרסמים (שרת מודעות של צד שלישי – 3PAS) שמספקים את ה-Markup לנכסי הקריאייטיב של המודעות, מבצעים דיווח שיוך משלהם ועובדים עם מפרסמים שמשתמשים בשילוב עם ספקי מדידה או ניתוח נתונים של צד שלישי.

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

הגדרה אופיינית של קמפיין עשויה להיראות כך:

  1. שרת המודעות של המפרסם (3PAS) מספק את ה-Markup של נכס הקריאייטיב של המודעה ל-DSP, כולל הפיקסלים למעקב אחר חשיפות וקליקים של ספק המדידה של הצד השלישי. שרת המודעות צריך לוודא שהתג attributionsrc נכלל בסימון ה-HTML של הקריאייטיב של המודעה.

  2. פלטפורמת ה-DSP מציעה יכולות להוספת פיקסלים נוספים למעקב אחר חשיפות ולמעקב אחר קליקים למטרות מדידה, וצריך לוודא שה-attributionsrc נכלל בסימון ה-Creative הסופי של המודעה שבו הם מגישים הצעות מחיר.

תרחיש 2: רק ספק המדידה של הצד השלישי צריך לקבל דוחות מ-Attribution Reporting API

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

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

בדוגמה הרגילה להגדרת קמפיין בתרחיש 1, יכול להיות ששרת המודעות של בעל התוכן הדיגיטלי, ה-SSP או בעל התוכן הדיגיטלי עצמו יצטרכו רק לוודא שהמאפיין attributionsrc שסופק על ידי ה-DSP מופיע בדף של בעל התוכן הדיגיטלי.

פרטי ההטמעה

בטבלה הבאה מתוארים השלבים להטמעת Attribution Reporting API ברמה גבוהה:

שלבים אחריות על העבודה דוגמאות
שלב 1: מפעילים את מקור השיוך לנכסי קריאייטיב ולקוד המדידה הקיימים הישות שאחראית להפעלת אירועי חשיפות או לטיפול באירועי קליקים מוסיפה את המאפיין attributionsrc. באירועי קליקים, בדרך כלל הקונה (שרת המודעות של ה-DSP או המפרסם) שמרינדר את הקריאייטיב מוסיף את המאפיין.

באירועי חשיפות, הפלטפורמה למפרסמים (DSP), הפלטפורמה של בעלי התוכן הדיגיטלי (SSP), בעל התוכן הדיגיטלי, שרת המודעות או ספק המדידה מוסיפים את המאפיין, והוא תלוי בהגדרה של בעל התוכן הדיגיטלי.

במודעות וידאו בפורמט VAST, המפרסם ו-Video SDK מוסיפים את המאפיין.
שלב 2: מפעילים דיווח על שיוך למקורות של צד שלישי האפשרות הזו פועלת מבלי שתצטרכו לבצע שינויים אם אתם משתמשים בנתיב קיים של הפניה אוטומטית עם הפניות אוטומטיות מסוג 302.

אם אי אפשר להשתמש בהפניות אוטומטיות מסוג 302, אפשר להשתמש במאפיין attributionsrc כדי לרשום כמה שרתים של טכנולוגיית פרסום.

 באופן כללי, כל עוד המאפיין attributionsrc מתווסף לקריאייטיב, ההפניות האוטומטיות של הצד השלישי אמורות לקבל את הקריאות ל-Attribution Reporting API.
שלב 3: הגדרת תשובות לבקשות של Attribution Reporting API כל ישות שרוצה לקבל דוחות מ-Attribution Reporting API פלטפורמת ה-DSP וחברת המדידה של הצד השלישי שבהן המפרסם משתמש

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

שלב 1: מפעילים את מקור השיוך לנכסי קריאייטיב ולקוד המדידה הקיימים

בשלב הראשון, מפעילים את מקורות השיוך.

איך פועל המאפיין attributionsrc

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

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

כשהשדה attributionsrc ריק, הבקשות ל-ARA נשלחות לכתובת ה-URL שמוגדרת במאפיין href של תג האנקור (כתובת ה-URL של הקליקים). כשמגדירים את המאפיין attributionsrc, בקשות ה-ARA נשלחות לכתובת ה-URL שמוגדרת במאפיין attributionsrc. גם כתובת ה-URL של הקליקים עומדת בדרישות לרישום מקורות.

באופן כללי, כדאי להשתמש במאפיין attributionsrc ריק אם השרת שמארח את כתובת ה-URL של הקליקים יכול לקבל ולענות לבקשות של Attribution Reporting API. אם רוצים שהבקשות של Attribution Reporting API יישלחו לשרת אחר, צריך להגדיר כתובת URL משלכם של attributionsrc.

דוגמה למאפיין attributionsrc ריק:

ההגדרות הקיימות עם שילוב של ARA
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>

כשהמאפיין attributionsrc ריק, הבקשות ל-Attribution Reporting API נשלחות לכתובת ה-URL שמוגדרת במאפיין href של תג העוגן.

דוגמה למאפיין attributionsrc שאינו ריק:

ההגדרות הקיימות עם שילוב של ARA
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc="[ATTRIBUTION_SRC_URL]">...</a>

אם השדה attributionsrc לא ריק, הבקשות ל-Attribution Reporting API יישלחו לכתובת ה-URL שמוגדרת בתג attributionsrc. גם כתובת ה-URL של הקליקים עומדת בדרישות לרישום מקורות.

הוספת attributionsrc לאירועי קליקים וחשיפות

  • אירועי קליקים:
    • הישות שאחראית להוספת attributionsrc היא בדרך כלל טכנולוגיית הפרסום שמוצגת.
    • צריך להוסיף מאפיין attributionsrc לתגי עוגן עם אירועי קליקים.
    • כדי לציין את מקור השיוך, צריך להשתמש בארגומנט windowFeatures של הקריאה window.open בקליקים באמצעות window.open.
  • אירועי חשיפות:
    • הישות שאחראית להוספת attributionsrc היא בדרך כלל חברת טכנולוגיית הפרסום שמציגה את המודעות וספקי המדידה.
    • אירועי חשיפות שמופעל מהתג <img> או מהתג <script> צריכים לכלול מאפיין attributionsrc.
    • אירועי חשיפות שמשתמשים ב-Fetch API צריכים לכלול אובייקט attributionReporting בארגומנט options שמוענק לקריאה ל-Fetch API.

בטבלה הבאה מופיע סיכום של השינויים הנדרשים באירועי קליקים וחשיפות:

אירוע תיוג ההגדרות הקיימות אחרי שילוב ARA
קליק HTML <a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>
JavaScript window.open("[CLICKTHROUGH_URL]", "_blank"); window.open("[CLICKTHROUGH_URL]", "_blank", "attributionsrc");
חשיפה תג HTML <img> <img src="[IMPRESSION_URL]"> <img src="[IMPRESSION_URL]" attributionsrc>
תג HTML <script> <script src="[IMPRESSION_URL]"></script> <script src="[IMPRESSION_URL]" attributionsrc></script>
JavaScript const options = {...}
window.fetch("[IMPRESSION_URL]", options); 		const options = {
  attributionReporting: {
    eventSourceEligible: true,
    triggerEligible: false,
  },
  ...
};
window.fetch("[IMPRESSION_URL]", options);

הפעלת רישום של מקור שיוך במכרז עם Protected Audience API

כדי למדוד המרות במכרזים של קהלים מוגנים, במקום להשתמש ב-attributionsrc, אפשר להשתמש ב-registerAdBeacon/registerAdMacro וב-setReportEventDataForAutomaticBeacons/reportEvent כדי לאפשר רישום של מקורות שיוך.

כדי לדווח על אותות של קהלים מוגנים, הפונקציה registerAdBeacon זמינה בתוך רכיבי העבודה של הדוחות, והפונקציה registerAdMacro זמינה בתוך רכיב העבודה של הדוחות על המכרזים שהרווחתם. לאחר מכן, אפשר להוסיף את נתוני האירועים בתוך מסגרת המודעה למיקרופונים ולמאקרוים הרשומים באמצעות הפונקציות reportEvent ו-setReportEventDataForAutomaticBeacons של Fenced Frame Ads Reporting API. כך ניתן לשייך את האותות של נכסי ה-worklet לדיווח על Protected Audience לבין עומס הנתונים של אירוע המסגרת של נכס הקריאייטיב של המודעה.

הכותרת Attribution-Reporting-Eligible של HTTP מתווספת לבקשה כשהבייקונים והמאקרו מופעלים על ידי הקריאה reportEvent מהפריים, או שהבייקונים האוטומטיים מופעלים על ידי הדפדפן. אפשר להשתמש בתגובה של ה-beacon כדי לרשום מקור שיוך. יכול להיות שהבקשות מהחיישנים יועברו לכתובת אחרת כדי לאפשר מדידה על ידי צד שלישי.

לקבלת מידע מפורט יותר, אפשר לעיין בקטע תמיכה בדיווח על שיוך במאמר ההסבר על Fenced Frame Ad Reporting API.

הפעלת דיווח על שיוך (Attribution) בפורמטים של VAST

VAST הוא פורמט נפוץ להצגה ולמדידה של מלאי שטחי פרסום למודעות וידאו, ורבים מהאירועים שמוגדרים בתקן הזה צריכים להיחשב כאירועי מקור פוטנציאליים שעומדים בדרישות הרישום ב-Attribution Reporting API. הנספח ל-VAST לתמיכה בדוחות שיוך (Attribution) עוסק בנושא הזה בפירוט, אבל בקצרה, כל האירועים מסוג <Tracking>,‏ <Impression>,‏ <*ClickThrough> ו-<*ClickTracking> הם אירועים פוטנציאליים של מקורות שיוך. כל הטמעות ה-VAST צריכות לספק כיסוי של האירועים האלה לצורך הרשמה.

בנספח VAST מוגדרים מאפיינים חדשים לרכיבים האלה, כדי לאפשר להגדיר כתובת URL משנית במיוחד לצורך רישום שיוך (Attribution). כשאירוע מכיל את הפרמטרים attributiontype="DOUBLE_PING" ו-attributionsrc="[URL]", הקוד שמפעיל את האירוע הזה צריך להשתמש ב-[URL] כערך של המאפיין attributionsrc כשמפעילים את Attribution Reporting API. התוספת ל-VAST מכילה דוגמאות לכל תרחיש.

כדי להבטיח כיסוי מקסימלי, כשמפעילים פינגים של אירועים, כל האירועים שרשומים בהטמעות VAST צריכים להיות כשירים לרישום כברירת מחדל. לדוגמה, כשמפעילים כתובת URL של אירוע <Impression>, צריך להשתמש במאפיין attributionsrc (ריק) ברכיב <img> שמשמש לשליחת הבקשה (או ברכיב המקביל בקריאת האחזור), כדי שתמיד תהיה אפשרות לצד המקבל לרשום את האירוע הזה ב-Attribution Reporting API.

שלב 2: מפעילים דיווח על שיוך למקורות של צד שלישי

כדי לאפשר לצדדים שלישיים להשתמש ב-Attribution Reporting API, אפשר להשתמש בהפניות אוטומטיות קיימות או להוסיף רשימה של צדדים שלישיים למאפיין attributionsrc. ברוב המקרים, לכל טכנולוגיית פרסום יש שירות מעקב חשיפות עצמאי משלה, ולכן הפניות אוטומטיות רלוונטיות יותר למעקב אחר קליקים.

טיפול במקורות של צד שלישי בשרשרת הפניות אוטומטיות קיימת

בקליק טיפוסי על מודעה, יכולים להיות הרבה כלים למעקב אחר קליקים כשרשרת של הפניות אוטומטיות מסוג 302 שמתבצעות כחלק מהניווט לדף הנחיתה הסופי. כל בקשה בשרשרת ההפניה האוטומטית עומדת בדרישות לרישום ב-Attribution Reporting API אם יעד הקליק המקורי סומן ב-attributionsrc או נרשם באמצעות registerAdBeacon/registerAdMacro ב-Protected Audience API. צריך גם להירשם ל-AdTech בשרשרת ההפניה האוטומטית.

הערה: גוף הבקשה הראשונית לא נשלח בהפניות אוטומטיות. במכרזים של קהלים מוגנים, אם eventData מועבר אל reportEvent ויש צורך להשתמש ב-setReportEventDataForAutomaticBeacons כחלק מההפניה האוטומטית, צריך להעביר אותו במפורש כחלק מכתובת ה-URL להפניה האוטומטית.

בדוגמה הבאה נשתמש בטכנולוגיית פרסום להצגת מודעות (serving-adtech.example) ובספק מדידה של צד שלישי (3p-measurement.example) בתור שתי ישויות נפרדות שרוצות ליצור ולקבל דוחות שיוך. טכנולוגיית הפרסום להצגת המודעות בדוגמה הזו יכולה להיות פלטפורמת ניהול רשתות פרסום (DSP) שמרינדרת את הקריאייטיב באתר של בעל התוכן הדיגיטלי, ויש לה מוצר דיווח משלה. ספק המדידה של הצד השלישי יכול להיות ישות שהמפרסם משתמש בה לצורך דיווח על המרות.

תרשים שמתאר איך הצד הראשון רושם את המקור, ואז הצד השלישי רושם את

בזמן רישום המקור מתבצעים השלבים הבאים:

  1. serving-adtech.example מגדיר את המאפיין attributionsrc בקריאייטיב.המשתמש מבקר בדף של בעל התוכן הדיגיטלי, והדפדפן שולח בקשה אל serving-adtech.example.
  2. serving-adtech.example משיב עם הכותרת Attribution-Reporting-Register-Source והכותרת Location.
    1. serving-adtech.example משתמש בכותרת Attribution-Reporting-Register-Source כדי להשיב עם מטא-נתונים על המקור שרוצים לרשום.
    2. serving-adtech.example משתמש בכותרת Location כדי לכלול הפניה אוטומטית אל 3p-measurement.example. לתשומת ליבכם: סביר להניח שכבר נעשה שימוש בכותרת Location בתהליכי המעקב הקיימים אחר קליקים כדי לתמוך בהפניות אוטומטיות של 302 לצד שלישי.
  3. הדפדפן מקבל את התגובה מ-serving-adtech.example ומנתח את הכותרת Attribution-Reporting-Register-Source. הדפדפן מאחסן את אירוע המקור, באמצעות serving-adtech.example כמקור הדיווח.
  4. מכיוון שהבקשה הזו היא הפניה אוטומטית, הדפדפן שולח גם בקשה חדשה אל 3p-measurement.example.
  5. 3p-measurement.example משיב בתגובה שמכילה את הכותרת Attribution-Reporting-Register-Source.
  6. הדפדפן מקבל את התגובה הזו מ-3p-measurement.example וקורא את Attribution-Reporting-Register-Source. הדפדפן מאחסן את אירוע המקור, באמצעות 3p-measurement.example כמקור הדיווח.

שימוש ב-attributionsrc למקורות של צד שלישי שלא נמצאים בשרשרת של הפניות אוטומטיות

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

ההגדרות הקיימות עם שינוי של ARA
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc="[REPORTING_URL_1] [REPORTING_URL_2]">...</a>

בדוגמה הזו, בקשות שעומדות בדרישות של Attribution Reporting API יישלחו גם אל REPORTING_URL_1 וגם אל REPORTING_URL_2. בקשת הניווט שנשלחת לכתובת ה-URL של הקליקים עומדת בדרישות לרישום מקורות שיוך.

שלב 3: הגדרת תשובות לבקשות של Attribution Reporting API

בכל המקורות שמקבלים בקשת Attribution Reporting API, חשוב לוודא שהשרת מגיב עם הכותרת המתאימה Attribution-Reporting-Register-Source. במדריך רישום מקורות ובהסבר מוסבר איך צריך לבנות את התגובה.

רישום של מספר טריגרים

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

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