הסבר על מודל הגישה של Google Ads

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

אתם יכולים להעניק גישה לחשבונות Google Ads למשתמשים פרטיים או לחשבונות שירות. יש שתי דרכים לתת למשתמשים גישה לחשבון מפרסם:

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

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

נבחן את היררכיית החשבונות הבאה. נניח שלכל המשתמשים יש גישה רגילה.

בטבלה הבאה מופיע סיכום של מבנה החשבון הזה.

משתמש	יש גישה ישירה אל	יש גישה עקיפה אל
U1, SA1	M1	M2, A1, A2, A3
U2	M2, ‏ M3	A1, ‏ A2, ‏ A3, ‏ A4
U3	A4

מספר הלקוח להתחברות

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

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

משתמש	מספר הלקוח שמשמש לכניסה	חשבונות לביצוע קריאות ל-API
U1, SA1	M1	M1, M2, A1, A2, A3
U2	M2	M2, A1, A2, A3
U2	M3	M3, ‏ A1, ‏ A4
U3	A4	A4

אפשר לדלג על הוספת הכותרת login-customer-id אם למשתמש יש גישה ישירה לחשבון Google Ads שאליו מתבצעות הקריאות. לדוגמה, לא צריך לציין את הכותרת login-customer-id כשמשתמשים בפרטי הכניסה U3 כדי לבצע קריאה אל A4, כי שרתי Google Ads יכולים לקבוע בצורה נכונה את רמת הגישה ממזהה הלקוח (A4).

אם אתם משתמשים באחת מספריות הלקוח שלנו, אתם יכולים להשתמש בהגדרות הבאות כדי לציין את הכותרת login-customer-id.

Java

מוסיפים את ההגדרה הבאה לקובץ ads.properties.

api.googleads.loginCustomerId=INSERT_LOGIN_CUSTOMER_ID_HERE

C#‎

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

GoogleAdsConfig config = new GoogleAdsConfig()
{
    ...
    LoginCustomerId = ******
};
GoogleAdsClient client = new GoogleAdsClient(config);

PHP

מוסיפים את ההגדרה הבאה לקובץ google_ads_php.ini.

[GOOGLE_ADS]
loginCustomerId = "INSERT_LOGIN_CUSTOMER_ID_HERE"

Python

מוסיפים את ההגדרה הבאה לקובץ google-ads.yaml.

login_customer_id: INSERT_LOGIN_CUSTOMER_ID_HERE

Ruby

מוסיפים את ההגדרה הבאה לקובץ google_ads_config.rb.

Google::Ads::GoogleAds::Config.new do |c|
  c.login_customer_id = 'INSERT_LOGIN_CUSTOMER_ID_HERE'
end

יוצרים מופע GoogleAdsClient על ידי העברת הנתיב למיקום שבו שומרים את הקובץ הזה.

client = Google::Ads::GoogleAds::GoogleAdsClient.new('path/to/google_ads_config.rb')

Perl

מוסיפים את ההגדרה הבאה לקובץ googleads.properties.

loginCustomerId=INSERT_LOGIN_CUSTOMER_ID_HERE

curl

מציינים את הארגומנט הבא בשורת הפקודה כשמריצים את הפקודה curl.

-H "login-customer-id: LOGIN_CUSTOMER_ID"

תפקידי משתמשים

ל-Google Ads API אין מודל גישה נפרד משלו, והוא לא משתמש בהיקפי הרשאות נפרדים של OAuth 2.0 כדי להגביל את הפונקציונליות. לדוגמה, ב-Google Ads API נעשה שימוש באותם היקפי הרשאות לפעולות לקריאה בלבד ולפעולות לקריאה וכתיבה. במקום זאת, Google Ads API פועל לפי אותם תפקידי משתמש שנתמכים ב-Google Ads. כשמקצים תפקיד משתמש לחשבון ברמת חשבון הניהול, החשבונות בהיררכיה יורשים את התפקיד. אם למשתמש יש תפקידים סותרים בחשבון מסוים, הרמה הנכונה נקבעת לפי חשבון login-customer-id שצוין בבקשת ה-API.

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

משתמש	תפקיד המשתמש הוענק	login-customer-id	רמת הגישה בפועל
SA1	הרשאת גישה רגילה בחשבון M1	M1	הרשאת גישה רגילה בחשבונות M1,‏ M2,‏ A1,‏ A2 ו-A3
U2	הרשאת גישה רגילה ב-M2 גישה לקריאה בלבד ב-M3	M2	הרשאת גישה רגילה ב-M2, ‏ A1, ‏ A2, ‏ A3
U2	הרשאת גישה רגילה ב-M2 גישה לקריאה בלבד ב-M3	M3	גישה לקריאה בלבד ב-M3,‏ A1 ו-A4