שיטות מומלצות

כשמשתמשים ב-Data Manager API, חשוב לזכור את השיטות המומלצות הבאות.

שליחת כל מזהי המשתמשים

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

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

בקשות לאופטימיזציה

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

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

שליחת בקשות מקבילות

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

אפשר לשלוח בקשות בו-זמנית גם אם יש להן אותו ערך של destinations.

אימות נתונים בצד הלקוח

‫Data Manager API משתמש במודל fast-fail. אם רשומה כלשהי בבקשה נכשלת באימות סינכרוני, הבקשה כולה נכשלת ואף אחת מהרשומות לא מעובדת. בנוסף, ה-API מאמת בקשות בשכבות עוקבות, כך שתיקון שגיאה אחת עשוי לחשוף שגיאה משכבת אימות עוקבת.

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

• הסרת ערכים ריקים לפני הגיבוב: לפני שמחשבים את ערכי ה-SHA-256, בודקים אם יש בשדות כמו email_address ו-phone_number מחרוזות ריקות או מחרוזות שמכילות רק רווחים. גיבוב של מחרוזת ריקה יוצר גיבוב תקין שעובר את בדיקות התחביר, אבל פוגע באחוז הלקוחות לטירגוט.

• השמטת אובייקטים מורכבים לא שלמים: ודאו שהאובייקטים המורכבים כוללים את כל השדות הנדרשים לפני שאתם מוסיפים אותם לרשומה. לדוגמה, אם באובייקט AddressInfo חסר אחד מארבעת השדות הנדרשים (given_name,‏ family_name,‏ region_code או postal_code), צריך להשמיט את כל המזהה address כדי למנוע שגיאות REQUIRED_FIELD_MISSING.

• אימות שדות הקידוד והטקסט הרגיל: מוודאים שהשדות המגובבים תואמים ל-encoding המוצהר, במקום לשלוח טקסט רגיל גולמי, ומוודאים שהשדות שחייבים להישאר כטקסט רגיל (כמו mobile_ids) לא מגובבים.

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

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

• מספרי טלפון נקיים: ודאו שמספרי הטלפון כוללים קוד מדינה ושהם בפורמט E.164 לפני הגיבוב.

• צמצום רשומות ריקות או גדולות מדי: מגבילים את user_identifiers למגבלה לכל רשומה (10 מזהים), מסירים פרמטרים מותאמים אישית ריקים ומשמיטים כל רשומה שלא מכילה מזהים חוקיים.

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

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

כללים מפורטים לנרמול וגיבוב זמינים במאמר פורמט של נתוני משתמשים.

בדיקת הסטטוס והאבחון של הבקשה

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

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

מעקב אחרי מכסות וקבלת התראות

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

פריסה בסביבת הייצור

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

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