İzləmə API-si üzrə qiymət modelləri izah edilir: çağırış başına və göndəriş başına ödəniş və real xərci necə hesablamaq olar
Çağrı başına izləmə API-si üzrə qiymət ödənişli sorğulara görə, göndəriş başına qiymət isə müəyyən edilmiş izləmə vahidinə, məsələn, qeydiyyatdan keçmiş izləmə nömrəsinə görə hesablanır. Bunlardan heç biri avtomatik olaraq daha ucuz deyil. Real xərci qiymətləndirmək üçün hər iki modeli eyni göndəriş həcmi, yeniləmə tələbləri, izləmə müddəti və hesablaşma qaydaları əsasında müqayisə edin, sonra platforma haqlarını, artıq istifadə ödənişlərini və inteqrasiya xərclərini əlavə edin.
Mühəndislik, əməliyyat və satınalma komandaları üçün faydalı müqayisə sadəcə çağrı başına qiymət ilə göndəriş başına qiymət arasında deyil. Məsələ biznesinizin ehtiyac duyduğu göndəriş görünürlüğünü təmin etməyin ümumi xərcidir. Aşağı sorğu tezliyi tez-tez sorğulama zamanı baha başa gələ bilər, aşağı göndəriş sayı isə izləmə müddəti və ya daxil edilmiş xidmətlər iş prosesinizə uyğun gəlmədikdə yanıltıcı ola bilər.
Hər bir qiymət modeli əslində nəyi ölçür
İlk addım üç anlayışı ayırmaqdır: API sorğusu, göndərişin qeydiyyatı və izləmə yeniləməsi. Bunlar fərqli hadisələrdir və müqavilə onların hər biri üçün fərqli hesablaşma qaydası müəyyən edə bilər.
| Müqayisə nöqtəsi | Çağrı başına qiymət | Göndəriş başına qiymət |
|---|---|---|
| Hesablaşma əsası | Ödənişli olaraq müəyyən edilmiş sorğular və ya sorğu vahidləri | Ödənişli olaraq müəyyən edilmiş göndəriş vahidləri |
| Əsas xərc amili | Tətbiqin ödənişli sorğuları nə qədər tez-tez göndərməsi | Əhatə dairəsinə neçə ödənişli izləmə vahidinin daxil olması və ya orada qalması |
| Həll edilməli hesablaşma sualı | Hansı endpoint-lər, cavablar və paket elementləri hesablanır? | Bir göndərişi nə müəyyən edir və izləmə nə qədər müddətə daxil edilir? |
| Potensial xərc riski | Təkrar sorğulama, yenidən cəhdlər və lazımsız axtarışlar | Təkrar qeydiyyatlar, çoxsaylı bağlamalar və izləmə müddəti məhdudiyyətləri |
| Ən uyğun şərti istifadə sahəsi | Nəzarət olunan sorğu həcmi ilə az tezlikli axtarışlar | Yeniləmələrin göndəriş haqqına daxil olduğu davamlı monitorinq |
Çağrı başına qiymət mütləq hər HTTP sorğusunun eyni başa gəlməsi demək deyil
Qiymət təklifi ödənişli endpoint-ləri və onların vahidlərini göstərməlidir. İzləmə nömrəsinin qeydiyyatı, saxlanılmış nəticələrin əldə edilməsi, yeniləmə sorğusu və abunəliklərin idarə edilməsi fərqli qaydada hesablanma bilər. Uğursuz sorğunun pulsuz olduğunu və ya uğurlu sorğunun həmişə ödənişli olduğunu düşünməyin.
Paket sorğuları da açıq şəkildə müəyyən edilməlidir. 100 izləmə nömrəsi olan bir sorğu bir sorğu, 100 izləmə vahidi və ya müqavilədə göstərilən başqa bir miqdar kimi hesablan bilər. Şəbəkə trafikini azaltmaq, ölçmə qaydaları bunu dəstəkləmədiyi halda, hesablaşmada qənaət demək deyil.
Göndəriş başına qiymət mütləq sifariş başına qiymət demək deyil
E-ticarət sifarişi bir neçə bağlama yarada bilər. Ödənişli vahid izləmə nömrəsidirsə, bölünmüş sifariş bir neçə vahid sərf edə bilər. Qaytarmalar, əvəzləyici göndərişlər və daşıyıcılar arasında təhvil dəqiq qaydada müəyyən edilməlidir.
Haqqın müəyyən edilmiş müddət ərzində, müəyyən edilmiş tamamlanma hadisəsinə qədər və ya başqa bir məhdudiyyət çərçivəsində izləməni əhatə edib-etmədiyini soruşun. Həmçinin əvvəlcədən qeydiyyatdan keçmiş göndərişlərin sonrakı hesablaşma dövründə yeni ödəniş yaradıb-yaratmadığını müəyyən edin. Bu detallar qiymət planının adından daha vacibdir.
Xərci yalnız sifariş sayına görə deyil, iş prosesinizə əsasən qiymətləndirin
Nümunəvi əməliyyat dövründən istifadə edin və göndəriş səviyyəsindəki məlumatlar əsasında proqnoz hazırlayın. Həm yeni göndərişləri, həm də hələ də monitorinq tələb edən köhnə göndərişləri daxil edin. Məlumatlarınız tam deyilsə, nəticəni dəqiq qiymət təklifi kimi təqdim etməkdənsə, fərziyyələri açıq göstərin.
- İzlənə bilən bağlamaları sayın. Kassa sifarişlərindən deyil, unikal bağlama izləmə vahidlərindən başlayın. Hesablaşma qaydaları təsdiqlənənə qədər göndərilən bağlamaları, qaytarmaları və əvəzləmələri ayrı saxlayın.
- Monitorinq müddətini ölçün. Lazım gəldikdə tranzitdən əvvəlki və istisna dövrləri də daxil olmaqla, hər göndərişin nə qədər müddət yeniləməyə ehtiyacı olduğunu qiymətləndirin.
- Tələb olunan yeniləmə tezliyini müəyyən edin. Tətbiqinizin yeni məlumata nə qədər tez-tez ehtiyac duyduğunu və bunun göndəriş statusuna görə dəyişib-dəyişmədiyini göstərin.
- API iş prosesini xəritələndirin. İnteqrasiyanızın istifadə edəcəyi qeydiyyatları, nəticə axtarışlarını, yeniləmə sorğularını, düzəlişləri, təkrar cəhdləri və digər endpoint-ləri sadalayın.
- Hesablaşma qaydalarını tətbiq edin. Təklif olunan müqavilədən istifadə edərək texniki fəaliyyəti ödənişli çağrılara və ya göndəriş vahidlərinə çevirin.
- İstifadədən kənar ödənişləri əlavə edin. Tətbiq olunan abunə haqqını, minimum öhdəliyi, əlavə xidmətləri və tətbiqetmə və ya əməliyyat xərclərini daxil edin.
Hər axtarış üçün bir izləmə nömrəsi olan sadə sorğulama inteqrasiyası üçün ilkin qiymətləndirmə belədir:
Axtarış sorğuları = monitorinq edilən göndərişlər × orta monitorinq günləri × gündəlik axtarışlar
Bu qısa düstur hər göndərişin eyni orta cədvələ uyğun olduğunu fərz edir. Daha dəqiq model hər göndəriş və ya göndəriş qrupu üzrə sorğuları toplayır, sonra qeydiyyat çağrılarını və digər ödənişli fəaliyyəti əlavə edir. Göndərişlər ayın sonunda hələ aktivdirsə, onların sorğularını həmin sorğuların baş verdiyi hesablaşma dövrlərinə bölüşdürün.
Nümunə: daha ucuz modelin dəyişdiyi vəziyyət
Aşağıdakı rəqəmlər yalnız hesablamanı nümayiş etdirmək üçün uydurulub. Bunlar 17TRACK qiymətləri, təchizatçı təklifləri və ya bazar göstəriciləri deyil.
Fərz edək ki, eyni modelləşdirilmiş dövr ərzində 10 000 bağlama qeydiyyatdan keçirilib və tam monitorinq olunur. Hər biri səkkiz gün ərzində bir qeydiyyat sorğusu və gündə üç axtarış sorğusu tələb edir. Fərz edək ki, hər sorğu ödənişlidir, hər sorğu bir bağlama ilə bağlıdır və heç bir təkrar cəhd, paket endirimi, güzəşt və ya sabit ödəniş yoxdur.
- Qeydiyyat sorğuları: 10 000.
- Axtarış sorğuları: 10 000 × 8 × 3 = 240 000.
- Ümumi ödənişli sorğular: 250 000.
- Nümunəvi çağrı başına tarif: $0.002.
- Nümunəvi göndəriş başına tarif: $0.04, tələb olunan monitorinq daxil olmaqla.
Çağrı başına istifadə xərci 250 000 × $0.002 = $500-dır. Göndəriş başına istifadə xərci 10 000 × $0.04 = $400-dır. Bu fərziyyələrə əsasən, göndəriş başına qiymət istifadə üçün $100 daha azdır.
İndi yalnız axtarış tezliyini gündə bir dəfəyə dəyişək. Sorğu sayı 10 000 qeydiyyat və 80 000 axtarış, yəni 90 000 çağrı olur. Çağrı başına istifadə xərci $180-a düşür, nümunəvi göndəriş başına istifadə xərci isə $400 olaraq qalır. İş yükü dəyişdiyi üçün üstünlük verilən model də dəyişir; bunun səbəbi qiymət strukturlarından hər hansı birinin mahiyyətcə daha yaxşı olması deyil.
Zərərsizlik nöqtəsini tapın
Hər iki planda sabit ödəniş, güzəşt və ya əlavə haqq yoxdursa, aşağıdakı düsturdan istifadə edin:
Göndəriş başına zərərsizlik ödənişli çağrı sayı = göndəriş tarifi ÷ çağrı tarifi
Nümunədə $0.04 ÷ $0.002 göndəriş başına 20 ödənişli çağrıya bərabərdir. 20 çağrıdan yuxarı olduqda göndəriş haqqı daha aşağıdır; 20-dən aşağı olduqda çağrı haqqı daha aşağıdır. Nümunənin fərziyyələrinə əsasən qeydiyyat çağrıları da bu həddə daxildir.
Bu qısa üsul pilləli planlar, əvvəlcədən ödənilmiş kreditlər, fərqli endpoint tarifləri və ya minimum öhdəliklər üçün kifayət deyil. Belə təkliflərdə əsas vahid tariflərini müqayisə etmək əvəzinə, hər proqnozlaşdırılan həcm üzrə tam hesab-fakturanı hesablayın.
Webhook-lar sorğulamaları azalda bilər, lakin hesablaşma hələ də yoxlanılmalıdır
Sorğulama tətbiqinizin izləmə məlumatını təkrar-təkrar istəməsi deməkdir. Webhook xidmətə tətbiqinizə hadisə göndərməyə imkan verir və hadisə axını tələblərinizə cavab verdikdə təkrar axtarış ehtiyacını azaldır.
Lakin daha az axtarış sorğusu avtomatik olaraq daha aşağı hesab-faktura demək deyil. Webhook çatdırılmasının daxil olub-olmadığını, çatdırılmaların və ya təkrar cəhdlərin ölçülüb-ölçülmədiyini, həmçinin uyğunlaşdırma axtarışlarının hələ də lazım olub-olmadığını təsdiqləyin. Tətbiqiniz həmçinin təkrarlanan və ya ardıcıllığı pozulmuş hadisələri təhlükəsiz şəkildə idarə etməli və çatdırılma uğursuzluqlarından bərpa olunmalıdır.
Qorunmalı başqa bir fərq də var: məlumatı daha tez-tez tələb etmək əsas daşıyıcının yeni skan yaratmasına zəmanət vermir. Az əməliyyat dəyəri yarada biləcək sorğulama tezliyinə pul ödəməzdən əvvəl axtarışın nə qaytardığını və məlumat yenilənməsinin necə işlədiyini soruşun.
Başlıq tarifinin gizlədə biləcəyi xərclər
Daxil edilmiş güzəştlər, minimumlar və əvvəlcədən ödənilmiş qalıqlar
Minimum hesab-fakturanı daxil edilmiş istifadə ilə abunəlikdən fərqləndirin. Minimum hesab-faktura xərclərin aşağı həddini müəyyən edə bilər; güzəşt isə artıq istifadə haqları tətbiq olunmazdan əvvəl müəyyən edilmiş miqdarı əhatə edə bilər. Əvvəlcədən ödənilmiş kreditlər müddətin bitməsi, geri qaytarılma və istifadə olunmamış qalıqlarla bağlı ayrıca suallar yaradır.
Güzəşt artıq istifadə ödənişlərindən əvvəl çıxılan plan üçün faydalı struktur belədir:
API hesab-fakturası = sabit plan haqqı + ödənişli artıq istifadə + tətbiq olunan əlavələr
Bu düsturdan yalnız müqaviləyə uyğun gəldiyi halda istifadə edin. Eyni daxil edilmiş istifadəni iki dəfə əlavə etməyin və bütün planların marjinal qiymətləndirməni eyni qaydada tətbiq etdiyini düşünməyin.
Uzunmüddətli göndərişlər və təkrar qeydiyyatlar
Uzun monitorinq müddətləri sorğulama modelində axtarış həcmini artırır. Göndəriş başına qiymətləndirmədə əsas sual ilkin haqqın həmin müddəti əhatə edib-etməməsidir. Yalnız tez tamamlanan çatdırılmaları deyil, istisnaları və gecikmiş göndərişləri də yoxlayın.
Həmçinin eyni izləmə nömrəsinin iki dəfə təqdim edilməsi, düzəldilməsi, silinib yenidən əlavə edilməsi və ya başqa daşıyıcı ilə əlaqələndirilməsi zamanı nə baş verdiyini təsdiqləyin. Uyğun olduqda təkrarların qarşısını alın, lakin tətbiq səviyyəsindəki təkrarların aradan qaldırılmasının təchizatçının hesablaşma identikliyi ilə tam uyğun olduğunu düşünməyin.
Tarif məhdudiyyətləri və pik tutum
Əlverişli aylıq güzəşt inteqrasiyanın böyük idxalı və ya trafik artımını idarə edə biləcəyini göstərmir. Sorğu tezliyi məhdudiyyətlərini, paket limitlərini, paralellik məhdudiyyətlərini və limitlərə çatdıqda gözlənilən davranışı yoxlayın. Aylıq həcmi ödəyən, lakin tələb olunan iş prosesini dəstəkləməyən plan eyni əsasda müqayisə edilə bilən alternativ deyil.
Mühəndislik və əməliyyat xərcləri
API hesab-fakturasını ümumi sahibolma xərcindən ayrı saxlayın. Daxili xərclərə inteqrasiyanın hazırlanması, webhook hostinqi, növbələr, monitorinq, insidentlərə cavab, məlumatların saxlanması və texniki xidmət daxil ola bilər.
Öz əmək və infrastruktur qiymətləndirmələrinizdən istifadə edin. Daha bahalı abunəlik əməliyyat işini əhəmiyyətli dərəcədə azaltdığı sübut olunarsa, yenə də iqtisadi cəhətdən sərfəli ola bilər, lakin bu qənaət fərziyyə kimi deyil, yoxlanılaraq qəbul edilməlidir.
Təklifləri necə müqayisə etməli və qısa siyahını necə təsdiqləməli
Hər təchizatçıdan eyni iş yükü spesifikasiyasını qiymətləndirməsini istəyin: bağlama həcmi, göndəriş tərkibi, monitorinq müddəti, yeniləmə tələbləri, endpoint-lər, pik yük və tələb olunan xidmətlər. Hesablaşma vahidinin yazılı izahını və nümunə hesab-faktura hesablamasını tələb edin.
17TRACK-i nəzərdən keçirən komandalar üçün rəsmi Tracking API səhifəsi və API sənədləri məhsul və inteqrasiya qiymətləndirməsi üçün müvafiq başlanğıc nöqtələridir. Proqnozunuzda bir model təyin etməzdən əvvəl tətbiq olunan qiymətləri və hesablaşma təriflərini birbaşa təsdiqləyin. Bu məqalədə cari 17TRACK planı üzrə qiymət göstərilmir və ya təsnifat aparılmır.
Öhdəlik götürməzdən əvvəl nümunəvi göndərişlərdən istifadə edərək nəzarətli pilot həyata keçirin. Bölünmüş sifarişləri, təkrar təqdimatları, gecikmiş bağlamaları, sərhədlərarası daşımaları və hesablaşma sərhədini keçən göndərişləri daxil edin. Uğursuzluq və ya təkrar cəhd davranışını yalnız xidmətin icazə verdiyi üsullarla yoxlayın.
- Sorğu qeydlərinizi təchizatçının istifadə məlumatları ilə müqayisə edin.
- Qeydiyyatdan keçmiş izləmə vahidlərini hesablanmış göndəriş vahidləri ilə tutuşdurun.
- Tələb olunan yeniləmə tezliyinin faktiki olaraq əldə edilib-edilmədiyini yoxlayın.
- Pik tələbi aylıq istehlakdan ayrıca ölçün.
- Xərcləri proqnozlaşdırmazdan əvvəl izah olunmayan fərqləri araşdırın.
Ən azı üç proqnoz hazırlayın: normal əməliyyatlar, mövsümi pik və uzadılmış tranzit. Hesaba ixtiyari faiz əlavə etmək əvəzinə əsas amilləri dəyişdirin. Məsələn, pik dövr üçün daha çox bağlama, gecikmə ssenarisi üçün isə daha uzun monitorinq müddəti modelləşdirin.
Hansı modeli seçməlisiniz?
Çağrı başına qiymətə üstünlük verin — axtarışlar az tezlikli olduqda, sorğu tələbi ölçülə bildikdə və qeydiyyatlar ilə digər ödənişli fəaliyyət daxil edildikdən sonra proqnoz zərərsizlik nöqtəsindən aşağı qaldıqda. Tez-tez sorğulama və ya proqnozlaşdırılmayan monitorinq müddəti əhəmiyyətli sorğu riski yaratdıqda bu model daha az cəlbedicidir.
Göndəriş başına qiymətə üstünlük verin — davamlı monitorinq tələb olunduqda və təklif edilən göndəriş haqqına ehtiyacınız olan yeniləmə tezliyi, izləmə müddəti və çatdırılma mexanizmi daxil olduqda. Nadir istifadə etdiyiniz monitorinq üçün ödəniş etdikdə və ya göndəriş tərifi gözlənilməz əlavə vahidlər yaratdıqda bu model daha az cəlbedicidir.
Son qərar əməliyyat başına ümumi xərcə əsaslanmalıdır: API hesab-fakturası və aid edilə bilən əməliyyat xərcləri, biznesinizin monitorinq etməli olduğu unikal bağlamalara bölünməklə. Təchizatçılar fərqli hesablaşma vahidlərindən istifadə etsələr də, təkliflər arasında daxili bağlama tərifini ardıcıl saxlayın.
Tez-tez verilən suallar
Uğursuz API sorğuları ödənişlidirmi?
Heç bir nəticəni avtomatik qəbul etməyin. Doğrulama xətaları, autentifikasiya uğursuzluqları, tarif limiti cavabları, server xətaları və vaxt aşımı ilə bağlı qaydaları soruşun. Vaxt aşımı, tətbiqiniz yenidən cəhd etməzdən əvvəl sorğunun emal edilib-edilmədiyi ilə bağlı qeyri-müəyyənlik də yarada bilər.
Bir sifariş həmişə bir göndəriş sayılır?
Xeyr. Sifarişdə ayrıca izlənən bir neçə bağlama ola bilər. Büdcə planlaşdırması üçün sifarişləri izləmə vahidlərinə uyğunlaşdırın və sonra təchizatçının tərifini tətbiq edin. Qaytarmaların, əvəzləmələrin və daşıyıcılar arasında təhvilin necə hesablandığını təsdiqləyin.
Paket sorğuları hesabımı azaldacaq?
Yalnız hesablaşma qaydaları paket sorğularını üstün tutursa. Paketlər şəbəkə sorğularını azalda bilər, lakin ödənişli izləmə vahidlərini azaltmaya bilər. Paket limitini və hesablaşmanın sorğu başına, element başına və ya çəkili vahid vasitəsilə tətbiq edilib-edilmədiyini yoxlayın.
Webhook-lar bütün axtarış sorğularını aradan qaldıra bilər?
Onlar müntəzəm sorğulamanın böyük hissəsini aradan qaldıra bilər, lakin dizaynınızda ilkin əldəetmə, buraxılmış hadisələrdən sonra bərpa və ya dövri uyğunlaşdırma hələ də tələb oluna bilər. Bu çağrıları qiymətləndirməyə daxil edin və webhook çatdırılması üçün hər hansı ödənişi təsdiqləyin.
Gələn ay hələ aktiv olan göndərişlər üçün büdcəni necə planlaşdırmalıyam?
Çağrı başına qiymətləndirmədə həmin göndərişlərin növbəti dövrdə yaradacağı sorğuları proqnozlaşdırın. Göndəriş başına qiymətləndirmədə monitorinqin əhatə olunmağa davam edib-etmədiyini və ya əlavə ödəniş yaradıb-yaratmadığını təsdiqləyin. Davam edən iş yükünü qiymətləndirərkən yalnız yeni yaradılmış göndərişləri saymayın.
Mənbələr
Yuxarıdakı hesablamalarda dərc edilmiş təchizatçı qiymətlərindən deyil, açıq şəkildə hipotetik giriş məlumatlarından istifadə olunur. 17TRACK qiymətləndirməsi üçün bu rəsmi istinad səhifələrindən istifadə edin və kommersiya şərtlərini birbaşa təsdiqləyin:
