דוגמאות לחישובים של חלוקת הכנסות ב-Google Cloud Marketplace

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

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

תרחיש 1

ספק תוכנה עצמאי (ISV) בשם Example ISV יוצר ומפרסם מבצע פרטי ללקוח שלו, Cymbal Fintech, בתאריך 21 באפריל 2025 או אחריו.

לצורך הדוגמה הזו, נניח את הפרטים הבאים:

• ההזמנה צפויה להתחיל ב-1 ביולי 2025.
• ההזמנה לא מוגדרת לחידוש אוטומטי בסוף התקופה.
• הערך של השדה 'סוג המבצע' בהזמנה הוא new.

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

• תשלום ראשון: 1,000,000$, לתשלום ב-1 ביולי 2025.
• תשלום מס' 2: 1,500,000$, לתשלום ב-1 ביולי 2026.
• תשלום #3: 1,750,000$, לתשלום ב-1 ביולי 2027.

ערך החוזה הכולל (TCV) של המבצע הזה מוצג במבצעים פרטיים כ-4,250,000$.

במקרה כזה, אחוז חלוקת ההכנסות שחל על כל תשלום בעסקה הזו הוא 98%.

תרחיש 1.1

הדוגמה הבאה היא המשך של תרחיש 1.

ב-1 בפברואר 2028, חברת Cymbal Fintech פונה אל Example ISV כדי לברר אם אפשר לחדש את העסקה בתנאים זהים לעסקה המקורית. מכיוון שהחידוש האוטומטי לא הופעל, לחברת ISV לדוגמה יש שתי אפשרויות כדי לוודא שהיא תקבל את אחוז חלוקת ההכנסות מהחידוש של 98.5% כשהעסקה תתחדש:

אפשרות א'

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

• מוסיפים עוד שלוש תשלומים, עם מבנה התשלומים הבא:
  • תשלום 4: 1,000,000$, לתשלום ב-1 ביולי 2028.
  • תשלום 5: 1,500,000$, לתשלום ב-1 ביולי 2029.
  • תשלום מס' 6: 1,750,000$, לתשלום ב-1 ביולי 2030.
• משנים את הערך של השדה 'סוג המבצע' מ-new ל-native renewal.

חלוקת ההכנסות שחלה על שלושת התשלומים החדשים מהעסקה המתוקנת הזו היא 98.5%.

אפשרות ב'

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

חלוקת ההכנסות שחלה על שלושת התשלומים של העסקה החדשה הזו היא 98.5%.

תרחיש 1.2

הדוגמה הבאה היא המשך של תרחיש 1.

בתרחיש הזה, אחרי התשלום השני, חברת Cymbal Fintech מבקשת להרחיב את העסקה, והתשלומים העתידיים מובנים באופן הבא:

• תשלום #3:‏ 2,500,000$, לתשלום ב-1 ביולי 2027.
• תשלום מס' 4: 2,500,000$, לתשלום ב-1 ביולי 2028.
• תשלום #5: 2,500,000$, לתשלום ב-1 ביולי 2029.
• תשלום 6: 2,500,000$, לתשלום ב-1 ביולי 2030.

ערך החוזה הכולל (TCV) של העסקה הזו מוצג עכשיו במבצעים פרטיים כ-14,250,000$.

הערך הכולל של החוזה (TCV) של התיקון גדל ביותר מ-60%, וכך גם משך הזמן, ולכן ספק התוכנה העצמאי (ISV) לדוגמה עומד בדרישות לחלוקת רווחים לפי שיעור החידוש. כדי לוודא שהם יקבלו את חלקם בהכנסות מחידוש המינוי על כל התשלומים הקרובים, הם צריכים להגדיר את הערך של השדה 'סוג העסקה' ל-native renewal.

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

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

תרחיש 1.2.1

הדוגמה הבאה היא המשך של תרחיש 1.2.

בתרחיש הזה, המבצע הפרטי מסתיים ב-30 ביוני 2031, וחברת Cymbal Fintech ממשיכה להשתמש במוצר, ועוברת לתמחור לפי שימוש בלבד.

חלוקת ההכנסות שחלה על השימוש של Cymbal Fintech אחרי שההצעה הפרטית הסתיימה היא 97%.

תרחיש 1.2.1.1

הדוגמה הבאה היא המשך של תרחיש 1.2.1.

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

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

הערה: אם המבצע החדש נוצר יותר מ-90 ימים אחרי שהמבצע הקודם הסתיים, הוא לא עומד בדרישות לשיתוף הכנסות מחידוש המינוי, וספק ה-ISV צריך להגדיר את הערך של שדה סוג העסקה כ-new. ‫Cloud Marketplace שומר לעצמו את הזכות לבצע התאמות לפי הצורך במקרים כאלה.

