מדריך לחיובי ניידות

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

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

מושגים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מפתחות API

ממשקי API של Google Maps Platform מאומתים באמצעות מפתח 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 Maps Platform ללא עלות, כל עוד אתם עומדים במגבלות שהוגדרו מראש באותו תרחיש שימוש של שירותי תחבורה.

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

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

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

תוכניות פיילוט והערכה

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

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

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

לסיכום:

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

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

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

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

דרישות

אדם מטעמכם שיכול:

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

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

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

יצירת פרויקט

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

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

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

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

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

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

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

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

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

הגדרת חיוב

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

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

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

אימות החיוב

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

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

1. אימות אם לבקשות ל-API של הפלטפורמה של מפות Google יש 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 (חיוב), ברשימה הנפתחת Billing account (חשבון לחיוב), בוחרים את קוד החשבון לחיוב שקיבלתם במכתב הפתיחה. לאחר מכן לוחצים על 'הגדרת החשבון':

   

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

   

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

דוחות חיוב

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

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

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

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

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

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

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

בנוסף, במקרים רבים, לא כל התנועה תהיה שייכת לתרחיש לדוגמה של ניידות, כמו במקרה של איתור חנויות, איסוף מהחנות ופתרונות פנימיים אחרים. הם צריכים להצביע על חשבון לחיוב ב-Google Maps Platform, כי התנועה שם צריכה להיות נפרדת מהחשבון לחיוב של 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 Maps Platform שבהם נעשה שימוש כיום בתרחישי השימוש הרלוונטיים, והיקפי השימוש בהם. 3. כדאי לבדוק אם עדיין יהיה צורך בממשקי ה-API של הפלטפורמה של מפות Google אחרי הטמעת פתרון הניידות – לדוגמה, חישוב משוער של זמן ההגעה מתבצע באופן אוטומטי ב-Fleet Engine, ולכן יכול להיות שלא תצטרכו יותר לחשב אותו באמצעות Directions API. 4. לזהות כמה זמן ייקח להעביר באופן מלא את תרחישי השימוש בניידות לפלטפורמת הניידות החדשה בצד שלכם. 5. כדאי לבדוק היטב אם מגבלות השימוש מספיקות לתרחישי השימוש שלכם. 6. צריך לזהות את נקודת המפנה שבה אפשר להעביר את כל הבקשות של Google Maps Platform לחשבון לחיוב של ניידות, לתרחישי שימוש בניידות.

סיכום

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

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

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