Takip API'si Fiyatlandırma Modelleri Açıklandı: Çağrı Başına mı Gönderi Başına mı? Gerçek Maliyetinizi Nasıl Tahmin Edebilirsiniz
Çağrı başına izleme API'si fiyatlandırması, ücretlendirilebilir istekler için ücret alır; gönderi başına fiyatlandırma ise kayıtlı bir takip numarası gibi tanımlanmış bir izleme birimi için ücret alır. Bunlardan hiçbiri otomatik olarak daha ucuz değildir. Gerçek maliyetinizi tahmin etmek için her iki modeli aynı gönderi hacmi, güncelleme gereksinimleri, izleme süresi ve faturalandırma kuralları üzerinden karşılaştırın; ardından platform ücretlerini, aşım ücretlerini ve entegrasyon maliyetlerini ekleyin.
Mühendislik, operasyon ve satın alma ekipleri için yararlı karşılaştırma yalnızca çağrı başına fiyat ile gönderi başına fiyat arasında değildir. Asıl mesele, işletmenizin ihtiyaç duyduğu gönderi görünürlüğünü sağlamanın toplam maliyetidir. Düşük bir istek oranı sık yoklama nedeniyle pahalı hale gelebilir; düşük bir gönderi oranı ise izleme penceresi veya dahil edilen hizmetler iş akışınıza uymuyorsa yanıltıcı olabilir.
Her fiyatlandırma modeli gerçekte neyi ölçer?
İlk adım üç şeyi birbirinden ayırmaktır: bir API isteği, bir gönderi kaydı ve bir izleme güncellemesi. Bunlar farklı olaylardır ve bir sözleşme her biri için farklı faturalandırma uygulamaları belirleyebilir.
| Karşılaştırma noktası | Çağrı başına fiyatlandırma | Gönderi başına fiyatlandırma |
|---|---|---|
| Faturalandırma temeli | Ücretlendirilebilir olarak tanımlanan istekler veya istek birimleri | Ücretlendirilebilir olarak tanımlanan gönderi birimleri |
| Ana maliyet unsuru | Uygulamanın ücretlendirilebilir istekleri ne sıklıkta yaptığı | Ücretlendirilebilir izleme birimlerinden kaçının kapsama girdiği veya kapsamda kaldığı |
| Çözülmesi gereken faturalandırma sorusu | Hangi uç noktalar, yanıtlar ve toplu işlem öğeleri sayılır? | Bir gönderiyi ne oluşturur ve izleme ne kadar süreyle dahildir? |
| Olası maliyet riski | Tekrarlanan yoklamalar, yeniden denemeler ve gereksiz sorgular | Yinelenen kayıtlar, birden fazla paket ve izleme penceresi sınırları |
| En uygun olduğu koşul | Kontrollü istek hacmine sahip düşük frekanslı sorgular | Güncellemelerin gönderi ücretine dahil olduğu sürekli izleme |
Çağrı başına fiyatlandırma, her HTTP isteğinin aynı maliyete sahip olduğu anlamına gelmez
Bir fiyat teklifi, ücretlendirilebilir uç noktaları ve bunların birimlerini belirtmelidir. Bir takip numarasının kaydedilmesi, depolanan sonuçların alınması, yenileme talep edilmesi ve aboneliklerin yönetilmesi farklı şekilde ele alınabilir. Başarısız bir isteğin ücretsiz olduğunu veya başarılı bir isteğin her zaman ücretlendirileceğini varsaymayın.
Toplu işlemler de açıkça tanımlanmalıdır. 100 takip numarası içeren tek bir istek, bir istek, 100 izleme birimi veya sözleşmede belirtilen başka bir miktar olarak sayılabilir. Ağ trafiğini azaltmak, ölçüm kuralları bunu desteklemediği sürece faturalandırma tasarrufu sağlamaz.
Gönderi başına fiyatlandırma, sipariş başına fiyatlandırma anlamına gelmez
Bir e-ticaret siparişi birkaç paket oluşturabilir. Ücretlendirilebilir birim takip numarasıysa bölünmüş bir sipariş birden fazla birim tüketebilir. İadeler, değiştirme gönderileri ve taşıyıcı devirleri de net biçimde ele alınmalıdır.
Ücretin belirli bir dönem için mi, tanımlanmış bir tamamlanma olayına kadar mı veya başka bir sınır kapsamında mı izleme sağladığını sorun. Ayrıca daha önce kaydedilmiş gönderilerin sonraki bir faturalandırma döneminde yeni ücretlere tabi olup olmadığını belirleyin. Bu ayrıntılar, fiyatlandırma planındaki etiketten daha önemlidir.
Maliyeti yalnızca sipariş sayınızdan değil, iş akışınızdan tahmin edin
Temsili bir operasyon dönemi kullanın ve gönderi düzeyindeki verilerden bir tahmin oluşturun. Yeni gönderilerin yanı sıra hâlâ izlenmesi gereken eski gönderileri de dahil edin. Verileriniz eksikse sonucu kesin bir teklif gibi sunmak yerine varsayımları görünür kılın.
- İzlenebilir paketleri sayın. Ödeme siparişlerinden değil, benzersiz paket izleme birimlerinden başlayın. Faturalandırma uygulamaları doğrulanana kadar giden paketleri, iadeleri ve değiştirme gönderilerini ayrı tutun.
- İzleme süresini ölçün. Gerektiğinde taşıma öncesi ve istisna dönemleri de dahil olmak üzere her gönderinin güncellemelere ne kadar süre ihtiyaç duyduğunu tahmin edin.
- Gerekli güncelleme sıklığını tanımlayın. Uygulamanızın ne sıklıkta güncel bilgiye ihtiyaç duyduğunu ve bunun gönderi durumuna göre değişip değişmediğini belirtin.
- API iş akışını eşleyin. Entegrasyonunuzun kullanacağı kayıt, sonuç sorguları, yenileme istekleri, düzeltmeler, yeniden denemeler ve diğer uç noktaları listeleyin.
- Faturalandırma kurallarını uygulayın. Teknik etkinliği, önerilen sözleşmeyi kullanarak ücretlendirilebilir çağrılara veya gönderi birimlerine dönüştürün.
- Kullanım dışı ücretleri ekleyin. Geçerli abonelik, minimum taahhüt, isteğe bağlı hizmetler ve uygulama veya işletim maliyetlerini dahil edin.
Her sorguda bir takip numarası kullanılan basit bir yoklama entegrasyonu için başlangıç tahmini şöyledir:
Sorgu istekleri = izlenen gönderiler × ortalama izlenen gün sayısı × günlük sorgu sayısı
Bu kısayol, her gönderinin aynı ortalama programa uyduğunu varsayar. Daha doğru bir model, her gönderi veya gönderi grubuna ait istekleri toplar ve ardından kayıt çağrılarını ve diğer ücretlendirilebilir etkinlikleri ekler. Gönderiler ay sonu boyunca aktif kalıyorsa isteklerini, bu isteklerin gerçekleştiği faturalandırma dönemlerine dağıtın.
Uygulamalı bir örnek: Daha ucuz model değiştiğinde
Aşağıdaki sayılar yalnızca hesaplamayı göstermek amacıyla oluşturulmuştur. Bunlar 17TRACK fiyatları, tedarikçi teklifleri veya piyasa karşılaştırmaları değildir.
Aynı modellenen dönem içinde 10.000 paketin kaydedildiğini ve tamamen izlendiğini varsayalım. Her biri için sekiz gün boyunca günde bir kayıt isteği ve üç sorgu isteği gerektiğini varsayın. Her isteğin ücretlendirilebilir olduğunu, her isteğin bir paketi ilgilendirdiğini ve yeniden deneme, toplu işlem indirimi, muafiyet veya sabit ücret bulunmadığını kabul edin.
- Kayıt istekleri: 10.000.
- Sorgu istekleri: 10.000 × 8 × 3 = 240.000.
- Toplam ücretlendirilebilir istek: 250.000.
- Örnek çağrı başına ücret: $0.002.
- Gerekli izlemeyi içeren örnek gönderi başına ücret: $0.04.
Çağrı başına kullanım maliyeti 250.000 × $0.002 = $500 olur. Gönderi başına kullanım maliyeti 10.000 × $0.04 = $400 olur. Bu varsayımlar altında gönderi başına fiyatlandırma kullanım için $100 daha ucuzdur.
Şimdi yalnızca sorgu sıklığını günde bire değiştirin. İstek sayısı 10.000 kayıt artı 80.000 sorgu, yani 90.000 çağrı olur. Çağrı başına kullanım maliyeti $180'a düşerken örnek gönderi başına kullanım maliyeti $400 olarak kalır. Tercih edilen model, herhangi bir fiyatlandırma yapısının doğası gereği daha iyi olması nedeniyle değil, iş yükü değiştiği için değişir.
Başabaş noktasını bulun
Her iki planda da sabit ücret, muafiyet veya ek ücret yoksa şu formülü kullanın:
Gönderi başına başabaş ücretlendirilebilir çağrı sayısı = gönderi ücreti ÷ çağrı ücreti
Örnekte, $0.04 ÷ $0.002, gönderi başına 20 ücretlendirilebilir çağrı eder. 20 çağrının üzerinde gönderi ücreti daha düşüktür; 20'nin altında çağrı ücreti daha düşüktür. Örneğin varsayımları uyarınca kayıt çağrıları bu eşiğe dahildir.
Bu kısayol kademeli planlar, ön ödemeli krediler, farklı uç nokta ücretleri veya minimum taahhütler için yeterli değildir. Bu teklifler için başlık birim ücretlerini karşılaştırmak yerine her tahmini hacimde tam faturayı hesaplayın.
Web kancaları yoklamayı azaltabilir, ancak faturalandırma yine doğrulanmalıdır
Yoklama, uygulamanızın izleme bilgilerini tekrar tekrar istemesi anlamına gelir. Web kancası ise bir hizmetin uygulamanıza olay göndermesini sağlar ve olay akışı gereksinimlerinizi karşılıyorsa tekrarlanan sorgu ihtiyacını azaltır.
Ancak daha az sorgu isteği otomatik olarak daha düşük fatura anlamına gelmez. Web kancası iletiminin dahil olup olmadığını, iletimlerin veya yeniden denemelerin ölçülüp ölçülmediğini ve mutabakat sorgularının hâlâ gerekli olup olmadığını doğrulayın. Uygulamanızın yinelenen veya sırası değişmiş olayları güvenli biçimde ele alması ve iletim hatalarından kurtulması da gerekir.
Korunması gereken başka bir ayrım daha vardır: bilgiyi daha sık istemek, temel taşıyıcının yeni bir tarama oluşturduğunu garanti etmez. Çok az operasyonel değer sağlayabilecek bir yoklama sıklığı için ödeme yapmadan önce bir sorgunun ne döndürdüğünü ve verilerin nasıl yenilendiğini sorun.
Başlık ücretinin gizleyebileceği maliyetler
Dahil edilen kullanımlar, minimumlar ve ön ödemeli bakiyeler
Minimum fatura ile dahil kullanıma sahip aboneliği birbirinden ayırın. Minimum fatura bir harcama tabanı belirleyebilir; kullanım hakkı ise aşım ücretleri uygulanmadan önce belirli bir miktarı karşılayabilir. Ön ödemeli krediler, sona erme, geri ödeme ve kullanılmayan bakiyeler hakkında ayrıca sorular doğurur.
Kullanım hakkının aşım ücretlerinden önce düşüldüğü bir plan için yararlı bir yapı şöyledir:
API faturası = sabit plan ücreti + ücretlendirilebilir aşım + geçerli eklentiler
Bu formülü yalnızca sözleşmeyle uyumluysa kullanın. Aynı dahil kullanımı iki kez eklemeyin veya tüm planların marjinal fiyatlandırmayı aynı şekilde uyguladığını varsaymayın.
Uzun süren gönderiler ve tekrarlanan kayıtlar
Uzun izleme süreleri, yoklama tasarımında sorgu hacmini artırır. Gönderi başına fiyatlandırmada asıl soru, ilk ücretin bu süreyi kapsayıp kapsamadığıdır. Yalnızca hızlı tamamlanan teslimatları değil, istisnaları ve geciken gönderileri de test edin.
Ayrıca aynı takip numarasının iki kez gönderilmesi, düzeltilmesi, silinip yeniden eklenmesi veya farklı bir taşıyıcıyla ilişkilendirilmesi durumunda ne olduğunu doğrulayın. Uygun olduğunda yinelenen kayıtları önleyin; ancak uygulama düzeyindeki tekilleştirmenin tedarikçinin faturalandırma kimliğiyle tamamen örtüştüğünü varsaymayın.
Hız sınırları ve yoğun dönem kapasitesi
Uygun fiyatlı bir aylık kullanım hakkı, entegrasyonun büyük bir içe aktarma işlemini veya trafik artışını kaldırabileceği anlamına gelmez. İstek hızı sınırlarını, toplu işlem sınırlarını, eşzamanlılık kısıtlamalarını ve sınırlara ulaşıldığında beklenen davranışı kontrol edin. Aylık hacmi karşılayan ancak gerekli iş akışını destekleyemeyen bir plan eşdeğer bir alternatif değildir.
Mühendislik ve işletim maliyetleri
API faturasını toplam sahip olma maliyetinden ayrı tutun. Dahili giderler arasında entegrasyon geliştirme, web kancası barındırma, kuyruklar, izleme, olaylara müdahale, veri depolama ve bakım bulunabilir.
Kendi iş gücü ve altyapı tahminlerinizi kullanın. Daha pahalı bir abonelik, operasyonel işi görünür biçimde azaltıyorsa yine de ekonomik olabilir; ancak bu tasarruf varsayılmak yerine test edilmelidir.
Teklifleri karşılaştırma ve kısa listeyi doğrulama
Her tedarikçiden aynı iş yükü tanımına göre fiyat vermesini isteyin: paket hacmi, gönderi karması, izleme süresi, güncelleme gereksinimleri, uç noktalar, yoğun yük ve gerekli hizmetler. Faturalandırma biriminin yazılı açıklamasını ve örnek bir fatura hesaplamasını talep edin.
17TRACK'i değerlendiren ekipler için resmi Tracking API sayfası ve API belgeleri, ürün ve entegrasyon değerlendirmesi için ilgili başlangıç noktalarıdır. Tahmininizde bir model belirlemeden önce geçerli fiyatlandırmayı ve faturalandırma tanımlarını doğrudan doğrulayın. Bu makale güncel bir 17TRACK planından alıntı yapmaz veya planı sınıflandırmaz.
Taahhütte bulunmadan önce temsili gönderileri kullanarak kontrollü bir pilot yürütün. Bölünmüş siparişleri, yinelenen gönderimleri, geciken paketleri, sınır ötesi hareketleri ve bir faturalandırma sınırını aşan gönderileri dahil edin. Hata veya yeniden deneme davranışını yalnızca hizmetin izin verdiği şekillerde test edin.
- İstek günlüklerinizi tedarikçinin kullanım kayıtlarıyla karşılaştırın.
- Kaydedilen takip birimlerini faturalandırılan gönderi birimleriyle mutabık hale getirin.
- Gerekli güncelleme sıklığının gerçekten sağlanıp sağlanmadığını kontrol edin.
- Yoğun talebi aylık tüketimden ayrı ölçün.
- Maliyetleri genellemeden önce açıklanamayan farkları araştırın.
En az üç tahmin oluşturun: normal operasyonlar, mevsimsel yoğunluk ve uzayan taşıma. Faturaya rastgele bir yüzde eklemek yerine temel etkenleri değiştirin. Örneğin yoğun dönem için daha fazla paket, gecikme senaryosu için daha uzun izleme süreleri modelleyin.
Hangi modeli seçmelisiniz?
Çağrı başına fiyatlandırmayı tercih edin; sorgular seyrek olduğunda, istek talebi ölçülebilir olduğunda ve kayıtlar ile diğer ücretlendirilebilir etkinlikler dahil edildikten sonra tahmin başabaş noktasının altında kaldığında. Sık yoklama veya öngörülemeyen izleme süresi önemli ölçüde istek riski oluşturduğunda bu model daha az caziptir.
Gönderi başına fiyatlandırmayı tercih edin; sürekli izleme gerektiğinde ve teklif edilen gönderi ücreti ihtiyacınız olan güncelleme sıklığını, izleme süresini ve iletim mekanizmasını kapsadığında. Nadiren kullandığınız izleme için ödeme yaptığınızda veya gönderi tanımı beklenmeyen ek birimler oluşturduğunda bu model daha az caziptir.
Nihai karar operasyonel paket başına toplam maliyeti kullanmalıdır: API faturası artı atfedilebilir işletim maliyetleri, işletmenizin izlemesi gereken benzersiz paketlere bölünür. Tedarikçiler farklı faturalandırma birimleri kullansa bile kendi paket tanımınızı teklifler arasında tutarlı tutun.
SSS
Başarısız API istekleri ücretlendirilebilir mi?
Herhangi bir sonucu varsaymayın. Doğrulama hatalarının, kimlik doğrulama başarısızlıklarının, hız sınırı yanıtlarının, sunucu hatalarının ve zaman aşımlarının nasıl ele alındığını sorun. Zaman aşımı, uygulamanız yeniden denemeden önce bir isteğin işlenip işlenmediği konusunda da belirsizlik yaratabilir.
Bir sipariş her zaman bir gönderi olarak mı sayılır?
Hayır. Bir sipariş, ayrı ayrı izlenen birkaç paket içerebilir. Bütçeleme için siparişleri takip birimleriyle eşleyin ve ardından tedarikçinin tanımını uygulayın. İadelerin, değiştirme gönderilerinin ve taşıyıcı devirlerinin nasıl sayıldığını doğrulayın.
Toplu istekler faturamı azaltır mı?
Yalnızca faturalandırma kuralları toplu işlemleri ödüllendiriyorsa. Toplu işlemler, ücretlendirilebilir izleme birimlerini azaltmadan ağ isteklerini azaltabilir. Toplu işlem sınırını ve faturalandırmanın istek başına, öğe başına veya ağırlıklı birim üzerinden mi uygulandığını doğrulayın.
Web kancaları tüm sorgu isteklerini ortadan kaldırabilir mi?
Rutin yoklamaların çoğunu ortadan kaldırabilirler; ancak tasarımınız yine de ilk erişime, kaçırılan olaylardan sonra kurtarmaya veya periyodik mutabakata ihtiyaç duyabilir. Bu çağrıları tahmine dahil edin ve web kancası iletimi için ücret olup olmadığını doğrulayın.
Gelecek ay hâlâ aktif olan gönderiler için nasıl bütçe ayırmalıyım?
Çağrı başına fiyatlandırmada bu gönderilerin sonraki dönemde oluşturacağı istekleri tahmin edin. Gönderi başına fiyatlandırmada izlemenin kapsanmaya devam edip etmediğini veya başka bir ücret doğurup doğurmadığını doğrulayın. Devam eden iş yükünü tahmin ederken yalnızca yeni oluşturulan gönderileri saymayın.
Kaynaklar
Yukarıdaki hesaplamalarda yayımlanmış tedarikçi fiyatları değil, açıkça varsayımsal girdiler kullanılmıştır. 17TRACK değerlendirmesi için bu resmi referans sayfalarını kullanın ve ticari şartları doğrudan doğrulayın:
