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

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

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

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

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

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

פרטי ההטמעה

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

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

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

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

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

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

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

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

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

‫VAST הוא פורמט נפוץ להצגה ולמדידה של מלאי שטחי פרסום של מודעות וידאו, ורבים מהאירועים שמוגדרים בתקן הזה נחשבים לאירועי מקור פוטנציאליים שעומדים בדרישות לרישום ב-Attribution Reporting API. הנושא הזה מוסבר בפירוט בנספח VAST לתמיכה בדוחות שיוך, אבל בקצרה, כל האירועים <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 Reporting API, אפשר להשתמש בהפניות או להוסיף רשימה של צדדים שלישיים למאפיין attributionsrc. ברוב המקרים, לכל טכנולוגיית פרסום יש כלי עצמאי למעקב אחר חשיפות, ולכן הפניות אוטומטיות רלוונטיות יותר לכלי מעקב אחר קליקים.

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

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

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

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

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

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

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

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