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

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

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

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

Attribution Reporting API מאפשר למספר טכנולוגיות פרסום לרשום מקורות שיוך וטריגרים עבור אותה חשיפה או המרה, ולקבל דוחות נפרדים מה-API. לדוגמה, ספק DSP יכול לקבל דוחות שיוך (Attribution) משלו מה-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 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 כדי לרשום כמה שרתים טכנולוגיים (ATP).

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

הערה: הפרטים הספציפיים של כל שלב תלויים באופן שבו נכסי הקריאייטיב מוצגים ומוצגים בדף של בעל התוכן הדיגיטלי, ובישויות של טכנולוגיות הפרסום שמקבלות דוחות שנשלחים על ידי 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. כתובת אתר בעקבות קליק מתאימה גם לרישום מקורות.

באופן כללי, כדאי להשתמש במאפיין attributionsrc ריק אם השרת שמארח את כתובת היעד של הקליק יכול לקבל בקשות ל-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. כתובת אתר בעקבות קליק מתאימה גם לרישום מקורות.

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

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

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

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

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

כדי להתעמק בנושא, אפשר לעיין בקטע 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. גם טכנולוגיות הפרסום בשרשרת ההפניה האוטומטית צריכות לרשום.

שימו לב שגוף הבקשה הראשונית לא נשלח בהפניות אוטומטיות. במכרזים של Protected Audience, אם צריך להשתמש במאפיין 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 של הקליק יכולה לרשום מקורות שיוך.

שלב 3: מגדירים תשובות לבקשות של Attribution Reporting API

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

רישום של כמה טריגרים

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

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