Make ve CRM: yinelenen kayıtsız talep akışı

Bir form “gönderildi” diyebilir, ancak talep CRM'ye hiç ulaşmayabilir. Tersi de maliyetlidir: yeniden deneme iki kayıt, iki arama ve ödenebilir görünen iki sonuç oluşturur. Sağlam bir entegrasyon üç ayrı soruyu yanıtlar: Talep korundu mu, tek bir iş kaydı oluştu mu ve bu kayıt daha sonra reklamverenin koşullarına göre kabul edildi mi?

Bu rehber, Make ve kendi CRM'sini kullanan Avrupa'daki bir hizmet işletmesi için eğitim amaçlı tasarımdır. Kurulmuş bir AffiliateCore bağlayıcısı değildir. Kişisel veri göndermeden önce müşterinin ülkesini, hesap uygunluğunu, veri işleme sözleşmesini ve CRM yetkilerini doğrulayın. Örnekler sıradan hizmet talepleridir; kumar oyuncusu edinimi içermez. TRY tutarları bağımsız varsayımlardır; Make fiyatı veya döviz çevrimi değildir.

1. Talebe kalıcı bir kimlik verin

Form sunucusu gönderimi kabul ettiğinde submission_id oluştursun. Aynı gönderimin tesliminde ve yeniden denemesinde bu ID korunsun. Gerçekten yeni talep yeni ID almalıdır. E-posta adresi iletişim bilgisidir, güvenilir talep anahtarı değildir: aynı kişi iki hizmet isteyebilir; yazım düzeltmesi yeni bir ücretli müşteri adayı yaratmamalıdır.

formA:submission_id gibi bir ad alanı kullanın. Taşıma anahtarını CRM kişi kimliğinden ve talep kimliğinden ayırın. Eşleme kaydında anahtar, CRM talep ID'si, işleme durumu, ilk alınma zamanı, son deneme zamanı ve kısa hata sınıfı bulunsun. Telefon ve e-postayı URL'ye, sub-ID'ye veya herkese açık günlüklere koymayın.

İstenen fiyat teklifine yanıt almak için iletişim bilgisi vermek, reklam aboneliği oluşturmaz. İlgili bildirimi ve veri işlemenin dayanağını kaydedin; bir onay kutusunu gelecekteki her kullanımın izni saymayın. Hizmet gerektirmiyorsa sağlık, finans veya kimlik belgesi bilgilerini serbest metin alanında istemeyin.

2. CRM teslimini iş ortağı sonucu kabulünden ayırın

Kendi platformumuz AffiliateCore, reklamveren teklifinizi hazırladığınız ve desteklenen dönüşüm koşullarını kararlaştırdığınız yer olabilir. Form ve CRM otomasyonu dış sistemlerde kalır. Başarılı CRM yazımı otomatik olarak onaylı AffiliateCore dönüşümü değildir. Yayımlanan salt okunur API, dönüşüm oluşturma veya onaylama aracı olarak tanıtılmamalıdır.

Durumları eşleştirmeden önce iş sonucunu tanımlayın: örneğin hizmet bölgesindeki desteklenen bir hizmet için tekil talep, kullanılabilir iletişim yolu ve kararlaştırılan sürede inceleme. Tekrarları, müşterinin vazgeçmesini, yanlış bölgeyi ve kapsam dışı başvuruları açıklayın. CRM daha sonra satışı kapattı diye kayıt olayını satış olarak yeniden adlandırmayın. Ücretli iş ortağı trafiği bağlanmadan önce gerçek entegrasyonu ve desteklenen olayı ayrıca doğrulayın.

Teklif koşullarınızı hazırlamak için AffiliateCore'a reklamveren olarak kaydolun. Bu işlem Make kurmaz, CRM bağlamaz ve herhangi bir ülke veya ürünü onaylamaz. Mevcut kullanıcılar kararlaştırılmış tanımları dış entegrasyon haritasının yanında saklamalıdır.

