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

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

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

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

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

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

<img "activewear"="" "attribution="" "casualwear"="" "casualwear",="" "outerwear"="" "outerwear".="" "outerwear"."="" #1".the="" 1.="" 2.="" alt="An image showing 4 boxes labelled sources numbered 1 through 4 and a single box labelled " and="" attributes="" filter:="" first="" following="" fourth="" has="" priority:="" scope":="" second="" source="" src="/static/assets/images/attribution-scopes-example-1.png" the="" third="" title="Example on how attribution works with attribution scopes and filters" trigger="" />

לפני השיוך

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

במהלך השיוך

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

שיוך לפוסט

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

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

במהלך השיוך

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

שיוך לפוסט

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

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

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

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

<img "attribution="" "attribution",="" "deactivation="" "filters="" "report="" "source="" "trigger="" alt="תמונה שמציגה גרסה פשוטה של תהליך השיוך, שבו כל שלב מיוצג כריבוע שמקושר לשלב הבא באמצעות חץ. השלבים בסדר הם " and="" check",="" checks"="" generation"."="" matching",="" of="" other="" registration",="" scopes="" source="" sources",="" src="/static/assets/images/attribution-scopes-attribution-flow.png" title="Simplified attribution flow diagram" />

פעולות בתהליך השיוך (Attribution)

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

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

השלבים הבאים

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