Refill ve Düşüş Yönetimi: Telafi Talepleri İçin Tam Rehber

Takipçi veya etkileşim sayısında teslimat sonrasında azalma yaşanması “düşüş” olarak adlandırılır. Refill ise desteklenen servislerde, belirli koşullar karşılandığında bu kaybın telafi edilmesi için oluşturulan taleptir. Refill her servis ve her sipariş için otomatik bir hak değildir; servis özelliği, sipariş durumu, hedef bağlantı ve talep zamanı birlikte değerlendirilir.

Bu rehber, gerçek bir düşüşün nasıl ölçüleceğini, refill uygunluğunun nasıl kontrol edileceğini, telafi talebinin neden reddedilebileceğini ve destek ekibine hangi kanıtların gönderilmesi gerektiğini açıklar.

Düşüş nedir, ne değildir?

Gerçek düşüş nasıl tanımlanır?

Bir siparişin teslimatı tamamlandıktan sonra hedef sayaçta kalıcı azalma görülmesi düşüş olabilir. Ancak mevcut toplamın sipariş miktarından düşük görünmesi tek başına gerçek düşüşü kanıtlamaz. Başlangıç sayacı, organik hareketler, başka kampanyalar ve platform sayaç gecikmeleri değerlendirilmelidir.

Örneğin start count 10.000, sipariş miktarı 1.000 ve Completed sonrası görülen değer 10.850 ise ilk bakışta 150 eksik görünebilir. Aynı dönemde 150 mevcut takipçi ayrıldıysa servis teslimatı tamamlanmış olsa bile toplam 10.850’de kalabilir. Bu nedenle yalnız toplam fark üzerinden kesin sonuç çıkarılmaz.

Platform sayaç gecikmesi düşüş sayılır mı?

Bazı platformlar sayaçları uygulama, web ve analiz ekranlarında farklı zamanlarda güncelleyebilir. Anlık bir azalma veya geçici görünüm farkı, kalıcı düşüş olmayabilir. Sayfayı yenileyin, farklı görünümden kontrol edin ve kısa bir gözlem aralığı kullanın.

Organik kayıp nasıl ayırt edilir?

Hedef hesap doğal olarak takipçi veya etkileşim kaybedebilir. İçerik silinmesi, hesap temizliği, kullanıcı davranışı ve platform politikaları toplam sayacı etkiler. Sipariş döneminde düzenli kayıt tutmak, teslimat kaynaklı değişimle organik hareketi ayırmaya yardımcı olur.

Refill desteği nasıl kontrol edilir?

Serviste refill özelliği var mı?

Sipariş verdiğiniz servisin açıklamasında veya servis bilgisinde refill desteğini kontrol edin. API servis listesinde refill alanı true ise servis telafi talebini destekleyebilir. false ise refill beklenmemelidir.

Refill desteği bulunması, her koşulda tamamlanacağı anlamına gelmez. Refill süresi, hedef görünürlüğü, sipariş durumu ve servis kuralları ayrıca kontrol edilir.

Sipariş durumu refill için uygun mu?

RoketBayim API dokümantasyonuna göre refill talebi için siparişin Completed veya Partial durumda olması gerekir. Pending, Processing veya Canceled siparişler uygun olmayabilir. Aktif siparişte görülen geçici sayaç değişimini refill ile çözmeye çalışmayın; önce ana siparişin terminal duruma ulaşmasını bekleyin.

Hedef bağlantı hangi durumda olmalı?

Hesap veya içerik dışarıdan erişilebilir kalmalıdır. Kullanıcı adının değiştirilmesi, hesabın gizliye alınması, gönderinin silinmesi ya da arşivlenmesi refill işlemini engelleyebilir. Servis, artık erişemediği bir hedefe telafi gönderemez.

Düşüşü doğru ölçme yöntemi

Hangi veriler kaydedilmeli?

• Order ID
• Servis adı veya servis ID
• Hedef bağlantı
• Sipariş miktarı
• Start count
• Completed veya Partial zamanı
• Teslimat sonrası gözlenen sayaçlar ve tarihleri
• Varsa aynı hedefte çalışan diğer kampanyalar

Bu kayıtlar olmadan “500 düştü” gibi genel bir ifade doğrulanması zor bir iddiadır. Tarihli ekran görüntüleri ve panel kaydı, destek incelemesini hızlandırır.

Ölçüm aralığı nasıl seçilmeli?

