עדכונים לגבי הצעות לדיווח על שיוך (Attribution) בינואר 2022

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

למי הפוסט הזה מיועד?

הפוסט הזה מיועד לך:

  • אם אתם כבר מבינים את ה-API – לדוגמה, אם צפיתם בדיונים במאגר של WICG או השתתפתם בהם ואתם רוצים להבין את קבוצת השינויים שבוצעו בהצעה בינואר 2022.
  • אם אתם משתמשים ב-Attribution Reporting API במצגת או בניסוי בסביבת הייצור.

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

מיגרציה בהמשך

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

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

שינויי שמות

דוחות סיכום ודוחות שאפשר לצבור

מה שעשוי להופיע כ'דוחות מצטברים' יקרא מעכשיו דוחות סיכום.

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

שינויים במנגנון ה-API

רישום מקור שמבוסס על כותרת (דוחות ברמת האירוע)

מה עומד להשתנות ומדוע?

כשהמשתמש צופה במודעה או לוחץ עליה, הדפדפן – באופן מקומי במכשיר של המשתמש – מתעד את האירוע הזה, יחד עם פרמטרים ספציפיים לדוחות שיוך (כמו הפרמטרים attributionsourceeventid, ‏ attributiondestination, ‏ attributionexpiry ופרמטרים אחרים). ערכי הפרמטרים האלה מוגדרים על ידי פתרון ה-AdTech.

הדרך שבה הפרמטרים האלה מוגדרים משתנה.

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

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

תרשים של רישום מקור שמבוסס על כותרת

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

איך פועל תהליך הרישום של המקור

  1. עכשיו, כדי להגדיר מודעה מסוימת, פלטפורמת הפרסום צריכה להגדיר מאפיין ספציפי בצד הלקוח בשם attributionsrc. הערך של המאפיין הזה הוא כתובת URL שאליה הדפדפן ישלח בקשה. הבקשה הזו תכלול כותרת HTTP חדשה Attribution-Reporting-Source-Info, שהערך שלה, navigationאו event,, מציין אם המקור היה קליק או צפייה, בהתאמה.
  2. כשהבקשה הזו מתקבלת, שרת המעקב אחר קליקים/צפיות צריך להשיב בכותרת HTTP‏, Attribution-Reporting-Register-Source, שמכילה את פרמטרי השיוך הרצויים.

  3. המקור שמחזיר את הכותרת הזו הוא עכשיו מקור הדיווח (לשעבר attributionreportto).

    כותרת התגובה של HTTP‏ Attribution-Reporting-Register-Source:

    {
  "source_event_id": "267630968326743374",
  "destination": "https://toasters.example",
  "expiry": "604800000"
}

מידע נוסף זמין בהסבר הטכני

רישום מקורות שיוך

הצטרפות לדיון הציבורי

בעיה מס' 261

טריגר שיוך (Attribution) שמבוסס על כותרת (דוחות ברמת האירוע)

מה עומד להשתנות ומדוע?

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

בנוסף, בהצעה החדשה צריך להוסיף את המאפיין attributionsrc בדף ההמרה.

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

שימו לב שבצד המקור – בדרך כלל אתר של בעל תוכן דיגיטלי – יש אמצעי בקרה ברמת הדף באמצעות Permissions-Policy, וגם אמצעי בקרה ברמת הרכיב באמצעות attributionsrc.

איך פועל הטריגר של השיוך

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

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

כותרת התגובה של HTTP‏ Attribution-Reporting-Register-Event-Trigger:

    [{
        trigger_data: (unsigned 3-bit integer),
        trigger_priority: (signed 64-bit integer),
        deduplication_key: (signed 64-bit integer)
    }]

הפניה אוטומטית (אופציונלי)

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

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

פרטים נוספים זמינים במאמר דיווח של צד שלישי.

מידע נוסף זמין בהסבר הטכני

שיוך (Attribution) של טריגרים

הצטרפות לדיון הציבורי

בעיה מס' 91

אין ווירטואל וויט (דוחות שניתן לצבור)

מה עומד להשתנות ומדוע?

בהצעה הקודמת לדוחות שניתן לצבור, נדרשה גישה ל-JavaScript כדי להפעיל וורקלט (worklet) – מנגנון שמבוסס על JavaScript – שייצור את הדוחות האלה.

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