3. Sınırlı ve kurtarılabilir bir senaryo kurun

Make özel webhook belgeleri, alıcı modülü, isteğe bağlı API anahtarı doğrulamasını ve tanımlı veri yapısını açıklar. İstekleri form sunucusundan gönderin; özel anahtarı herkese açık tarayıcı koduna yerleştirmeyin. Ayrı test senaryosu ve CRM test ortamı veya açıkça ayrılmış test hattıyla başlayın. Hayalî iletişim bilgileri kullanın ve bu ortamda müşteriye mesaj göndermeyi kapatın.

Eğitim şeması: form sunucusu talebi saklar → kimliği doğrulanmış alıcı → yapı ve alan kontrolü → kimlik araması → CRM oluşturma/güncelleme → eşleme makbuzu → mutabakat. Bu, canlı sistem ekran görüntüsü değil bir tasarımdır.

Webhook ekleyin, zorunlu alanları belirleyin, yanlış türleri ve bilinmeyen hizmet kodlarını reddedin. Tek örnekten alan isimlerini öğrenmek, doğrulama sözleşmesinin yerine geçmez. CRM bağlantısına yalnızca gereken yetkileri verin. Belgelenmiş upsert veya CRM'nin benzersizliğini zorunlu tuttuğu dış ID mekanizmasını tercih edin. Hedef benzersizlik sağlayamıyorsa belirsiz teslimleri incelemeye yönlendirin; “tam bir kez” işleme sözü vermeyin.

Tek yazıcılı küçük pilotlarda senaryo ayarları sıralı işleme sunar. Bu, çakışan çalıştırmalara yardımcı olur; fakat arama ardından oluşturma işlemini diğer senaryolara, elle içe aktarmaya veya CRM kullanıcılarına karşı atomik yapmaz. Tek yetkili yazıcı kullanın ya da hedefte benzersizliği zorunlu kılın. Doğrulanmış atomik işlem olmadan depolama bayrağına dağıtık kilit demeyin.

Make, durum saklamak için Data stores özelliğini de belgeler. Gerçek sınırlar, yedekleme ve saklama düzeni içinde kullanın. Eşleme kaydı kurtarmaya yardım eder; CRM kaydı ve formun başlangıç günlüğü ayrı kanıtlar olmaya devam eder.

4. Neyin tekrarlanacağına, neyin araştırılacağına karar verin

Otomatik tekrarları açmadan önce hataları sınıflandırın. Eksik alan veya reddedilen kimlik bilgisi düzeltme gerektirir; sonsuz döngü değil. Geçici hız sınırı veya kesinti, sağlayıcı kurallarına göre sınırlı tekrarı haklı çıkarabilir. Sonucu bilinmeyen işlem mutabakat gerektirir: bağlantı kesilmeden önce CRM kaydetmiş olabilir.

Şu diziyi düşünün: CRM 418 numaralı talebi oluşturur, yanıt kaybolur, Make hata yazar, ikinci çalıştırma kontrol etmeden Create çağırır. Tekrarın nedeni iki kullanıcı gönderimi değil, teslim belirsizliğidir. Kalıcı dış ID ile arayın veya CRM'nin özelliklerini garanti ettiği idempotent upsert'i yineleyin. Eski kaydın bulunmadığını doğrulamadan yeni kayıt oluşturmayın.

Örneğin üç otomatik deneme, ardından elle inceleme şeklinde operasyon sınırı koyun. Bu eğitim ayarıdır; Make'in evrensel davranışı değildir. Deneme sayısını ve sonraki işlemi kaydedin. Bekleme aralığı ve kota yönetimi gerçek modüle ve CRM yanıtına bağlıdır. Yeniden oynatma, vazgeçen kişiyi reklam listesine geri eklememeli veya yeni kararı eski olayla ezmemelidir.

Hata işleme rehberi desteklenen kurtarma yollarına bağlantı verir. Webhook belgeleri kuyruğa kabulü senaryonun işlenmesinden ayırır. Raporunuzda da alınma, CRM yazımının tamamlanması ve ticari kabul ayrı durumlar olsun.