Servis açıklamasında refill veya garanti süresi belirtiliyorsa gözlemi bu dönem içinde yapın. Çok kısa aralıklarla anlık değişimleri raporlamak yerine kalıcı eğilimi izleyin. Ancak servis süresini kaçıracak kadar uzun beklemeyin.

Her gün aynı saat civarında sayaç kaydetmek karşılaştırmayı kolaylaştırır. Uygulama ve web görünümü farklıysa aynı kaynağı kullanmaya devam edin.

Refill talebi oluşturma

Talep öncesi kontrol listesi

API üzerinden refill nasıl oluşturulur?

API kullanan bayiler tek sipariş için action=refill ve order parametresi gönderebilir. Birden fazla uygun sipariş için orders parametresi virgülle ayrılmış olarak kullanılabilir.

POST https://roketbayim.com/api/v2
key=your_api_key
action=refill
order=12345

Başarılı yanıtta refill ID ve durum dönebilir. Bu refill ID daha sonraki takip ve destek işlemleri için saklanmalıdır.

Refill durumları

Refill talebi neden reddedilir?

Sipariş veya refill kimliği yanlış olabilir

Yanlış order ID, hesabınıza ait olmayan sipariş veya geçersiz refill ID talebin reddedilmesine yol açar. Kimlikleri elle yazarken rakam atlamadığınızdan emin olun. Destek talebine ekran görüntüsüyle birlikte kopyalanmış ID eklemek hatayı azaltır.

Sipariş durumu uygun olmayabilir

Pending veya Processing sipariş için refill talebi erken olabilir. Canceled sipariş de telafi için uygun kabul edilmeyebilir. Ana siparişin nihai durumunu kontrol edin.

Servis refill desteklemiyor olabilir

Benzer isimli servislerin refill özellikleri farklı olabilir. Daha önce kullandığınız başka bir serviste refill bulunması, bu siparişte de bulunduğu anlamına gelmez. Sipariş kaydındaki gerçek servis bilgisini esas alın.

Refill dönemi geçmiş olabilir

Servis belirli bir telafi dönemi sunuyorsa talep bu süre içinde oluşturulmalıdır. Süre sona erdikten sonra görülen düşüşler kapsam dışında kalabilir. Kesin koşul için servis açıklamasını kontrol edin.

Hedef bağlantı değişmiş olabilir

Kullanıcı adı değişikliği, hesap gizliliği, içerik silme veya arşivleme hedefin doğrulanmasını engeller. Refill talebinden önce bağlantıyı gizli pencerede açın.

Birden fazla refill talebi yönetimi

Aynı sipariş için tekrar talep ne zaman oluşturulmalı?

Mevcut refill pending iken yeni talep göndermeyin. Önce refill durumunu takip edin. Completed sonrasında yeniden düşüş yaşanırsa servis süresi ve koşulları içinde yeni talebin mümkün olup olmadığını kontrol edin.

Her talebin refill ID, oluşturma zamanı, durumu ve ilgili order ID kaydını tutun. Bu geçmiş, tekrarlayan düşüşün değerlendirilmesini kolaylaştırır.

Çoklu refill yanıtları nasıl okunur?

Birden fazla sipariş için oluşturulan taleplerde her sipariş ayrı sonuç döndürebilir. Bazıları completed, bazıları rejected olabilir. Tüm grubu tek bir başarı veya hata olarak değerlendirmeyin.

Refill tamamlandı fakat sayaç artmadıysa

Önce görünümü yenileyin

Platform sayaçları gecikmeli güncellenebilir. Uygulama ve web görünümünü karşılaştırın, doğru hedefte olduğunuzu kontrol edin ve kısa bir gözlem süresi kullanın.

Doğal düşüş devam ediyor olabilir

Refill teslim edilirken aynı anda yeni kayıplar yaşanabilir. Toplam sayaç değişmese bile telafi işlemi gerçekleşmiş olabilir. Tarihli sayaç kaydı ve başka kampanyalar bu noktada önemlidir.

Destek için kanıt hazırlayın

Order ID, refill ID, hedef bağlantı, refill durumunun ekran görüntüsü ve hedef sayaç kayıtlarını tek talepte paylaşın. “Refill olmadı” gibi genel mesaj yerine tarih ve sayılarla açıklama yapın.

Refill sırasında yapılmaması gerekenler

• Hesabı gizliye almak veya kullanıcı adını değiştirmek.
• Hedef gönderiyi silmek, arşivlemek veya bağlantıyı değiştirmek.
• Pending refill varken aynı sipariş için tekrar talep göndermek.
• Aynı bağlantıya yeni ve çakışan siparişler açmak.
• Start count ve tarih kaydı olmadan yalnız mevcut toplamla düşüş hesaplamak.
• Servis koşulunu okumadan refill garantisi varsaymak.

