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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פרטי ההטמעה

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

שלבים	אחריות העבודה	דוגמאות
שלב 1: מפעילים את מקור השיוך (Attribution) עבור נכסי קריאייטיב קיימים וקוד מדידה קיים	הישות שאחראית להפעלת אירועי חשיפות או לטיפול באירועי קליקים מוסיפה את המאפיין attributionsrc.	באירועי קליק, בדרך כלל קונה (שרת מודעות מסוג DSP/מפרסם) שמעבד את הקריאייטיב מוסיף את המאפיין. לאירועי חשיפה, המאפיין בצד הביקוש (DSP), פלטפורמה לספקים (SSP), בעל תוכן דיגיטלי, שרת מודעות או ספק מדידה מוסיפים את המאפיין, והוא תלוי בהגדרות של בעל התוכן הדיגיטלי. עבור מודעות וידאו בפורמט VAST, בעל האתר וה-SDK של הווידאו מוסיפים את המאפיין.
שלב 2: מפעילים דיווח על שיוך (Attribution) למקורות צד שלישי	התכונה הזו פועלת באופן מיידי אם משתמשים בנתיב קיים של הפניה אוטומטית עם הפניות 302. אם לא ניתן להשתמש בהפניות 302, אפשר להשתמש במאפיין attributionsrc כדי לציין כמה שרתים של פרסום דיגיטלי.	באופן כללי, כל עוד המאפיין attributionsrc מתווסף לקריאייטיב, ההפניות האוטומטיות של צד שלישי אמורות לקבל את הקריאות ל-Attribution Reporting API.
שלב 3: הגדרת תגובות לבקשות של Attribution Reporting API	כל ישות שרוצה לקבל דוחות מ-Attribution Reporting API	פלטפורמת ה-DSP וספק הצד השלישי למדידה של המפרסם

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

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

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

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

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

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

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

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

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

דוגמה למאפיין 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
  • לקליקים שנעשה בהם שימוש ב-window.open צריך להשתמש בארגומנט windowFeatures של הקריאה ל-window.open כדי לציין את מקור השיוך.
• אירועי חשיפות:
  • הישות שאחראית להוספת attributionsrc היא בדרך כלל ספקי טכנולוגיית הפרסום וספקי המדידה
  • אירועי חשיפה שהופעלו מתג <img> או מתג <script> צריכים לכלול את המאפיין attributionsrc.
  • אירועי חשיפות שמשתמשים ב-אחזור API צריכים לכלול אובייקט attributionReporting בארגומנט אפשרויות שמועבר אל הקריאה ל-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 />
	תג <script> ב-HTML	<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);

הפעלת רישום של מקור שיוך (Attribution) במכירה פומבית של Protected Audience

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

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

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

הערה: Fenced Frame Ads Reporting API זמין גם ב-iframe וגם ב-Fenced frame

הסבר מעמיק יותר זמין בקטע Support for Attribution Reporting בהסבר של Fenced Frame Ad Reporting API.

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

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

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

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

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

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

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

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

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

בדוגמה הבאה נשתמש בטכנולוגיה של מודעות להצגת מודעות (serving-adtech.example) ובספק שירותי מדידה של צד שלישי (3p-measurement.example) כשתי ישויות נפרדות שרוצות ליצור ולקבל דוחות שיוך (Attribution). הטכנולוגיה להצגת מודעות בדוגמה זו יכולה להיות 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 של שירות הקליקים כשירה לרישום מקורות של שיוך.

אזהרה: הבקשות האלה נשלחות רק בדפדפנים שתומכים ב-Attribution Reporting API, ויכול להיות שהבקשות יאבדו בסביבות שאינן תומכות.

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

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

רישום טריגרים מרובים

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

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