5. Ücretli sahte etkinlik yaratmadan hata testi yapın

Beklenen sonuçları önceden yazın. Geçerli talep, birebir tekrar, neredeyse eşzamanlı iki tekrar, eksik zorunlu alan, CRM hız sınırı, benzetilmiş yazımdan sonraki zaman aşımı, düzeltilmiş iletişim bilgisi, müşterinin vazgeçmesi ve yeni durumdan sonra gelen eski güncellemeyi deneyin. Yalnızca değiştirmeye yetkili olduğunuz test uçlarını ve kayıtları kullanın. Üretimi aşırı yüklemeyin veya sağlayıcıda gerçek kesinti yaratmayın.

Her test için küçük kanıt satırı tutun: gönderim ID'si, beklenen sonuç, gözlenen CRM ID'leri, makbuz durumu, hata sınıfı ve kontrol eden kişi. Tekrar yeni talep oluşturmamalı. Geçersiz gönderim sessizce kaybolmamalı. Geri çekilmiş talep tekrar sonrasında geri çekilmiş kalmalı. Ticari raporda ödenecek test dönüşümü sayısı sıfır olmalıdır.

Kurtarma sorumlusunun işini de test edin. Tüm içerikleri okumadan açık ID'yi bulabiliyor mu? Tekrar Create demeden zaman aşımını uzlaştırabiliyor mu? Teknik tekrar ile aynı kişinin ikinci gerçek isteğini ayırabiliyor mu? Yanıtlar belirsizse daha fazla hacme hazır değilsiniz.

Pilot öncesi kuyruk sorumlusunu ve yükseltme zamanını belirleyin. Son çalıştırmanın yeşil olması dünkü açık hataların düzeldiğini kanıtlamaz. Her gün kaynak günlüğüyle CRM'yi karşılaştırın; hem eksikleri hem beklenmeyen fazlalıkları arayın.

6. Birinci örnek: tam maliyetle doğru pilot

Kapalı eğitim kohortunda 200 teslim denemesi, bunların içinde 20 tam tekrar olduğunu varsayalım. 180 benzersiz gönderim kalır. Doğrulama 10 hatalı gönderimi reddeder; CRM'de 170 talep oluşur. İş incelemesi 140'ını kabul eder, 30'unu kapsam dışı bulur. Kabul edilen 10 müşteri nihai sözleşmesel sonuçtan önce vazgeçer: iptal edilmemiş 130 kabul kalır. Tekrarlar ve teknik testler hiçbir zaman ücretli sonuç değildir.

Varsayılan maliyetler: trafik 24.000 TRY; kurulum 9.600 TRY (8 saat × 1.200); otomasyon payı 1.600 TRY; CRM 1.200 TRY; elle inceleme 4.800 TRY (4 saat × 1.200); destek 1.200 TRY; iş ortağı/platform ücretleri 2.600 TRY. Toplam 45.000 TRY. Varsayılan geri alınamayan giderler dahildir; gerçek bütçeye eksik vergileri, kur ücretlerini ve veri işleme giderlerini ekleyin. Bu hizmet payları güncel sağlayıcı tarifeleri değildir.

Benzersiz gönderim başına maliyet 45.000 ÷ 180 = 250 TRY. İptalsiz kabul başına 45.000 ÷ 130 = 346,15 TRY. Eğitim tavanı 400 TRY olduğundan ekonomik koşul sağlanır. Sonuç başına bu giderlerden önce 480 TRY katkı varsayılırsa 130 × 480 − 45.000 = 17.400 TRY kalır. Bu öğretici hesaptır, gelir tahmini değildir.

Karar: 180 ID'nin tamamını uzlaştırdıktan sonra aynı hacmi tekrarlayın, ardından küçük artışı değerlendirin. İlk raporu güzelleştirmek için kurulum maliyetini çıkarmayın. Sonraki dönemler için tekrarlayan giderleri ayrıca gösterebilirsiniz, ancak bunu etiketleyin ve tam pilot toplamını görünür tutun. Hızlı teslim tek başına ilave satış kanıtı değildir.

