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

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

כללים מפורטים לנורמליזציה וגיבוב (hashing) מופיעים במאמר פורמט של נתוני משתמשים.

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

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

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

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

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

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

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

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