סינון מקורות לפני השיוך באמצעות היקפי שיוך

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

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

במהלך רישום המקור

פרמטר אופציונלי attribution_scopes נוסף לכותרת Attribution-Reporting-Register-Source, שמכילה שני פרמטרים נדרשים: values ו-limit, ופרמטר אופציונלי אחד: max_event_states.

  • limit: מייצג את המספר הכולל של היקפים שונים שמותרים לכל יעד עבור מקור הדיווח. כל המקורות הרשומים הקיימים עם אותו מקור ויעד של דיווח, אבל עם מגבלה קטנה יותר, יימחקו.
  • values: מייצג את רשימת היקפי השיוך למקור מסוים. הערכים האלה חייבים להיות מחרוזות באורך של עד 50 תווים.
  • ‫max_event_states (אופציונלי): מייצג את המספר המקסימלי של מצבי אירוע שהמתקשר ל-API מתכנן להשתמש בהם בכל הרישומים הבאים של מקורות אירועים. שימו לב: כל המקורות הרשומים הקיימים עם אותו מקור ויעד של דיווח אבל עם max_event_states value שונה יימחקו. ערך ברירת המחדל של השדה האופציונלי הזה הוא 3.

דוגמה לרישום מקור

  Attribution-Reporting-Register-source: {
  //optional
  "attribution_scopes":{
  "limit": <int>,
  "values": <list of strings>,
  // optional
  "max_event_states": <int>
    },
  ...
  }

במהלך רישום הטריגר

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

דוגמה להרשמה להפעלת טריגר

Attribution-Reporting-Register-Trigger: {
//optional
"attribution_scopes": <list of strings>,
...
}

דוגמה להיקפי ייחוס

בדוגמה הבאה מוצג המקרה שבו טריגר משויך למקור בזמן השימוש בהיקפי שיוך.

רישום המקור מספר 1

  Attribution-Reporting-Register-source: {
  "destination": "https://trigger.example",
  "attribution_scopes": {
  "limit": 2,
  "values": ["advertiser1"],
  "max_event_states": 3
  },
  ...
  }

רישום מקור #2

  Attribution-Reporting-Register-source: {
  "destination": "https://trigger.example",
  "attribution_scopes": {
  "limit": 2,
  "values": ["advertiser2"],
  "max_event_states": 3
  },
  ...
  }

רישום טריגר

  Attribution-Reporting-Register-Trigger: {
  "attribution_scopes": ["advertiser1"],
  ...
  }

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

היקפי שיוך לעומת מסננים

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

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

ארבע תיבות עם התוויות &#39;מספרי מקור 1&#39; עד &#39;מספרי מקור 4&#39; ותיבה אחת עם התווית &#39;טריגר מס&#39; 1&#39;. למקור הראשון יש את המאפיינים &#39;היקף השיוך&#39;: &#39;ביגוד ספורט&#39; ועדיפות: 2. למקור השני יש את המאפיינים &#39;היקף השיוך&#39;: &#39;ביגוד ספורט&#39; ו&#39;מסנן&#39;: &#39;ביגוד עליון&#39;. למקור השלישי יש את המאפיינים &#39;היקף השיוך&#39;: &#39;casualwear&#39;, מסנן: &#39;outerwear&#39;. למקור הרביעי יש את המאפיינים &#39;היקף השיוך&#39;: &#39;casualwear&#39;, &#39;מסנן&#39;: &#39;outerwear&#39; ו&#39;עדיפות&#39;: 1. למאפיין &#39;טריגר&#39; יש את המאפיינים &#39;היקף השיוך&#39;: &#39;casualwear&#39; ו&#39;מסנן&#39;: &#39;outerwear&#39;.
דוגמה לאופן שבו שיוך פועל עם היקפי שיוך ומסננים

לפני השיוך

  • מקור מספר 1 מסונן כי היקף השיוך שלו לא תואם להיקף של אירוע ההפעלה casualwear. העובדה שמקור מסוים הוא בעל העדיפות הגבוהה ביותר מבין כל המקורות הזמינים לא מונעת את הסינון שלו, כי הסינון לפני השיוך מתבצע לפני בדיקת העדיפויות.
  • גם מקור מספר 2 מסונן כי אין לו את אותו היקף כמו הטריגר. במקור הזה יש גם את אותו מסנן כמו בטריגר, אבל מסננים ברמה גבוהה לא מוחלים עד אחרי השיוך (Attribution).

במהלך השיוך

  • מקור מספר 3 לא נבחר לשיוך כי העדיפות שלו נמוכה יותר מזו של מקור מספר 4.
  • מקור מספר 4 נבחר כי היקף השיוך שלו תואם לטריגר והוא בעדיפות הגבוהה ביותר. מסננים ברמה גבוהה מוחלים אחרי השיוך, ולכן הם לא נלקחים בחשבון במהלך תהליך השיוך.

שיוך פוסטים

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

בדוגמה הקודמת לא נוצר דוח. עם זאת, אם המקור הרביעי יוסר לגמרי:

אותן ארבע תיבות עם התוויות &#39;מספרי מקור 1&#39; עד &#39;מספרי מקור 4&#39; ותיבה אחת עם התווית &#39;הפעלה מס&#39; 1&#39;. ההבדל בתמונה הזו הוא שהתיבה עם התווית &#39;מקור מספר 4&#39; מסומנת ב-X אדום.
דוגמה שעברה שינוי שממחישה איך שיוך (Attribution) עובד עם היקפי שיוך ומסננים

במהלך השיוך

  • מקור מספר 3 נבחר כי היקף השיוך שלו חופף להיקף של הטריגר.

שיוך פוסטים

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

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

המיקום של היקפי שיוך בתהליך השיוך

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

גרסה פשוטה של תהליך הייחוס, שבה כל שלב מיוצג כריבוע שמקושר לשלב הבא באמצעות חץ. השלבים לפי הסדר הם &#39;רישום מקורות&#39;, &#39;רישום טריגרים&#39;, &#39;התאמת מקורות&#39;, &#39;בדיקת היקפי שיוך&#39;, &#39;שיוך&#39;, &#39;בדיקת מסננים&#39;, &#39;השבתה של מקורות אחרים&#39;, &#39;בדיקות שיוך&#39; ו &#39;יצירת דוחות&#39;.
תהליך שיוך פשוט

פעולות בתהליך שיוך

בטבלה הבאה מפורטות הפעולות השונות שמתבצעות במהלך תהליך השיוך:

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

השלבים הבאים