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

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

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

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

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

סטטוס תקינות השילוב

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

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

jsonPayload.errorResponse.code:*

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

שאילתות לגבי שגיאות באמצעות Cloud Logging
שאילתות לגבי שגיאות באמצעות Cloud Logging

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

יצירת מדד משאילתה ב-Cloud Logging
יצירת מדד משאילתה של 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 (דוחות). אחר כך תוכלו להשתמש במסננים הבאים:

מסננים של דוחות חיוב
פילטרים של דוחות חיוב

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

סיכום

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

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