תרחיש 2.0

ספק תוכנה עצמאי (ISV) בשם Example ISV יוצר ומפרסם מבצע פרטי ללקוח שלו, Cymbal Fintech, לפני 21 באפריל 2025.

לצורך הדוגמה הזו, נניח את הפרטים הבאים:

• ההזמנה התחילה ב-1 ביולי 2024.
• ההזמנה לא מוגדרת לחידוש אוטומטי בסוף התקופה.

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

• תשלום ראשון: 1,000,000$, לתשלום ב-1 ביולי 2024.
• תשלום #2: 1,500,000$, לתשלום ב-1 ביולי 2025.
• תשלום מס' 3: 1,750,000$, לתשלום ב-1 ביולי 2026.

ערך החוזה הכולל (TCV) של המבצע הזה מוצג במבצעים פרטיים כ-4,250,000$.

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

תרחיש 2.1

הדוגמה הבאה היא המשך של תרחיש 2.0.

בתרחיש הזה, ב-1 בפברואר 2027, חברת Cymbal Fintech פונה אל Example ISV ושואלת אם אפשר לחדש את העסקה בתנאים זהים לאלה של העסקה המקורית. מכיוון שהתשלומים החדשים הם חלק מתקופת חידוש, חברת ISV לדוגמה זכאית לחלוקת רווחים לפי שיעור החידוש. מכיוון שהחידוש האוטומטי לא הופעל, לחברת התוכנה העצמאית (ISV) יש שתי אפשרויות כדי לוודא שהיא תקבל את אחוז חלוקת ההכנסות מהחידוש של 98.5% כשהעסקה תחודש:

אפשרות א'

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

• מוסיפים עוד שלוש תשלומים, עם מבנה התשלומים הבא:
  • תשלום 4: 1,000,000$, לתשלום ב-1 ביולי 2027.
  • תשלום מס' 5: 1,500,000$, לתשלום ב-1 ביולי 2028.
  • תשלום #6: 1,750,000$, לתשלום ב-1 ביולי 2029.
• משנים את הערך של השדה 'סוג המבצע' מ-new ל-native renewal.

חלוקת ההכנסות שחלה על שלושת התשלומים החדשים מהעסקה המתוקנת הזו היא 98.5%.

אפשרות ב'

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

חלוקת ההכנסות שחלה על שלושת התשלומים של העסקה החדשה הזו היא 98.5%.

תרחיש 2.2

הדוגמה הבאה היא המשך של תרחיש 2.0.

בתרחיש הזה, אחרי התשלום השני, חברת Cymbal Fintech מבקשת להרחיב את העסקה, והתשלומים העתידיים מובנים באופן הבא:

• תשלום #3: 2,500,000$, לתשלום ב-1 ביולי 2026.
• תשלום מס' 4: 2,500,000$, לתשלום ב-1 ביולי 2027.
• תשלום מס' 5: 2,500,000$, לתשלום ב-1 ביולי 2028.
• תשלום #6: 2,500,000$, לתשלום ב-1 ביולי 2029.

ערך החוזה הכולל (TCV) של העסקה הזו מוצג עכשיו במבצעים פרטיים כ-14,250,000$.

הערך הכולל של החוזה (TCV) של התיקון גדל ביותר מ-60%, וכך גם משך החוזה, ולכן ספק התוכנה לדוגמה זכאי לחלוקת הכנסות לפי שיעור החידוש. כדי לוודא שהם יקבלו את חלוקת ההכנסות על חידוש המינוי על כל התשלומים הקרובים, הם צריכים להגדיר את הערך של השדה 'סוג העסקה' ל-native renewal.

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

פתרון בעיות בחישובים של חלוקת הכנסות

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

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

למה הערך של השדה 'סוג העסקה' הוא new בכל המבצעים שנוצרו מתוכנית המבצע הפרטי שלי למפיץ עם כמה שימושים? בתוכניות של מבצעים פרטיים למפיצים עם שימוש רב, ערך ברירת המחדל של השדה deal type (סוג העסקה) הוא new. כדי לציין ערך אחר, כמו native renewal,‏ channel shift או migration, צריך להשתמש בתוכנית של מבצע פרטי למפיץ לשימוש חד-פעמי. מידע נוסף על תוכניות מבצעים פרטיות למפיצים זמין במאמר הגדרת תוכניות מבצעים פרטיות למפיצים.