Kullanıma dayalı fiyatlandırma uygulaması: neyi ölçmelisiniz, toplamları nerede hesaplamalısınız ve faturalar çıkmadan önce faturalama hatalarını yakalayan mutabakat kontrolleri.
Kullanım faturalaması, faturadaki sayı ürününüzün gerçekte teslim ettiğinden farklı olduğunda bozulur. Fark ilk başta çok küçük olabilir (birkaç eksik API çağrısı), sonra iadelere, öfkeli destek taleplerine ve panolara güvenmeyen bir finans ekibine dönüşebilir.
Nedenler genelde öngörülebilirdir. Olaylar, bir servis kullanım bildirmeden önce çöktüğü, bir kuyruğun kapalı olduğu veya istemcinin çevrimdışı olduğu için kaybolur. Olaylar iki kez sayılabilir çünkü yeniden denemeler oldu, worker'lar aynı mesajı tekrar işledi veya bir içe aktarma işi tekrar çalıştı. Zaman da kendi sorunlarını getirir: sunucular arası saat kayması, saat dilimleri, yaz saati uygulamaları ve geç gelen olaylar kullanımın yanlış faturalama dönemine düşmesine neden olabilir.
Kısa bir örnek: AI üretimi başına ücret alan bir sohbet ürünü, bir istek başladığında bir olay, tamamlandığında başka bir olay üretebilir. Başlangıç olayından faturalandırırsanız başarısızlıklar için ücret alabilirsiniz. Bitirme olayından faturalandırırsanız, son geri çağrı hiç gelmediğinde kullanım kaçabilir. Eğer her ikisi de faturalandırılırsa çift ücretlendirme olur.
Birden fazla kişinin aynı sayılara güvenmesi gerekir:
Hedef sadece doğru toplamlar değildir. Açıklanabilir faturalar ve hızlı itiraz işleme hedeflenmelidir. Bir kalem kalemi ham kullanıma kadar izleyemiyorsanız, bir kesinti faturalamanızı tahmine dönüştürebilir ve işte o zaman faturalama hataları olay haline gelir.
Bir soruyla başlayın: tam olarak ne için ücret alıyorsunuz? Birimi ve kuralları bir dakikada açıklayamıyorsanız, sistem tahmin etmeye başlar ve müşteriler fark eder.
Her sayaç için bir birincil faturalandırılabilir birim seçin. Yaygın seçenekler API çağrıları, istekler, tokenler, hesaplama dakikaları, GB depolama, GB transfer veya koltuk sayısıdır. Karışık birimlerden (örneğin “aktif kullanıcı dakikaları”) kaçının, gerçekten ihtiyaç yoksa. Denetlenmesi ve açıklanması daha zordur.
Kullanım sınırlarını tanımlayın. Kullanımın ne zaman başladığı ve bittiği konusunda net olun: bir deneme metered aşımı içerir mi yoksa bir sınıra kadar ücretsiz mi? Bir hoşgörü dönemi sunuyorsanız, hoşgörü sırasındaki kullanım daha sonra faturalandırılır mı yoksa affedilir mi? Plan değişiklikleri kafa karışıklığının zirve yaptığı yerdir. Prorata yapar mısınız, hakları hemen sıfırlar mısınız yoksa değişikliği bir sonraki fatura döneminde mi uygularsınız? Karar tutarlı, belgelenmiş ve test edilebilir olmalı.
Yuvarlama ve minimumları yazılı hale getirin. Örneğin: en yakın saniyeye/dakikaya/1.000 tokene yuvarla; günlük minimum ücret uygula; veya 1 MB gibi bir minimum faturalandırılabilir artış zorunlu kıl. Bu tür küçük kurallar büyük “neden ücretlendirildim?” talepleri yaratır.
Erken kararlaştırılması gereken kurallar:
Örnek: bir ekip Pro planında iken ay ortasında yükseltme yaptı. Eğer yükseltmede hakları sıfırlıyorsanız, bir ay içinde fiilen iki ücretsiz hak almış olabilirler. Sıfırlamıyorsanız, yükseltme için cezalandırıldıklarını hissedebilirler. Her iki seçim de geçerli olabilir, ancak tutarlı, belgelenmiş ve test edilebilir olmalıdır.
Bir faturalama olayının ne sayılacağını belirleyin ve bunu veri olarak yazın. Eğer yalnızca olaylardan “ne oldu” hikayesini tekrar oynatamıyorsanız, itirazlar sırasında tahmin etmek zorunda kalırsınız.
Sadece “kullanım oldu”yu takip etmeyin. Müşterinin ne ödemesi gerektiğini değiştiren olayları da kaydetmelisiniz.
Çoğu faturalama hatası bağlam eksikliğinden gelir. Destek, finans ve mühendisliğin daha sonra soruları cevaplayabilmesi için sıkıcı alanları şimdi yakalayın.
Destek kalitesinde ek metadata da işe yarar: istek ID’si veya trace ID, bölge, uygulama sürümü ve uygulanan fiyatlandırma kuralı sürümü. Bir müşteri “2:03’te iki kez ücretlendirildim” dediğinde, bu alanlar ne olduğunu kanıtlamanıza, güvenli şekilde tersine çevirmenize ve tekrarını önlemenize yarar.
İlk kural basit: faturalanabilir olayları işi gerçekten yapan sistemden yayınlayın. Çoğu durumda bu tarayıcı veya mobil uygulama değil, sunucunuzdur.
İstemci tarafı sayıcılar sahteye kolayca açık ve kaybolmaya müsaittir. Kullanıcılar istekleri engelleyebilir, tekrar oynatabilir veya eski kod çalıştırabilir. Kötü niyet olmasa bile mobil uygulamalar çökebilir, saatler kayabilir ve yeniden denemeler olabilir. Eğer istemci sinyali okumanız gerekiyorsa, bunu fatura olarak değil ipucu olarak değerlendirin.
Pratik yaklaşım, geri dönüşü olmayan bir noktayı geçtiğinizde kullanımı yayınlamaktır: bir kaydı kalıcı hale getirdiğinizde, bir iş tamamlandığında veya ürettiğinizi kanıtlayabileceğiniz bir yanıt verdiğinizde. Güvenilir yayın noktalarına örnekler:
Çevrimdışı mobil ana istisnadır. Eğer bir Flutter uygulaması bağlantı olmadan çalışmak zorundaysa, kullanımı yerelde takip edip sonra yükleyebilir. Kontrollere ekleyin: benzersiz olay ID’si, cihaz ID’si ve monoton sıra numarası ekleyin; sunucu hesap durumunu, plan limitlerini, yinelenen ID’leri ve imkansız zaman damgalarını doğrulasın. Uygulama yeniden bağlandığında sunucu olayları idempotent kabul etmeli ki yeniden denemeler çift faturalamaya yol açmasın.
Olay zamanlaması, kullanıcıların ne görmeyi beklediğine bağlıdır. API çağrıları için gerçek zamanlı uygun olabilir. Birkaç dakikalık gecikme genelde yeterli ve daha ucuzdur. Yüksek hacimli sinyaller için toplu işleme uygun olabilir ama gecikmeler konusunda net olun ve geç gelen verinin geçmiş faturaları sessizce değiştirmemesini sağlayacak aynı doğruluk kurallarını kullanın.
Size ileride fayda sağlayacak gibi görünen iki şeye ihtiyacınız var: değiştirilemez ham olaylar (ne oldu) ve türetilmiş toplamlar (ne faturalandırdınız). Ham olaylar hakikattir. Toplamalar ise hızlı sorgulayıp müşteriye açıklayacağınız ve faturaya çevireceğiniz veridir.
Toplamları hesaplayabileceğiniz iki yaygın yer vardır. Veritabanında hesaplamak (SQL işleri, materialize tablolar, zamanlanmış sorgular) ilk etapta işletmesi daha basit ve mantığı verinin yanına yakın tutar. Ayrı bir toplayıcı servis (olayları okuyup rollup yazan küçük bir worker) versiyonlamayı, test etmeyi ve ölçeklemeyi kolaylaştırır ve ürünler arası tutarlı kuralları zorlayabilir.
Ham olaylar sizi hatalardan, iadelerden ve itirazlardan korur. Toplamalar ise fatura ve dashboard için yavaş sorguların ve pahalı hesapların önüne geçer. Sadece agregat saklarsanız, yanlış bir kural geçmişi kalıcı bozabilir.
Pratik bir kurulum:
Toplama pencerelerini açık seçin. Bir fatura saat dilimi seçin (çoğunlukla müşterinin saat dilimi veya herkes için UTC) ve buna sadık kalın. “Gün” sınırları saat dilimleriyle değişir ve müşteriler kullanımın günler arasında kaymasına dikkat eder.
Geç ve sıralama dışı olaylar normaldir (mobil çevrimdışı, yeniden denemeler, kuyruk gecikmeleri). Geç gelen bir olay yüzünden geçmiş bir faturayı sessizce değiştirmeyin. Kapatma-ve-dondurma kuralı kullanın: bir fatura dönemi faturalandığında, düzeltmeleri bir sonraki faturada ayarlama olarak yazın ve açık bir sebep belirtin.
Örnek: API çağrıları aylık faturalandırılıyorsa, dashboardlar için saatlik sayımlar, uyarılar için günlük sayımlar ve faturalama için dondurulmuş aylık toplamlar oluşturabilirsiniz. Eğer 200 çağrı iki gün geç gelirse, bunları kaydedin ama bunları önceki ayın faturasını yeniden yazmak yerine bir sonraki ayın faturasında +200 ayarlama olarak faturalandırın.
Çalışır durumda bir kullanım hattı büyük ölçüde veri akışıdır ancak güçlü korumalarla. Sıralamayı doğru alırsanız, daha sonra fiyatlandırmayı değiştirmek zorunda kalırsanız her şeyi elle yeniden işlemeye gerek kalmaz.
Bir olay geldiğinde hemen doğrulayın ve normalleştirin. Gerekli alanları kontrol edin, birimleri dönüştürün (bayttan GB’ye, saniyeden dakikaya) ve zaman damgalarını açık bir kurala göre sınırlayın (olay zamanı vs alım zamanı). Bir şey geçersizse, sebep ile birlikte reddedilmiş olarak kaydedin; sessizce atmayın.
Normalleştirmeden sonra ekleme-yalnızca zihniyetini koruyun ve tarihi yerinde “düzeltmeyin”. Ham olaylar sizin gerçek kaynak verinizdir.
Bu akış çoğu ürün için işe yarar:
Sonra fatura sürümünü dondurun. “Dondurmak” şunu ifade eder: hangi ham olayların, hangi dedupe kuralının, hangi agregasyon kodu sürümünün ve hangi fiyatlandırma kurallarının bu satırları ürettiğini cevaplayan bir denetim izi tutmak. Daha sonra fiyat değiştirir veya bir hata düzeltirseniz, yeni bir fatura revizyonu oluşturun; sessiz bir düzenleme yapmayın.
Çift faturalama ve eksik kullanım genelde aynı kök sorundan gelir: sisteminiz bir olayın yeni mi, yinelenmiş mi yoksa kayıp mı olduğunu ayırt edemez. Bu, zekice faturalama mantığından ziyade olay kimliği ve doğrulama etrafında sıkı kontrollerle ilgilidir.
Idempotency anahtarları ilk savunma hattıdır. Anahtar, HTTP isteği için değil, gerçek dünya aksiyonu için kararlı olmalıdır. İyi bir anahtar deterministik ve faturalandırılabilir birim başına benzersizdir; örneğin: tenant_id + billable_action + source_record_id + time_bucket (sadece birim zaman tabanlıysa time_bucket kullanın). İlk kalıcı yazmada bunu benzersiz kısıtlama ile zorlayın ki tekrarlar yere düşmesin.
Yeniden denemeler ve zaman aşımı normaldir, bu yüzden bunlara göre tasarlayın. Bir istemci 504 sonrası aynı olayı tekrar gönderebilir. Kuralınız: tekrarları kabul edin ama iki kez saymayın. Alma işlemini (ingest) saymadan ayırın: bir kez alın (idempotent), sonra depolanan olaylardan toplayın.
Doğrulama, “imkansız kullanım”un toplamları bozmasını engeller. Hem alımda hem de toplamada doğrulayın, çünkü hatalar her iki yerde de olabilir.
Eksik kullanım fark edilmesi en zor olandır; bu yüzden alım hatalarını birinci sınıf veri olarak ele alın. Başarısız olayları başarılı olanlardan ayrı saklayın (aynı alanlarla), ayrıca bir hata nedeni ve yeniden deneme sayısı ekleyin.
Mutabakat kontrolleri, “çok fazla ücret aldık” veya “kullanımı kaçırdık” hatalarını müşteriler fark etmeden önce yakalayan sıkıcı ama hayat kurtarıcı korunmalardır.
İki yerde aynı zaman penceresini mutabakatla başlayın: ham olaylar ve toplanmış kullanım. Belirli bir pencere seçin (örneğin, dün UTC’de), sonra sayıları, toplamları ve benzersiz ID’leri karşılaştırın. Küçük farklar olabilir (geç gelen olaylar, yeniden denemeler) ama bunlar bilinen kurallarla açıklanmalı, gizemli olmamalı.
Sonra faturaladığınızla fiyatladığınız arasındaki uyumu kontrol edin. Bir fatura, fiyatlandırılmış kullanım anlık görüntüsünden yeniden üretilebilir olmalıdır: tam kullanım toplamları, kullanılan fiyat kuralları, para birimi ve yuvarlama. Eğer hesaplamayı tekrar çalıştırdığınızda fatura değişiyorsa, elinizde fatura değil, bir tahmin var demektir.
Günlük sağduyu kontrolleri “yanlış matematik” olmayan ama “garip gerçeklik” olan sorunları yakalar:
Bir problem bulduğunuzda bir backfill sürecine ihtiyacınız olacak. Backfill’ler kasıtlı ve kaydedilmiş olmalı. Ne değişti, hangi pencere, hangi müşteriler, kim tetikledi ve sebep kaydedilmeli. Düzeltmeleri muhasebe girişleri gibi ele alın, sessiz düzenlemeler gibi değil.
Basit bir itiraz iş akışı desteği sakin tutar. Bir müşteri bir ücreti sorguladığında, aynı anlık görüntü ve fiyat sürümü ile ham olaylardan faturalarını yeniden üretebilmelisiniz. Bu belirsiz şikayeti düzeltilebilir bir hataya çevirir.
Çoğu faturalama yangını karmaşık matematikten değil, yalnızca en kötü zamanda bozulan küçük varsayımlardan gelir: ay sonu, yükseltme sonrası veya yeniden deneme fırtınası sırasında. Dikkatli kalmak çoğunlukla zaman, kimlik ve kurallar için bir gerçek (single source of truth) seçmek ve buna sadık kalmaktır.
Bunlar olgun ekiplerde bile tekrar tekrar görünür:
Örnek: bir müşteri 20’sinde yükseltme yapar ve olay işleyiciniz bir günün verisini bir zaman aşımı sonrası yeniden işler. Idempotency anahtarları ve kural sürümlenmesi yoksa, 19.’u çiftleyebilir ve 1–19 arasını yeni oranla fiyatlayabilirsiniz.
Basit bir örnek: Acme Co adlı bir müşteri üç sayaçla faturalandırılıyor: API çağrıları, depolama (GB-gün) ve premium özellik çalıştırmaları.
Uygulamanızın bir gün içinde (5 Ocak) ürettiği olaylara bakın. Hikayeyi daha sonra kolayca yeniden kurmayı sağlayan alanlara dikkat edin: event_id, customer_id, occurred_at, meter, quantity ve idempotency anahtarı.
{"event_id":"evt_1001","customer_id":"cust_acme","occurred_at":"2026-01-05T09:12:03Z","meter":"api_calls","quantity":1,"idempotency_key":"req_7f2"}
{"event_id":"evt_1002","customer_id":"cust_acme","occurred_at":"2026-01-05T09:12:03Z","meter":"api_calls","quantity":1,"idempotency_key":"req_7f2"}
{"event_id":"evt_1003","customer_id":"cust_acme","occurred_at":"2026-01-05T10:00:00Z","meter":"storage_gb_days","quantity":42.0,"idempotency_key":"daily_storage_2026-01-05"}
{"event_id":"evt_1004","customer_id":"cust_acme","occurred_at":"2026-01-05T15:40:10Z","meter":"premium_runs","quantity":3,"idempotency_key":"run_batch_991"}
Ay sonunda agregasyon işi ham olayları customer_id, meter ve fatura dönemi bazında gruplar. Ocak toplamları ay boyunca toplananların toplamıdır: API çağrıları 1.240.500, depolama GB-gün 1.310.0 ve premium çalıştırmalar 68 olarak gelir.
Şimdi 2 Şubat’ta geç bir olay gelirse ama Jan 31’e aitse (mobil istemci çevrimdışıyken), çünkü occurred_at ile (alım zamanı değil) agregasyon yapıyorsunuz, Ocak toplamları değişir. Ya (a) bir sonraki faturada bir ayarlama satırı oluşturursunuz ya da (b) politikanız izin veriyorsa Ocak’ı yeniden düzenlersiniz.
Mutabakat burada bir hatayı yakalar: evt_1001 ve evt_1002 aynı idempotency_key (req_7f2) ile paylaşıyor. Kontrol “bir istek için iki faturalanabilir olay” diye işaretler ve faturalamadan önce birini çoğaltma olarak işaretler.
Destek basitçe açıklayabilir: “Aynı API isteği bir yeniden deneme nedeniyle iki kez raporlandı. Çoğaltılmış kullanım olayı kaldırıldı, bu yüzden bir kez ücretlendirildiniz. Düzeltilmiş toplamı yansıtan bir ayarlama faturanızda yer alıyor.”
Faturalamayı açmadan önce kullanım sisteminizi küçük bir muhasebe defteri gibi ele alın. Aynı ham veriyi yeniden oynatıp aynı toplamları elde edemiyorsanız, gece yarıları “imkansız” ücretlerin peşinden koşarsınız.
Bu kontrol listesini son kapı olarak kullanın:
Pratik bir test: bir müşteri seçin, son 7 günün ham olaylarını temiz bir veritabanına oynatın, sonra kullanım ve bir fatura üretin. Sonuç prodüksiyondan farklıysa, probleminiz matematik değil deterministiklik problemidir.
İlk sürümü bir pilot gibi ele alın. Bir faturalandırılabilir birim (örneğin “API çağrıları” veya “GB depolama”) ve beklediğinizle gerçekte faturaladığınız arasındaki bir mutabakat raporu seçin. Bu tam döngü boyunca stabil kaldığında, bir sonraki birimi ekleyin.
Destek ve finansı ilk günden başarılı kılmak için onlara hem ham olayları hem de faturaya çıkan hesaplanan toplamları gösteren basit bir dahili sayfa verin. Bir müşteri “neden ücretlendirildim?” dediğinde, cevabı dakikalar içinde veren tek bir ekranınız olsun.
Gerçek parayı tahsil etmeden önce gerçeği yeniden oynatın. Staging verisi ile bir aylık kullanım simülasyonu yapın, agregasyonu çalıştırın, faturalar oluşturun ve küçük bir müşteri örneklemesi için manuel sayımla beklenen sonuçları karşılaştırın. Düşük, düzensiz ve sabit örüntülere sahip birkaç müşteri seçin ve ham olaylar, günlük agregatlar ve fatura satırları arasında tutarlılık doğrulayın.
Eğer metreleme servisini inşa ediyorsanız, Koder.ai (koder.ai) gibi bir prototipleme platformu dahili admin UI ve Go + PostgreSQL backend prototipi için hızlı bir yol olabilir; mantık stabil olduğunda kaynak kodunu export edebilirsiniz.
Faturalama kuralları değiştiğinde riski azaltan bir sürüm rutini uygulayın:
Kullanım faturalaması, faturadaki toplamın ürünün gerçekten sağladığıyla uyuşmaması durumunda bozulur.
Yaygın nedenler şunlardır:
Çözüm, “daha iyi matematik”ten ziyade olayları güvenilir, tekrar edilemez ve baştan sona açıklanabilir hale getirmektir.
Her metre için bir net birim seçin ve onu bir cümleyle tanımlayın (örneğin: “başarılı bir API isteği” veya “tamamlanmış bir AI üretimi”).
Sonra müşterilerin itiraz edeceği kuralları yazın:
Birim ve kuralları hızlıca açıklayamıyorsanız, daha sonra denetlemek ve desteklemek zor olur.
Tüketimi değil, parayı etkileyen tüm olayları izleyin.
En azından:
Bunlar, plan değiştiğinde veya düzeltme gerektiğinde faturanın yeniden üretilebilir olmasını sağlar.
Sonradan tartışmayı önleyecek bağlamı yakalayın:
occurred_at UTC zaman damgası ve ayrı bir alım zaman damgasıDestek için faydalı ek bilgiler: isteK/trace ID, bölge, uygulama sürümü ve uygulanan fiyatlandırma kuralları sürümü.
Faturalandırılabilir olayları gerçekten işi yapan sistemden yayınlayın—çoğu durumda bu backend’dir, tarayıcı veya mobil uygulama değil.
İyi yayın noktaları, geri dönüşü olmayan anlar olmalıdır, örneğin:
Çevrimdışı mobil istisnası varsa, istemciden gelen sinyal bir ipucu olarak, sunucu doğrulamasıyla birlikte kullanılmalıdır.
Her ikisini de kullanın:
Sadece toplama saklarsanız, yanlış bir kural geçmişi kalıcı olarak bozabilir. Sadece ham olay saklarsanız, faturalar ve paneller yavaş ve maliyetli olur.
Tekrar faturalamayı önlemek için tasarımla çoğaltmaları imkansız hale getirin:
Böylece bir timeout+yeniden deneme çift faturalamaya dönüşmez.
Açık bir politika seçin ve otomatikleştirin.
Pratik varsayılan:
occurred_at (olay zamanı) kullanın, alım zamanı değilBöylece geçmiş faturaların sessizce değişmesi önlenir.
Her gün küçük, sıkıcı kontroller çalıştırın—bunlar pahalı hataları erken yakalar.
Yararlı mutabakatlar:
Farklar geç gelen olaylar veya dedupe gibi bilinen kurallarla açıklanmalı, gizemli deltalardan olmamalıdır.
Faturaları açıklanabilir kılmak için tutarlı bir iz bırakın:
Bir destek bileti geldiğinde cevaplanması gerekenler:
Bu, itirazları hızlı bir aramaya indirger.