Kurumsal düşüş takip düzeni

Ajanslar ve bayiler, refill işlemlerini ayrı bir takip tablosunda yönetebilir. Her satırda müşteri referansı, order ID, servis, hedef link, start count, teslimat tarihi, refill süresi, ölçülen düşüş, refill ID ve son durum bulunmalıdır.

Bu düzen, aynı müşteri için mükerrer talebi önler ve destek ekibine eksiksiz bilgi sağlar. API entegrasyonunda refill ve refill_status yanıtlarını aynı yerel kayda bağlamak gerekir.

Destek talebi örneği nasıl yapılandırılmalı?

Talebinizde aşağıdaki sırayı kullanabilirsiniz:

1. Order ID ve varsa refill ID
2. Servis adı
3. Hedef bağlantı
4. Sipariş ve refill durumları
5. Start count, teslimat sonrası sayaç ve güncel sayaç
6. Ölçümlerin tarihleri
7. Hesabın açık ve kullanıcı adının değişmemiş olduğuna dair bilgi

Parola veya API anahtarı destek talebine eklenmemelidir. İnceleme için order ID ve refill ID yeterli teknik referanslardır.

Hızlı karar özeti

• Sipariş hâlâ aktif: Refill oluşturmayın; ana siparişin tamamlanmasını bekleyin.
• Servis refill desteklemiyor: Telafi beklemeyin; servis koşulunu esas alın.
• Hedef gizli veya silinmiş: Önce erişim sorununu çözün; destek ekibine değişikliği bildirin.
• Refill pending: Yeni talep açmayın, mevcut refill ID’yi takip edin.
• Refill rejected: Order ID, durum, servis desteği ve hedef görünürlüğünü kontrol edin.
• Refill completed ama sonuç belirsiz: Tarihli sayaç kayıtlarını karşılaştırıp tek destek talebi oluşturun.

Teknik endpoint ve güncel parametreler için RoketBayim API dokümantasyonunu inceleyebilirsiniz.

Refill uygunluk değerlendirme örnekleri

Uygun talep örneği

Sipariş Completed durumunda, servis refill destekli, hedef profil herkese açık ve kullanıcı adı değişmemiştir. Kullanıcı teslimat sonrası sayacı tarihli olarak kaydetmiş ve servis koşulu içindeki kalıcı düşüşü göstermiştir. Order ID ile oluşturulan tek refill talebi takip için en sağlıklı yöntemdir.

Erken talep örneği

Sipariş Processing durumundayken sayaç kısa süre azalmış olabilir. Ana teslimat hâlâ devam ettiği için refill oluşturmak doğru değildir. Önce siparişin terminal duruma ulaşması, ardından teslimat sonucunun ölçülmesi gerekir.

Uygun olmayan hedef örneği

Completed siparişten sonra kullanıcı adının değiştirilmesi veya hesabın gizliye alınması, servis refill desteklese bile hedef doğrulamasını engelleyebilir. Önce erişim sorunu çözülmeli ve değişiklik destek talebinde açıkça belirtilmelidir.

Çakışan kampanya örneği

Aynı profile başka bir sağlayıcıdan eş zamanlı takipçi siparişi verildiyse hangi teslimatın düştüğü kesin olarak ayrıştırılamaz. Bu nedenle refill döneminde aynı sayaç türünde yeni kampanya başlatmamak gerekir.

Refill performansı nasıl raporlanmalı?

Ajanslar müşteriye yalnız “refill yapıldı” demek yerine talep tarihi, refill ID, başlangıç durumu, tamamlanma durumu ve gözlenen sayaç değişimini raporlamalıdır. Rejected sonuçlarda teknik nedeni kesin olarak bilmiyorsanız tahmin yürütmeyin; doğrulanan order ve servis bilgilerini paylaşın.

Aylık operasyon raporunda toplam refill talebi, completed ve rejected sayıları ile en sık ret nedenlerini takip etmek, yanlış servis seçimi veya hedef görünürlüğü gibi tekrar eden süreç hatalarını ortaya çıkarır.

Raporlama sırasında müşterilerin kullanıcı adı, parola veya API anahtarı gibi hassas bilgilerini saklamayın. Teknik takip için order ID, refill ID, servis ve tarih bilgisi yeterlidir. Gereksiz kişisel veriyi azaltmak hem güvenliği hem operasyon kalitesini artırır.

Her sonucu düzenli olarak arşivleyin.