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

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

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

מושגים

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

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

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

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

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

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

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

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

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

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

לסיכום:

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

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

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

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

דרישות

אדם מצוות העבודה שלכם שיכול:

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

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

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

יצירת פרויקט

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

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

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

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

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

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

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

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

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

הגדרת חיוב

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

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

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

אימות החיוב

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

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

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

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

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

דוחות חיוב

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סיכום

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

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