Kullanımı izleyen, adil fiyatlandıran, müşterilere fatura düzenleyen ve aşım, tekrar denemeler ve itirazlar gibi uç durumları yöneten bir web uygulamasını nasıl tasarlayıp inşa edeceğinizi öğrenin.
Kullanıma dayalı faturalama ancak herkesin “kullanım”ın ne olduğunu kabul ettiği zaman işe yarar. Tabloları tasarlamadan veya bir ödeme sağlayıcı seçmeden önce, hangi birimi ölçeceğinizi ve ücretlendireceğinizi tam olarak yazın—çünkü bu karar izleme, faturalar, destek ve müşteri güveni üzerinde etkili olur.
Somut, denetlenebilir bir tanımla başlayın:
Sonra neyin faturalandırılacağını kararlaştırın. Örneğin: başarısız API çağrıları faturalandırılır mı? Tekrar denemeler ücretsiz mi? Başlanan dakikaya mı yoksa saniyeye mi göre ücretlendirirsiniz? Keskin tanımlar daha sonra anlaşmazlıkları azaltır.
Müşteri beklentilerine ve veriyi uzlaştırma yeteneğinize uyan periyodu seçin:
Gerçek zamanlı kullanım grafiklerine sahip olsanız bile, birçok ürün muhasebenin öngörülebilir olması için aylık fatura kesmeye devam eder.
Faturalama sahibini netleştirin: hesap, workspace veya bireysel kullanıcı. Bu, izinleri, fatura satır öğelerini ve kullanımın nasıl toplanacağını etkiler.
En azından kullanıcıların şunları yapabilmesini planlayın:
Emin değilseniz, önce faturalama portalı ekranlarını taslak olarak çizin; bu, eksik kararları erken ortaya çıkaracaktır (ayrıca bkz. /blog/customer-billing-portal).
Kullanıma dayalı faturalama, müşterilerin bir hesap tablosuna ihtiyaç duymadan sonraki faturalarını tahmin edebildiklerinde en iyi şekilde çalışır. Amacınız fiyatlandırmayı “az matematik” hissettirmek, aynı zamanda maliyetlerinizin nasıl ölçeklendiğini yansıtmak.
Kullandıkça öde (birim başı sabit fiyat) anlaşılması en kolay olanıdır: API çağrısı başına $0.02, GB başına $0.10 vb. Her birim maliyeti yaklaşık aynı olduğunda idealdir.
Kademeli fiyatlar yüksek hacimlerde maliyet düşüşü olduğunda veya büyümeyi ödüllendirmek istediğinizde yardımcı olur. Katmanları az ve net adlandırılmış tutun.
Dahil edilmiş haklar (ör. “ilk 10.000 olay dahil”) faturaları stabil hale getirir ve küçük tutarlı faturaları azaltır.
| Model | Örnek | En uygun olduğu durum |
|---|---|---|
| Kullandıkça öde | $0.01 isteğe başına | Basit kullanım, net birim |
| Kademeli | 0–10k: $0.012, 10k–100k: $0.009 | Hacim indirimleri |
| Hakkı verilen | $49 20k isteği içerir, sonra $0.008 | Öngörülebilir bütçeler |
Bir temel ücret + kullanım genellikle en öngörülebilirdir: temel ücret destek, barındırma veya garanti edilen bir asgariyi karşılar; kullanım değerle ölçeklenir. Temeli açık bir faydaya bağlayın (“5 koltuk içerir” veya “20k çağrı içerir”).
Ücretsiz deneme sunuyorsanız, neyin ücretsiz olduğunu tanımlayın: zaman tabanlı (14 gün) ve/veya kullanım tabanlı (5k çağrıya kadar). Krediler için kurallar belirleyin: “önce aşım tutarına uygulanır” ve “12 ay sonra sona erer” gibi.
Kapanışı 2–3 düz İngilizce örnek paragrafla yapın (“30k istek kullandıysanız, $49 + 10k × $0.008 = $129 ödersiniz”). Bu tek paragraf çoğu zaman FAQ’dan daha fazla fiyatlandırma sorusunu azaltır.
Araçları seçmeden veya kod yazmadan önce, tek bir kullanım biriminin ürününüzden ücretli bir faturaya kadar giden tüm yolunu taslağıyla çizin. Bu, “gizemli matematik”, eksik veri ve ay sonu manuel iş sürprizlerini önler.
Basit bir iş akışı genellikle şöyle görünür:
Bunu dokümanlarınıza bir diyagram olarak yazın; zaman sınırlarını (saatlik vs günlük toplama, fatura tarihi, müsamaha süreleri) dahil edin.
Faturalama verilerine dokunan bileşenleri listeleyin:
Hangi işlemin uygulamanızda çalıştığını ve hangisini sağlayıcıya devrettiğinizi açıkça belirtin. İyi bir kural: ürün-spesifik sayaçlama ve karmaşık rating uygulamanızda kalsın; ödeme tahsilatı ve makbuzları mümkünse sağlayıcıya bırakın.
Kim ne yapar netleştirin:
Bu açıklık faturalamayı ölçeklendirilebilir ve desteklenebilir kılar.
Faturalama doğruluğunuz, her şeyden çok kullanım olaylarınızın yapısına bağlıdır. Net bir olay şeması, birçok servisten veri toplamanızı, müşteriye ücretleri açıklamanızı ve ileride denetimlerden sağ çıkmanızı kolaylaştırır.
Bir ücret üretebilecek her eylemi listeleyin (ör. “API isteği”, “gün başına GB saklama”, “aktif koltuk”). Her biri için zorunlu alanları ve tutarlı adlandırmayı tanımlayın.
Çoğu sayaç olayı en az şunları içermelidir:
customer_id (veya account_id)timestamp (kullanımın gerçekleştiği zaman, alınma zamanı değil)quantity (ücretlendireceğiniz birim)Sonra fiyatlayabileceğiniz veya raporlayabileceğiniz region, plan, feature veya resource_id gibi “boyutlar” ekleyin. Bu boyutları kararlı tutun—sonradan bir boyutun anlamını değiştirmek zordur.
Sayaç boru hatları yeniden denemelere maruz kalır. Bunu tasarlamazsanız iki kez sayım olur ve fazla faturalandırma yaşanır.
Değişmez bir event_id (veya source + request_id gibi bir idempotency anahtarı) ekleyin ve alım sırasında benzersizliği zorlayın. Aynı olay iki kez gelirse güvenle yoksayılsın veya birleştirilsin.
{
"event_id": "evt_01J...",
"customer_id": "cus_123",
"event_type": "api_call",
"timestamp": "2025-12-26T12:34:56Z",
"quantity": 1,
"dimensions": {"region": "us-east-1", "endpoint": "/v1/search"}
}
Gerçek sistemler gecikmeli kullanım gönderir (mobil istemciler, toplu işler, kesintiler). Politikanızı kararlaştırın:
Ayrıca düzeltmeleri ya (a) tersine çevirme olayları (negatif miktarlar) olarak ya da (b) supersedes_event_id ilişkisiyle destekleyin. Tarihsel satırları sessizce güncellemekten kaçının; değişiklikleri izlenebilir yapın.
Kullanım verisi müşteriyle paylaşılan kanıttır. İhtilaflar ve uyumluluk için ham olayları ve toplanmış toplamları yeterince uzun saklayın—çoğunlukla 12–24 ay, sektörünüze göre daha uzun olabilir. Kimlerin erişebileceğini, desteğe nasıl dışa aktarılacağını ve hesap kapandığında silinmelerin nasıl yönetileceğini tanımlayın.
Kullanıma dayalı faturalama, ham kullanım akışına güvenebiliyorsanız çalışır. Bu katmandaki hedefiniz basit: birçok kaynaktan olay kabul etmek, hatalı veriyi reddetmek ve geri kalanını downstream toplama işlemlerinin güvenebileceği şekilde depolamaktır.
Çoğu ekip bu desenlerden birini (veya karışımını) kullanır:
Pratik bir yaklaşım “API içeri, arkasına kuyruk koy”: API'niz olayları hızlıca doğrular ve kuyruğa ekler, sonra işçiler bunları asenkron olarak işler, böylece ani yükler uygulamanızı çökertmez.
Kullanım olaylarını ödeme gibi ele alın: sıkı kurallara ihtiyaçları var.
Zorunlu alanları doğrulayın (müşteri/hesap ID'si, zaman damgası, metrik adı, miktar), makul aralıkları zorlayın ve bilinmeyen metrikleri reddedin. Her müşteri veya API anahtarı için oran sınırlama ve throttling ekleyin ki alım servisinizi koruyun ve kontrolden çıkan istemcileri sınırlandırın.
İstemciler ve kuyruklar yeniden denemeler yapacaktır. Bunu bir idempotency/deduplication anahtarı (örneğin event_id + account_id) gerektirecek şekilde tasarlayın. Aynı olay iki kez gelse bile çifte faturalama olmaması için benzersiz kısıtlama saklayın.
Ayrıca bir alım durumu kaydedin (kabul edildi, reddedildi, karantinaya alındı) ve reddetme nedenini—bu destek ve itiraz çözümünü çok daha kolay hale getirir.
Alımı şu metriklerle instrumente edin ve uyarı kurun:
Buradaki küçük bir pano büyük fatura sürprizlerini önler. Eğer müşteri tarafına görünür şeffaflık inşa ediyorsanız, veriyi ne zaman kesinleştiğini müşteriye söylemek için portalde kullanım tazeliğini gösterebilirsiniz (ör. /billing).
Toplama, ham olayların faturalanabilecek bir şeye dönüştüğü yerdir. Hedefiniz her müşteri, her fatura dönemi ve her sayaç için net, tekrarlanabilir bir “faturalama özeti” üretmektir.
Basit bir sözleşme ile başlayın: belli bir müşteri ve dönem için (ör. 2025‑12‑01 to 2025‑12‑31) her meter için toplamları hesaplayın (API çağrıları, GB‑gün, koltuklar, dakika vb.). Çıktı deterministik olsun: aynı kesinleşmiş girdiler üzerinde toplama tekrar çalıştırıldığında aynı toplamları üretmelidir.
Pratik bir yaklaşım günlük olarak (yüksek hacim için saatlik) toplayıp sonra fatura dönemine roll-up yapmaktır. Bu sorguları hızlı tutar ve backfill işlemlerini yönetilebilir kılar.
Her meterı kendi “şeridi” gibi ele alın:
api_calls, storage_gb_day)Toplamları meter bazında saklayın ki daha sonra bağımsız fiyatlandırabilelim. Bugün fiyatınız paketli olsa bile, meter düzeyindeki toplamlar gelecekteki fiyat değişiklikleri ve müşteri açıklamaları için çok faydalıdır.
Hangi saate göre faturalayacağınızı önceden belirleyin:
Sonra kısmi dönemleri nasıl ele alacağınızı tanımlayın:
Bu kuralları dokümante edin ve tablo hesapları yerine kodla uygulayın. Günlük hata ve DST kaymaları sık itiraz sebebidir.
Sadece final toplamları saklamayın. Aşağıdaki gibi ara artefaktları da tutun:
Bu “kağıt izi” destek ekiplerinin “neden bu kadar faturalandım?” sorusuna ham loglara bakmak zorunda kalmadan cevap vermesini sağlar. Ayrıca düzeltmeler sonrası yeniden toplama yaparken önceki ve yeni sonuçları karşılaştırmayı kolaylaştırır.
Rating motoru, “ne kadar kullanıldı”yı “ne kadar ücretlendirilir”e çeviren kısımdır. Toplanmış kullanım toplamlarını ve müşterinin aktif fiyat planını alır, faturanın oluşturabileceği satır öğelerini üretir.
Çoğu kullandıkça öde fiyatlandırması sadece çarpma değildir. Yaygın kural tiplerini destekleyin:
Bunları sert kodlu koşullar yerine açık, test edilebilir kural blokları olarak modelleyin. Bu, denetimi ve yeni plan eklemeyi kolaylaştırır.
Kullanım gecikebilir, planlar güncellenebilir ve müşteriler dönem ortasında yükseltebilir. Tarihsel kullanımı bugünün planıyla yeniden değerlendirirseniz eski faturaları değiştirirsiniz.
Sürümlenmiş fiyat planları saklayın ve her rated satır öğesine kullanılan versiyonu iliştirin. Bir faturayı yeniden çalıştırırken aynı versiyonu kullanın; aksi halde kasıtlı bir düzeltme yapılmadığı sürece farklı sonuçlar çıkabilir.
Yuvarlamayı karar verin ve dokümante edin:
Son olarak müşterinin doğrulayabileceği bir satır-öğe dökümü üretin: miktar, birim fiyat, kademeli hesaplama, uygulanan dahil birimler ve minimum/kredi ayarlamaları. Net bir döküm destek taleplerini azaltır ve faturaya güveni artırır.
Faturalar kullanım matematiğinizin müşterinin anlayabileceği, onaylayabileceği ve ödeyebileceği bir şeye dönüştüğü yerdir. İyi bir fatura öngörülebilir, denetlenebilir ve gönderildikten sonra stabil olmalıdır.
Faturaları bir dönem anlık görüntüsünden oluşturun: müşteri, plan, para birimi, hizmet tarihleri ve kesinleşmiş faturalandırılabilir toplamlar. Ücretleri okunabilir satır öğelerine dönüştürün (ör. “API çağrıları (1,240,000 @ $0.0008)”). Tekrarlayan ücretler, tek seferlik ücretler ve kullanım için ayrı satırlar tutun ki müşteriler hızlıca uzlaşabilsin.
Vergileri ve indirimleri alt toplamı oluşturduktan sonra ekleyin. İndirim destekliyorsanız kullanılan kuralı (kupon, sözleşme fiyatı, hacim indirimi) kaydedin ve deterministik olarak uygulayın ki yeniden oluşturma aynı sonucu versin.
Çoğu ekip dönem sonu faturalama (aylık/haftalık) ile başlar. Kullandıkça öde için eşik faturalaması (ör. birikmiş $100 olduğunda) düşünün; bu kredi riskini ve büyük sürprizleri azaltır. Her müşteriye konfigüre edilebilen “fatura tetikleyicileri”yle her iki yaklaşımı da destekleyebilirsiniz.
Kesin kurallar belirleyin: yeniden oluşturma yalnızca bir fatura taslak durumundayken veya göndermeden önce kısa bir pencerede izin verilsin. İhraç edildikten sonra tarihi yeniden yazmak yerine ayarlamaları kredi notları/debit notları ile yapmayı tercih edin.
Fatura e-postalarını sabit bir fatura numarası ve görüntüleme/indirme bağlantısı ile gönderin. Muhasebe için PDF ve satır-öğe analizi için CSV sunun. İndirilebilir dosyaları müşteri portalinde (ör. /billing/invoices) sunun ki müşteriler destek aramadan kendi işlerini görebilsin.
Kullanıma dayalı faturalama, ödeme katmanınız kadar güvenilirdir. Hedef basit: doğru miktarı doğru zamanda tahsil etmek ve bir şeyler ters gittiğinde net kurtarma yolları sunmak.
Çoğu ekip, abonelikler, faturalar ve webhooks sunan bir ödeme sağlayıcısıyla başlar. Erken karar verin:
Faturaların ay içinde değişken olabileceğini tahmin ediyorsanız, sağlayıcının “fatura kesinleştirilip sonra öde” akışlarını desteklediğinden emin olun.
Yalnızca sağlayıcı token/ID'lerini saklayın (örneğin: customer_id, payment_method_id). Veritabanınız kart numaraları, CVC veya tam PAN içermemelidir—hiçbir zaman. Tokenizasyon, işlemleri uyumluluğu daha basitleştirerek yapmanızı sağlar.
Kullanıma dayalı faturalar beklenenden büyük olabilir, bu yüzden başarısızlıklar olur. Şunları tanımlayın:
Politikayı tutarlı ve faturalama UI'sında görünür yapın.
Ödeme durumunda webhookları yetkili kabul edin. Dahili “faturalama defteri”nizi sadece olaylar geldiğinde güncelleyin (invoice.paid, payment_failed, charge.refunded) ve işleyicileri idempotent yapın.
Ayrıca kaçırılan olayları yakalamak ve dahili durumu sağlayıcıyla uyumlu tutmak için periyodik bir mutabakat işi ekleyin.
Kullanıma dayalı model, müşteriler ay sonunda sadece toplamı gördüğünde “gizemli” gelebilir. Bir faturalama portalı kaygıyı azaltır, destek hacmini düşürür ve fiyatlandırmayı adil hissettirir—çünkü müşteriler ne için ücretlendirildiklerini doğrulayabilir.
Cari dönem kullanım ile birlikte açıkça etiketlenmiş bir tahmini maliyet gösterin. Tahminin varsayımlarını gösterin (kullanılan fiyat versiyonu, uygulanan indirimler, vergilerin dahil/haric olduğu) ve en son kullanım güncelleme zamanını belirtin.
UI'yi basit tutun: zaman içinde kullanım için bir grafik ve “kullanım → faturalandırılabilir birimler → tahmin” için kompakt bir döküm. Alım gecikmeli ise bunu belirtin.
Müşterilerin eşik uyarıları (e-posta, webhook, uygulama içi) ayarlamasına izin verin—ör. bütçenin %50'si, %80'i, %100'ü.
İsteğe bağlı harcama limitleri sunuyorsanız, limitte ne olacağını açıkça belirleyin:
Müşteriler şunları kendileri yapabilmeli:
/ fiyatlandırma ve /docs/billing gibi tanımlar, örnekler ve sık sorulanlar için referans verin.
“Kulağa yardım gerekiyor” gibi belirgin bir giriş ekleyin ve bağlamı önceden doldurun: hesap ID, fatura ID, zaman aralığı ve kullanım raporu anlık görüntüsü. Kısa bir form ve sohbet/e-posta seçenekleri genelde yeterlidir—ve temel konularda gidip gelmeleri engeller.
Kullanıma dayalı faturalama gerçek hayatta basit görünür; ta ki bir müşteri ay ortasında yükseltsin, iadə istesin ya da kullanımda ani bir artış için itiraz etsin. Bunları istisna değil, birinci sınıf ürün gereksinimleri olarak ele alın.
Plan değişikliği mid-cycle olduğunda “adil” ne demek netleştirin. Yaygın desenler:
Kuralı dokümante edin ve faturada açıkça gösterin ki müşteriler toplamları tahmin etmeden karşılaştırabilsin.
Önceden karar verin:
Ayrıca chargeback durumları için fatura PDF'leri, ödeme makbuzları ve kullanım kanıtını hızlı erişilebilir tutun. İçsel bir yönetim görünümü, kayıt dışı “mystery credit”lerin denetimi bozmadan önlenmesini sağlar.
İtirazları desteklemek için “bu API çağrısı gerçekleşti” ile “bu ücret oluşturuldu” arasındaki izleme zincirini tutun. Değişmez kullanım olaylarını ID, zaman damgası, müşteri/proje kimlikleri ve temel boyutlarla saklayın. Müşteri "neden bu kadar yüksek?" diye sorduğunda ortalamalar yerine belirli olaylara işaret edebilirsiniz.
İptaller öngörülebilir olmalı: gelecekteki tekrarlayan ücretleri durdurun, kullanımın dönemin sonuna kadar devam edip etmediğini belirleyin ve fatura edilmemiş kullanım için son fatura oluşturun. Hemen kapatma izni verirseniz, geç gelen olayları yine alıp faturalandırdığınızdan veya özellikle feragat ettiğinizden emin olun.
Faturalama, küçük bir hatanın finansal hata haline gelebileceği nadir alanlardan biridir. Yayınlamadan önce faturalamayı güvenlik hassasiyetli bir alt sistem gibi ele alın: erişimi kısıtlayın, her dış çağrıyı doğrulayın ve davranışınızı sonradan ispatlanabilir hale getirin.
Faturalama erişimi için net roller tanımlayarak başlayın. Yaygın bir ayrım: faturalama yöneticileri (ödeme yöntemlerini düzenleyebilir, krediler verebilir, plan değiştirebilir, ödemeyi yeniden deneyebilir) vs faturalama görüntüleyicileri (faturalar, kullanım ve ödeme geçmişini sadece görüntüler).
Bu izinleri uygulamanızda ve iç araçlarınızda açık hale getirin. Birden fazla workspace/hesap destekliyorsanız tenant sınırlarını her yerde zorlayın—özellikle fatura ve kullanım dışa aktarım uç noktalarında.
Kullanım takip ve sağlayıcı webhook'ları yüksek değerli hedeflerdir.
“Kimin neyi ne zaman ve neden değiştirdiğini” cevaplayabilecek ayrıntıda faturalama işlemlerini loglayın. Aktör kimliği, istek ID'leri, eski/yeni değerler ve ilgili nesnelere (müşteri, fatura, abonelik) bağlantılar dahil olsun. Bu loglar destek, itirazlar ve uyumluluk incelemeleri için gereklidir.
Bir sağlayıcı sandbox'ında uçtan uca test edin: abonelik değişiklikleri, prorasyon/krediler, başarısız ödemeler, iadeler, webhook teslim gecikmeleri ve yinelenen olaylar.
Faturalamaya özel izleme ekleyin: webhook hata oranı, fatura oluşturma gecikmesi, rating/toplama iş hataları ve ani kullanım sıçramaları için anomali uyarıları. /admin/billing altında küçük bir pano, lansman haftasında saatler kazandırabilir.
Kullanıma dayalı faturalamayı başlatmak bir anahtar açmak değil, bir düğmü yavaşça çevirmek gibidir. Amaç küçük başlamak, faturaların gerçeklikle uyuştuğunu kanıtlamak ve müşterileri ya da destek ekibini şaşırtmadan genişlemektir.
İlk olarak pilot bir grupla yayınlayın—tercihen sözleşmeleri basit ve yöneticileri yanıt veren müşteriler. Her fatura dönemi için sisteminizin ürettiğiyle ham kullanım ve fiyat kurallarına göre beklediğiniz nümerik değerleri karşılaştırın.
Pilot sırasında insan okunabilir bir mutabakat görünümü tutun: kullanım olayları zaman çizelgesi, toplanmış toplamlar ve nihai satır öğeleri. Bir şey yanlış görünürse cevaplayabilmelisiniz: Hangi olay? Hangi kural? Hangi fiyat versiyonu?
Geleneksel uptime grafikleri faturalama sorunlarını yakalamaz. Şunları izleyin ve uyarı kurun:
Bunları mühendislik ve operasyonun görebileceği şekilde yayın.
Destek ve mühendislik için en yaygın istekleri kapsayan runbook'lar oluşturun:
Runbook'ları kısa, aranabilir ve sürümlenmiş tutun.
Fiyat kurallarını veya meterleri değiştirdiğinizde bunu bir ürün yayını gibi ele alın: değişiklikleri ilan edin, yürürlüğe girme tarihlerini net tutun ve geçmiş kullanım üzerinde geriye dönük testler (backtest) çalıştırın.
Hızlandırmak isterseniz, sohbet tabanlı bir spesifikasyondan faturalama portalı ve yönetim araçları prototipi oluşturmanıza yardımcı olacak Koder.ai gibi bir vibe-coding platformu işe yarayabilir—hazır olduğunuzda kaynak kodunu dışa aktarabilirsiniz. Bu, genellikle ertelenen “yapıştırıcı” parçaları hızla kurmanıza yardımcı olur: iç mutabakat görünümleri, fatura geçmişi ekranları ve kullanım panoları.
Koder.ai’ın varsayılan yığını (web için React, backend için Go + PostgreSQL) burada tarif edilen mimariye iyi uyar: alım uç noktaları, toplama işleri, sürümlenmiş bir rating motoru ve /billing altındaki bir müşteri portalı. Planlama modu, anlık görüntüler ve geri alma özellikleri erken faturalama iterasyonlarını doğrularken daha güvenli hale getirebilir.
Sonraki adımlar için bkz. /pricing paketleme fikirleri ve /blog ilgili uygulama kılavuzları.
Öncelikle tek, denetlenebilir bir birim (olaylar, zaman, veri hacmi veya kapasite) tanımlayarak başlayın ve nelerin ücretlendirildiğini yazın.
Erken aşamada uç kuralları dahil edin (başarısız talepler, tekrar denemeler, saniye yerine dakika gibi minimum artışlar), çünkü bu seçimler ölçümleme, faturalar ve destek süreçlerini etkiler.
İyi bir kullanım tanımı şunlar olmalı:
Eğer depolanan olaylardan denetlenemiyorsa, itirazlarda savunması zor olur.
Birçok ürün anlık kullanım gösterse de hâlâ aylık fatura en öngörülebilir olanıdır.
Seçenekler:
Sahiplik bir ürün gereksinimidir:
Bu karar izinleri, fatura toplamalarını ve portaldeki “kullanım toplamları”nın ne anlama geldiğini belirler.
Müşterilerin tahmin edebilmesi için en basit yapıyı kullanın:
Müşteriler maliyeti tahmin etmekte zorlanıyorsa bir allowance veya temel abonelik ekleyin.
Evet—çoğu zaman temel ücret + kullanım en öngörülebilirdir.
Temel ücret destek, barındırma veya garanti edilen bir asgariyi karşılar; kullanım ise değerle doğru orantılı artar. Temeli müşterinin işaret edebileceği bir faydayla ilişkilendirin (“5 kullanıcı dahildir” veya “20k çağrı dahildir”).
En azından şunları dahil edin:
customer_id (veya account_id)timestamp (kullanımın gerçekleştiği zaman)quantity (faturalandırılacak birim)event_type (hangi meter olduğu)Olayları idempotent yapın:
event_id (veya deterministik bir idempotency anahtarı) zorunlu kılınBunlar yoksa normal tekrar davranışı çifte sayım ve fazla faturalamaya yol açar.
Politikanızı seçin ve tutarlı uygulayın:
supersedes_event_id ile kaydedinGeçmiş satırları sessizce güncellemeyin; izlenebilirlik güven ve denetimler için önemlidir.
Şeffaflığı artırmak için yeterli bilgiyi gösterin:
Destek yollarını hesap, fatura ID'si, zaman aralığı ve kullanım anlık görüntüsü ile önceden doldurun.
Sadece raporlayacağınız veya fiyatlandıracağınızsa ek boyutlar (region, feature, endpoint, resource_id) ekleyin—sonradan bu boyutların anlamını değiştirmek zordur.