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

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

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

מושגים

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

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

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

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

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

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

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

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

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

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

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

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

הגדרות אפשריות של חשבון לחיוב
הגדרות אפשריות של חשבון לחיוב

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

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

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

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

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

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

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

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

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

לסיכום:

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

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

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

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

דרישות

אדם בצד שלכם שיכול:

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

בהמשך אנחנו מציגים את השלבים הנדרשים להגדרת פרויקט חדש ואיך להגדיר את החיוב בפרויקטים החדשים האלה.

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

יצירת פרויקטים

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

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

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

  1. [אתם] יצירת חשבונות שירות, כולל שיוך של תפקידים נכונים של ניהול זיהוי וניידות (IAM) (מבוססים על נסיעה ומבוססי-משימה) – כפי שנעשה בסביבת הפיתוח או עם הפרדת גישה מובנית יותר במקרה הצורך – ניתן לעיין בקטע הזה.
  2. [אתם] יצירת מפתחות API – כפי שנעשה בסביבת הפיתוח או באמצעות הפרדה מובנית יותר של הגישה (למשל, לפי מוצר, דומיין וכו') לפי הצורך.
  3. [אתם] מפעילים ממשקי API כמו "נסיעות ומשלוחים מקומיים" וממשקי API אחרים של הפלטפורמה של מפות Google שנחוצים (כלומר, קידוד גיאוגרפי, השלמה אוטומטית, אימות כתובות).
  4. [You] מכסה: אם אתם זקוקים לשיפורים ב-QPS (שאילתות לשנייה) עבור ממשקי API מסוימים, אפשר לפתוח פנייה לתמיכה. כאן מוסבר איך לעשות את זה. חובה להוסיף נימוק עסקי שמציין למה יש צורך בהגדלה. כאן אפשר לראות את המכסות המוגדרות מראש.
  5. [אתם] אם פיתחתם מערכות שהשתמשו בפרטי כניסה מסביבת הפיתוח, עליכם לוודא שהמערכות האלה יכולות להצביע על פרטי הכניסה החדשים שנוצרו לפרויקטים החדשים שנוצרו. זה כולל הפניית מערכות עורפיות וממשקי קצה לפרטי הכניסה החדשים כמו מפתחות API וחשבונות שירות, ובדיקה האם נעשה שימוש במזהי הפרויקטים הנכונים בכל סביבה.

הגדרת חיוב

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

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

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

אימות חיוב

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

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

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

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

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

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

יצירת מדד משאילתה ב-Cloud Logging
יצירת מדד משאילתה ב-Cloud Logging

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

הגדרת חשבון לחיוב

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

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

לשם כך:

  1. פותחים את Google Cloud Console (https://console.cloud.google.com).
  2. בוחרים את הפרויקט החדש שישמש בסביבת הייצור.
  3. עוברים לקטע 'חיוב' בפרויקט. קיצור דרך יכול לגשת לקישור הזה: https://console.cloud.google.com/billing
  4. חיוב > לוחצים על "ניהול חשבונות לחיוב":
    חשבונות מרובים לחיוב
    ייתכן שהפרויקט ייראה שונה מהפרויקט שלמעלה.
  5. בקטע Billing > לוחצים על סמל התפריט (3 נקודות) פתיחת פרטים נוספים לצד הפרויקט שנוצר בסביבת הייצור ובוחרים באפשרות Change billing account (שינוי החשבון לחיוב):
    בוחרים את הפרויקט.
  6. חיוב > בחשבון לחיוב, בוחרים ברשימה הנפתחת את קוד החשבון לחיוב שקיבלתם במכתב הפתיחה. לאחר מכן לוחצים על 'הגדרת חשבון':
    בוחרים את הפרויקט.
  7. הפרויקט יקושר לחשבון החדש לחיוב:
    בחירת החשבון הנכון לחיוב
    חשוב: מעכשיו והלאה, כל הנסיעות או המשימות שדווחו בפרויקט הזה יחויבו לפי הסבר שהוסבר קודם. אם אימות החיוב עדיין לא בוצע, אל תקשרו עדיין את החשבון לחיוב.
  8. לאחר הוספת אמצעי החיוב החדש, עוברים אל 'סקירה כללית > סקירה כללית על תשלומים' ואל 'הגדרות תשלום' כדי לוודא שהמידע נכון. מידע נוסף על עדכון של החיוב והתשלומים זמין בקישור הזה.
    בכל בעיה הקשורה לחיוב, אפשר להגיש billing בנושא חיוב או לפנות לנציג השותף או לנציג של Google.

דוחות חיוב

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

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

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

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

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

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

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

הגדלת התוכנית

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

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

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

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

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

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

סיכום

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

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