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

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

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

מושגים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לסיכום:

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

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

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

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

דרישות

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

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

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

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

יצירת פרויקט

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

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

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

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

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

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

  3. [עליך] להפעיל ממשקי API כמו 'נסיעות מקומיות ושליחויות' וממשקי API אחרים של פלטפורמת מפות Google שנדרשים (למשל, קידוד גיאוגרפי, מילוי אוטומטי, אימות כתובות).

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

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

הגדרת חיוב

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

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

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

אימות החיוב

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

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

  1. כאן מוסבר איך בודקים אם בקשות שנשלחות לממשקי ה-API של הפלטפורמה של מפות Google כוללות מזהה TriId (או מזהה משימה) בכותרת הבקשה.

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

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

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

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

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

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

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

jsonPayload.errorResponse.code:*

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

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

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

דוחות חיוב

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

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

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

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

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

המסננים של דוח החיוב
דוגמה למוצרים שנעשה בהם שימוש בפרויקט

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

תוכנית הגדלה

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

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

חשוב שתצייתו למדיניות ההטמעה:

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

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

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

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

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

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

סיכום

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

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