7. İkinci örnek: tekrarlar zararı gizliyor

Başka pilot 150 teslim denemesi ve 30 tam tekrar kaydeder: 120 benzersiz gönderim vardır. Bozuk entegrasyon 145 CRM satırı oluşturur; 25'i fazladan tekrardır. Mutabakattan sonra 80 benzersiz talep kabul edilir, 40 reddedilir. Kabul edilenlerden 15'i nihai kabul öncesi çekilir ve 65 sonuç kalır. Fazladan 25 satır raporda düzeltilir, yeni müşteri sayılmaz.

Tam giderler: trafik 20.000 TRY; kurulum 12.000 TRY (10 saat × 1.200); otomasyon 2.400 TRY; CRM 2.000 TRY; inceleme 9.600 TRY (8 saat × 1.200); tekrar temizliği 4.800 TRY (4 saat × 1.200); iş ortağı/platform ücretleri 2.600 TRY. Toplam 53.400 TRY. Sonuç başına 821,54 TRY, 600 TRY tavanını aşar. Varsayılan 720 TRY katkıyla 65 × 720 − 53.400 = −6.600 TRY olur.

Karar: yeni ücretli edinimi durdurun, kapasite artırmadan kimlik işlemesini düzeltin. Mevcut gerçek talepler yanıt beklemeye devam eder; reklamı durdurmak kuyruğu terk etmek değildir. Tekrar ve zaman aşımı testlerini sentetik verilerle yenileyin, tüm gerçek açık ID'leri uzlaştırın ve kararlaştırılan kurala göre geçerli gönderim başına tek iş talebi oluştuğu kanıtlanmadan yeniden başlamayın. Daha ucuz Make planı kimlik hatasını çözmez.

8. Veriyi koruyun ve durdurma kuralı koyun

Her adım yalnızca gereken veriyi saklasın. Kimlik bilgilerini yönetilen bağlantılarda veya korumalı sunucu ayarlarında tutun; ekran görüntülerine, örnek yüklere veya ortak tablolara koymayın. Asıl talepler, eşleme makbuzları ve hata günlükleri için ayrı saklama süreleri belirleyin. Gizlilik ayarı, hiçbir kuyrukta veya dış serviste veri kalmadığını tek başına kanıtlamaz. Hesabın bölgesini ve işleme koşullarını, CRM ve form sağlayıcısıyla birlikte kontrol edin.

Açıklanamayan tekrarlar, ekibin kapasitesini aşan açık kuyruk, uzlaştırılamayan toplamlar veya beklenmeyen loglarda kişisel veri varsa yeni teslimi durdurun. Kanıtı koruyup desteklenen akışı geri kurun; göstergeyi yeşile çevirmek için hata kuyruğunu silmeyin. Değişikliği önce test senaryosunda yapın ve uygulanan sürümü kaydedin.

Yalnızca olgun kohort hem kimlik hem maliyet kontrolünü geçtiğinde büyütün. Bir değişkeni artırın, önceki yapılandırmayı koruyun ve kurtarma kapasitesi ayırın. Çalışma paketi alan sözleşmesi, kimlik kuralı, durum haritası, tekrar sınıfları, dokuz test, tam maliyet tablosu ve kuyruk sorumlusunu içermelidir.

Mevcut reklamverenler AffiliateCore'a giriş yaparak kendi teklif koşullarını dış süreçle uyumlu hale getirebilir. Yeni reklamverenler desteklenen entegrasyonu görüşmeden önce hesap hazırlayabilir. Teknik teslimi izleyen iş incelemesi için kabul ve uyuşmazlık rehberini okuyun. Birincil kaynaklar 13 Ekim 2026 tarihinde kontrol edildi; örnekler ve eşikler eğitim amaçlıdır.