להצעה החדשה יש כמה יתרונות:

  • הטמעה בדפדפנים: העיצוב החדש, בניגוד לעיצוב של רכיבי ה-worklet, פשוט יותר באופן משמעותי כי הוא לא מחייב סביבה חדשה להרצה בדפדפנים.
  • חוויית המשתמש של המפתחים: העיצוב החדש מסתמך על כותרות, שמשמשות מפתחים באופן נרחב ומוכרות להם היטב – בניגוד ל-worklets. הוא גם תואם מאוד לממשק ה-API לרישום מקורות, כך שקל יותר ללמוד את ה-API ולהשתמש בו.
  • אימוץ: העיצוב החדש מאפשר ליותר מערכות מדידה קיימות להשתמש בדוחות שניתן לצבור. פתרונות מדידה רבים הם מסוג HTTP בלבד: הם מסתמכים על בקשות תמונה – בקשות פיקסלים – שלא דורשות גישה ל-JavaScript. עם זאת, בגלל שגישה ל-JavaScript נדרשת לגישה ל-worklet, יכול להיות שהיה קשה לעבור אליו ממערכות מדידה קיימות מסוימות.
  • עמידות: העיצוב החדש עוזר לצמצם את אובדן הנתונים כי קל יותר לשלב אותו עם סמנטיקה של keepalive. לדוגמה, אם קליק או צפייה מתועדים כשמשתמש עוזב דף.

איך פועל המנגנון ללא ווירטואליות?

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

הצטרפות לדיון הציבורי

בעיה מס' 194

רישום מקור שמבוסס על כותרת (דוחות שניתן לצבור)

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

רק שם הכותרת שונה: Attribution-Reporting-Register-Aggregatable-Source.

מידע נוסף זמין בהסבר הטכני

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

טריגר שיוך מבוסס-כותרת (דוחות שניתן לצבור)

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

רק שם הכותרת שונה: Attribution-Reporting-Register-Aggregatable-Trigger-Data.

מידע נוסף זמין בהסבר הטכני

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

תכונות חדשות

דיווח של צד שלישי (דוחות ברמת האירוע ודוחות שניתן לצבור אותם)

מה עומד להשתנות ומדוע?

יש שני היבטים בהצעה החדשה שיעזרו לשפר את התמיכה בתרחישי לדוגמה של דיווח על צד שלישי:

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

איך פועל הדיווח מצד שלישי?

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

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

לכל צד יש גישה לדוחות הנפרדים שלו, והוא יכול להגדיר אותם עם נתונים נפרדים.

רישום של כמה טריגרים בלי הפניות לכתובת אחרת

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

הצטרפות לדיון הציבורי

בעיה מס' 91 בעיה מס' 261

מדידת צפיות (דוחות ברמת האירוע ודוחות שניתן לצבור)

מה עומד להשתנות ומדוע?

בהצעה החדשה, מדידת צפיות ומדידת קליקים פועלות באופן מאוחד:

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

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

איך פועלת המדידה של צפיות

המדידה של צפיות מלא ושל קליקים מלא מבוססת על רישום מבוסס-כותרת.

מידע נוסף זמין בהסבר הטכני

דוחות ברמת האירוע (גם לקליקים וגם לצפיות)

הצטרפות לדיון הציבורי

בעיה מס' 261

ניפוי באגים / ניתוח ביצועים (דוחות ברמת האירוע ודוחות שניתן לצבור)

מה עומד להשתנות ומדוע?

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

תרשים של מערכת ניפוי הבאגים החדשה שמבוססת על קובצי cookie

איך מתבצע ניפוי באגים?

גם ההרשמה של המקור וגם ההרשמה של הטריגר יקבלו פרמטר חדש, debug_key, שהוא מספר שלם ללא סימן באורך 64 ביט (כלומר, מספר גדול).

אם נוצר דוח עם מפתחות ניפוי באגים של מקור וטריגר, ואם קובץ cookie מסוג Samesite=None ar_debug=1 נמצא בקונטיינר של קובצי ה-cookie של מקור הדיווח בזמן הרישום של המקור והטריגר, יישלח דוח ניפוי באגים (JSON) לנקודת קצה מסוג .well-known/attribution-reporting/debug:

{
  "source_debug_key": 1234567890987,
  "trigger_debug_key": 4567654345028
}

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

מידע נוסף זמין בהסבר הטכני

אופציונלי: דוחות ניפוי באגים מורחבים

הצטרפות לדיון הציבורי

בעיה מס' 174

יכולות סינון (דוחות ברמת האירוע ודוחות שניתן לצבור)

מה עומד להשתנות ומדוע?

מאחר שהם תומכים בתרחישי שימוש חשובים בסביבת הפרסום של היום, מספר תרחישי שימוש יהיו נתמכים מעכשיו גם בדוחות ברמת האירוע וגם בדוחות שניתנים לצבירה:

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

