מדריך חיובים לפלטפורמה של מפות 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 לניידות:

מפתחות 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 מעבר למגבלות שנקבעו מראש (חריגות). המגבלות שלנו תואמות למה שזיהינו באופן כללי כדרישות בשוק.

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

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

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

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

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

לסיכום:

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

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

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

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

דרישות

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

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

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

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

יצירת פרויקט

  1. [אתם] יוצרים פרויקט חדש ב-GCP במסוף Google Cloud לכל סביבה חדשה. לדוגמה, ייצור, Staging ובקרת איכות.
  2. [Partner or Google team] Add new projects to an allowlist to have access to the Mobility products. פונים לנציג המכירות שלכם ב-Google או לשותף של 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: if you need QPM (queries per minutes) uplifts for certain APIs, open a ticket to support. כך עושים זאת. חובה להוסיף הצדקה עסקית שמסבירה למה נדרשת העלאה. אפשר לראות את המכסות המוגדרות מראש כאן.

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

הגדרת חיוב

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

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

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

אימות החיוב

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

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

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

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

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

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

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

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

העברה מוצלחת לסביבת הייצור צריכה להבטיח לא רק שהחיוב פועל בצורה תקינה, אלא גם שממשקי ה-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. בדף Billing (חיוב), לוחצים על סמל האפשרויות הנוספות (3 נקודות) לפתוח את חלונית הפרטים הנוספים ליד אחד מהפרויקטים של הסביבה הפעילה שנוצרו ובוחרים באפשרות Change billing account (שינוי חשבון לחיוב):
    בוחרים את הפרויקט.
  6. בקטע Billing (חיוב) > בחשבון לחיוב, בוחרים את קוד החשבון לחיוב שקיבלתם במכתב הפתיחה מהתפריט הנפתח. לאחר מכן, לוחצים על 'הגדרת חשבון':
    בוחרים את הפרויקט.
  7. הפרויקט יקושר לחשבון החיוב החדש:
    בחירת חשבון החיוב הנכון
    חשוב: מעכשיו, כל הנסיעות או המשימות שמדווחות בפרויקט הזה יחויבו כמו שמוסבר למעלה. אם עדיין לא בוצע אימות של פרטי החיוב, אל תקשרו את החשבון לחיוב.
  8. אחרי שמוסיפים את שיטת החיוב החדשה, עוברים אל 'סקירה כללית > סקירת תשלומים' ואל 'הגדרות תשלומים' כדי לוודא שהפרטים נכונים. מידע נוסף על עדכון החיוב והתשלום זמין בקישור הזה. אם יש לכם בעיות שקשורות לחיוב, אתם יכולים לפתוח פנייה לתמיכה בנושא חיוב או לפנות לשותף או לנציג Google שלכם.

דוחות חיוב

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

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

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

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

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

סיכום

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

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