מדריך חיובים לפלטפורמה של מפות Google וניידות

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

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

מושגים

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

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

חשבונות לחיוב

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

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

אפשר להשתמש בחשבון אחד לחיוב בכמה פרויקטים ב-Google Cloud או רק באחד.

פרויקט בודד שמקושר לאותו חשבון לחיוב:

• תרחיש שימוש ספציפי (למשל, תרחישי שימוש בניידות)
• חשבוניות נפרדות
• ההנחה ניתנת על נפח השימוש בפרויקט היחיד הזה

מספר פרויקטים שמצביעים על אותו חשבון לחיוב:

• אותו תרחיש לדוגמה
• איך נהנים מהנחות על סמך רמות שימוש
• חשבונית אחת

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

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

משאבי Cloud, חשבון לחיוב ויצירת חשבונית

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

מפתחות API

האימות של ממשקי ה-API של הפלטפורמה של מפות Google מתבצע באמצעות מפתח API. ‫Google מזהה את החשבון לחיוב של פרויקט Google Cloud התואם על סמך מפתח ה-API הזה, שבו יתבצע הצריכה.

דוגמה לבקשה אל Geocoding API:

https://maps.googleapis.com/maps/api/geocode/json?place_id=ChIJeRpOeF67j4AR9ydy_PIzPuM&key=YOUR_API_KEY

JWT

חלק מממשקי ה-API דורשים מזהה פרויקט ב-Google Cloud בכתובת ה-URL, ומשתמשים ב-JWT לאימות. לכן חשוב לוודא שהמערכות הנכונות משתמשות בשיטת האימות הנכונה כדי שהחיוב יתבצע בצורה תקינה.

דוגמה לבקשה אל Fleet Engine API:

curl -X GET \ https://fleetengine.googleapis.com/v1/providers/project_id/deliveryVehicles/vehicle-1234 \
  -H 'authorization: Bearer eyJ0eXAiOi...' \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -d '{
    "lastLocation": {
        "location": {
            "latitude": 37.432,
            "longitude": -122.094
        },
        "updateTime": "2022-11-13T17:55:00Z"
    }
}'

עלויות

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

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

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

בסוף החודש תופק חשבונית על סמך (i) מספר הנסיעות או המשימות שהושלמו ודווחו במערכת ו-(ii) כל נפח של קריאות ל-Google Maps Platform API מעבר למגבלות שנקבעו מראש ('חריגות'). המגבלות שלנו תואמות למה שראינו באופן כללי כנדרש בשוק.

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

פיילוטים והערכה

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

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

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

לסיכום:

• שלב הפיילוט או הפיתוח: אתם מחויבים רק על ממשקי ה-API של מפות Google שזמינים לציבור. לא נחייב אתכם על ממשקי API וערכות SDK שלא זמינים לציבור עד שתשתמשו בפרויקט בחשבון לחיוב של Mobility. חשוב לזכור ש-Google מציעה לכל חשבון חדש לחיוב שנוצר נפח שימוש חינמי לכל מק"ט בפלטפורמה של מפות Google. זה אמור להספיק לסביבה מבוקרת במהלך תקופת ההערכה.

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

איך עוברים לחשבון לחיוב של שירותי ניידות

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

דרישות

מישהו מצדכם שיכול:

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

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

הגדרת פרויקט חדש

יצירת פרויקט

1. [אתם] יוצרים פרויקט חדש ב-Google Cloud במסוף Google Cloud לכל סביבה חדשה. לדוגמה, ייצור, Staging ובקרת איכות.
2. [שותף או צוות Google] כדי לקבל גישה למוצרי Mobility, צריך להוסיף פרויקטים חדשים לרשימת ההיתרים. פונים לנציג המכירות שלכם ב-Google או לשותף ומספקים את מזהה הפרויקט שנוצר בשלב הקודם.
3. [אתה] מעדכן את אנשי הקשר החיוניים בפרויקטים שלך. השלב הזה חשוב מאוד כדי להבטיח שצוותי התמיכה של Google יוכלו להגיע לאנשים הנכונים בפרויקט שלכם במקרה הצורך.

הגדרות אישיות של פרויקט

מבצעים את השלבים הבאים במסוף Google Cloud עבור הפרויקט שנוצר בשלבים הקודמים:

1. [אתם] יוצרים חשבונות שירות, כולל שיוך של תפקידי ניהול זהויות והרשאות גישה (IAM) מתאימים ב-Mobility (מבוססי נסיעה ומבוססי משימה)

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