איך פועלות יכולות הסינון? (לדוחות ברמת האירוע)

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

  {
    source_event_id: "267630968326743374",
    destination: "https://toasters.example",
    expiry: "604800000"
    source_data: {
      conversion_subdomain: ["electronics.megastore"
                              "electronics2.megastore"],
      product: "198764",
      // Note that "source_type" will be automatically generated as one of {"navigation", "event"}
    }
  }

הרשמה של טריגר תקבל עכשיו כותרת Attribution-Reporting-Filters אופציונלית.

כותרת התגובה של HTTP‏ Attribution-Reporting-Filters:

{
  "conversion_subdomain": "electronics.megastore",
  "directory": "/store/electronics"
}

לחלופין, אפשר להרחיב את הכותרת Attribution-Reporting-Register-Event-Trigger באמצעות השדה filters כדי לבצע סינון סלקטיבי ולהגדיר את trigger_data על סמך source_data.

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

מידע נוסף זמין בהסבר הטכני

מסנני שיוך (Attribution) אופציונליים

הצטרפות לדיון הציבורי

בעיה מס' 194
בעיה מס' 201

שינויים בהגדרות של הגנה על הפרטיות

רעשים ושקיפות (דוחות ברמת האירוע ודוחות נצברים)

מה עומד להשתנות ומדוע?

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

לשיטה החדשה הזו יש כמה יתרונות:

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

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

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

יש לכך שני יתרונות עיקריים:

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

איך פועל הרעש?

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

הפלט המזויף יכול להיות:

  • ללא דוח בכלל – ללא קשר לכך שהמשתמש ביצע המרה.
  • דוח אחד או כמה דוחות מזויפים – ללא קשר לכך שהמשתמש השלים המרה.

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

בדומה לדוחות אמיתיים, דוחות מזויפים לא נשלחים מיד אחרי שהמשתמש משלים המרה. הם נשלחים בסוף חלון דיווח אקראי.

יש שלושה חלונות דיווח על קליקים (יומיים, 7 ימים או 30 יום אחרי הקליק). כל דוח מזויף מוקצה באופן אקראי לאחד מחלונות הדיווח.

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

מידע נוסף זמין בהסבר הטכני

דוגמאות להמרות מזויפות עם רעש

הצטרפות לדיון הציבורי

בעיה מס' 84
בעיה מס' 273

מגבלות דיווח (דוחות ברמת האירוע ודוחות שניתן לצבור)

מגבלות על מקורות דיווח

מה עומד להשתנות ומדוע?

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

  • אנחנו מציעים להגביל את המספר המקסימלי של מקורות דיווח ייחודיים (בדרך כלל פלטפורמות טכנולוגיות פרסום) שיכולים לרשום מקורות לכל {בעל תוכן דיגיטלי, מפרסם} ל-100 לכל 30 יום. המונה הזה יגדל בכל קליק על מודעה או צפייה במודעה (אירוע מקור), גם אם הם לא משויכים.
  • אנחנו מציעים להגביל את המספר המקסימלי של מקורות דיווח ייחודיים (בדרך כלל פלטפורמות טכנולוגיות פרסום) שיכולים לשלוח דוחות לכל {בעל תוכן דיגיטלי, מפרסם} ל-10 בכל 30 יום. המונה הזה יגדל בכל המרה שמשויכת למקור תנועה.

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

דיווח על תקופות צינון / מגבלות קצב

מה עומד להשתנות ומדוע?

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

בהצעה החדשה, אפשר לתזמן 100 דוחות לכל {source site, destination, reporting origin} (בדרך כלל {publisher, advertiser, adtech}) במהלך 30 ימים.

מעבר למגבלה הזו, הדפדפן יפסיק לתזמן דוחות שתואמים ל-{source site, destination, reporting origin} הזה (בדרך כלל {publisher, advertiser, adtech}) – עד שמספר הדוחות המצטבר ב-30 הימים האחרונים יירד מתחת ל-100 עבור ה-{source site, destination, reporting origin} הזה.

מידע נוסף זמין בהסבר הטכני

תקופת צינון לדיווח / מגבלות קצב

הגבלת יעד להמרות (דוחות ברמת האירוע בלבד)

מה עומד להשתנות ומדוע?

מגבלת היעד משתנה כך שתכלול את מקור הדיווח (בדרך כלל חברת טכנולוגיית פרסום) בהיקף: 100 יעדים ייחודיים בהמתנה (בדרך כלל אתרים של מפרסמים או אתרים שבהם צפויות להתרחש המרות) לכל {publisher, adtech}.

זוהי הגנה על הפרטיות שמטרתה להגביל את שחזור היסטוריית הגלישה.

מידע נוסף זמין בהסבר הטכני

הגבלת מספר היעדים הייחודיים שמכסים מקורות בהמתנה

כל המשאבים

תמונת הכותרת היא של Diana Polekhina ב-Unsplash.