2. [אתם] יוצרים מפתחות API – כמו שנעשה בסביבת הפיתוח או עם הפרדה מובנית יותר של הגישה (למשל, לפי מוצר, דומיין וכו') אם צריך.

3. [אתם] מפעילים ממשקי API כמו Local Rides and Deliveries (נסיעות מקומיות ומשלוחים) וממשקי API אחרים של הפלטפורמה של מפות Google שנדרשים (כלומר, Geocoding (קידוד גאוגרפי), Autocomplete (השלמה אוטומטית), Address Validation (אימות כתובות)).

4. [You] Quota: אם אתם צריכים להגדיל את מכסת השאילתות לדקה (QPM) עבור ממשקי API מסוימים, אתם יכולים לפתוח כרטיס תמיכה. כך עושים את זה. חובה להוסיף הצדקה עסקית שמסבירה למה נדרשת העלאת המגבלה. כאן אפשר לראות את המכסות המוגדרות מראש.

5. [אתם] אם פיתחתם מערכות שהשתמשו בפרטי כניסה מסביבת הפיתוח, אתם צריכים לוודא שהמערכות האלה יכולות להצביע על פרטי הכניסה החדשים שנוצרו עבור הפרויקטים החדשים. זה כולל הפניה של מערכות backend ו-frontend לפרטי הכניסה החדשים, כמו מפתחות API וחשבונות שירות, ולוודא שמזהי הפרויקט הנכונים משמשים בכל סביבה רלוונטית.

הגדרת חיוב

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

1. [אתם] בודקים אם מזהה החשבון לחיוב ב-Mobility התקבל כחלק ממכתב הפתיחה שנשלח מ-Google באימייל אחרי שהחוזה נחתם ובוצע. חשוב: מכתב הפתיחה נשלח לאנשי הקשר הטכניים והפיננסיים שצוינו בטופס ההזמנה של החוזה. כדאי לפנות לצוות הפרויקט כדי להבין מי קיבל את המייל, ולבקש ממנו את המזהה של החשבון לחיוב. המזהה הוא רצף של תווים ומספרים שמופרדים במקף.
2. [אתם] עובדים עם Google או עם שותף כדי לוודא שמתבצע אימות של החיוב – כלומר, המערכות שלכם כבר מדווחות ל-Google על נסיעות או על משימות בצורה תקינה. פרטים נוספים מופיעים בקטע הבא.
3. [אתם] מפנים את הפרויקטים ב-Google Cloud לחשבון החדש לחיוב באמצעות Cloud Console – ראו את הקטע הגדרת חשבון לחיוב בהמשך המסמך הזה.

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

אימות החיוב

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

אימות החיוב כולל את השלבים הבאים:

1. אימות אם לבקשות ל-Google Maps Platform APIs יש tripId (או taskId) בכותרת הבקשה – פרטים נוספים כאן.

2. בודקים אם הנסיעות (או המשימות) מדווחות בצורה תקינה. זה תלוי בחבילת הניידות שבה משתמשים:

   • ‫Mobility Starter ו-Optimize, או Accelerate (לפי נסיעה): נדרש שילוב עם ‫ReportBillableEvent API. כלומר, בכל פעם שנסיעה מסתיימת בהצלחה, צריך לשלוח בקשה ל-API הזה. כדי לוודא שהתהליך מתבצע בצורה תקינה, צריך לפעול לפי השלבים שמתוארים כאן.
   • ‫Mobility Accelerate (Task Based): החיוב לא חייב להיות מופעל על ידי קריאה ל-API. זה קורה באופן אוטומטי כשתוצאת המשימה מוגדרת כ-SUCCEEDED במשימת מסירה. לכן, חשוב מאוד להגדיר את תוצאת המשימה כ-FAILED או כ-SUCCEEDED. מהנדסי לקוחות (שותפים או Google) יעבדו איתכם כדי לוודא שההטמעה בוצעה בצורה תקינה. באמצעות Cloud Logging אפשר לוודא שהמשימות מתעדכנות בצורה תקינה על ידי הפעלת השאילתה הבאה של Cloud Logging:

   resource.type="fleetengine.googleapis.com/DeliveryFleet"
   jsonPayload.@type="type.googleapis.com/maps.fleetengine.delivery.log.v1.UpdateTaskLog"
   jsonPayload.request.task.taskOutcome="TASK_OUTCOME_LOG_SUCCEEDED"
   jsonPayload.response.type="TASK_TYPE_LOG_DELIVERY"
   

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

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

סטטוס תקינות האינטגרציה

העברה מוצלחת לסביבת הייצור צריכה להבטיח לא רק שהחיוב פועל בצורה תקינה, אלא גם שממשקי ה-API לא נכשלים בהרצה. כשמדובר בשירותי ניידות, חשוב לוודא שהשילוב עם Fleet Engine (Local Rides and Deliveries API) בוצע בצורה תקינה.

כדי לעשות זאת, אפשר לפתוח את Cloud Logging ולהשתמש בשאילתה הבאה:

jsonPayload.errorResponse.code:*

בשלב הזה אמורות להופיע כל רשומות היומן שכוללות בעיות. לדוגמה:

אפשר לייצא את הבעיות האלה למוצרים אחרים של Cloud, כמו BigQuery. אפשר להגדיר מדדים והתראות על סמך השאילתה של Cloud Logging:

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

הגדרת חשבון לחיוב

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

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

כדי לעשות זאת:

1. פותחים את מסוף Google Cloud ‏ (https://console.cloud.google.com).
2. בוחרים את הפרויקט החדש שישמש בסביבת הייצור.
3. עוברים לקטע Billing (חיוב) של הפרויקט. אפשר גם להשתמש בקיצור הדרך הזה: https://console.cloud.google.com/billing
4. חיוב > לוחצים על 'ניהול חשבונות לחיוב':

   

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

   

6. בקטע Billing (חיוב) > בחשבון לחיוב, בוחרים את קוד החשבון לחיוב שקיבלתם במכתב הפתיחה מהרשימה הנפתחת. לאחר מכן לוחצים על 'הגדרת החשבון':

   

7. הפרויקט יקושר לחשבון החדש לחיוב:

   

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

דוחות חיוב

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

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

פותחים את החשבון לחיוב שמקושר לפרויקט ובוחרים באפשרות Reports (דוחות). אחר כך תוכלו להשתמש במסננים הבאים:

ההגדרה העיקרית שצריך לזכור היא המסנן Group by לפי מק"ט, שיראה מידע מפורט על Trips ועל Tasks, וגם על ממשקי API אחרים אם נעשה בהם שימוש, כולל אם היו חריגות או לא, כפי שהוסבר קודם:

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

תוכנית להגדלת נפח החשיפה

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

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

חשוב לפעול בהתאם למדיניות ההטמעה:

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

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

לדוגמה, נניח שכל נסיעה או משימה כוללת 10 בקשות לגיאו-קידוד היום, בהתאם למגבלות השימוש. אם ההעברה תימשך כמה חודשים ותתחילו לדווח על 100,000 נסיעות או משימות בחודש הראשון, תוכלו לבצע קריאות ל-Geocoding API מיליון פעמים. אבל אם העסק שלכם שולח 5 מיליון בקשות לגיאו-קידוד, יכול להיות שההפרש (4 מיליון) ידווח כחריגה. יש שתי אפשרויות:

1. אתם מגדילים את מספר הנסיעות או המשימות שאתם מדווחים לנו עליהן (מאיצים את תוכנית ההרחבה), כך שחלות מגבלות גבוהות יותר. במקרה כזה, תצטרכו לדווח על 500,000 נסיעות או משימות בחודש.
2. אפשר לנהל משא ומתן על הגדלת המגבלות במהלך משא ומתן על החוזה, כמו שמוסבר למעלה.
3. כדי ליהנות מרמות הנחה גבוהות יותר ולשלם פחות מאשר על חריגות מהמכסה, צריך להפנות בקשות ל-Geocoding API אל Google Maps Platform API.

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

לסיכום, כדי ליצור תוכנית השקה מתאימה, צריך לבצע את השלבים הבאים: 1. לזהות אילו תרחישים לדוגמה קשורים לניידות ואילו לא, בהתאם למדיניות ההטמעה. 2. לזהות אילו ממשקי API של הפלטפורמה של מפות Google נמצאים בשימוש כיום בתרחישים הרלוונטיים לדוגמה, ואת נפחי השימוש בהם. 3. צריך לבדוק אם עדיין יהיה צורך בממשקי ה-API של הפלטפורמה של מפות Google אחרי הטמעת פתרון הניידות – לדוגמה, חישוב זמן ההגעה המשוער מתבצע באופן אוטומטי ב-Fleet Engine, ולכן יכול להיות שלא תצטרכו יותר לחשב אותו באמצעות Directions API. 4. לזהות כמה זמן ייקח להעביר באופן מלא את תרחישי השימוש בניידות לפלטפורמת הניידות החדשה בצד שלכם. 5. כדאי לבדוק היטב אם מגבלות השימוש מספיקות כדי לתמוך בתרחישי השימוש שלכם. 6. לזהות את נקודת המפנה שבה אפשר להעביר את כל הבקשות של הפלטפורמה של מפות Google לחשבון לחיוב של ניהול ניידות, לתרחישי שימוש בניידות.

סיכום

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

הפעולות הבאות

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