Brevo bağlayıcı kılavuzu: Brevo'yu teknoloji yığınınıza bağlamanın dört yolu
Brevo bağlayıcıları gerçekte nasıl çalışır: yerel eklentiler, iPaaS, entegrasyon katmanı veya doğrudan API. Doğrusunu seçin ve canlıdaki senkronizasyon hatalarından sağ çıkın.
“Brevo connector” diye arattığınızda karşınıza pazar eklentileri, üçüncü taraf otomasyon uygulamaları ve topluluk modüllerinden oluşan dağınık bir yığın çıkar. Bunun nedeni “bağlayıcı” kelimesinin tek bir şeyi anlatmaması. Bu, her biri farklı bir arıza biçimine ve bir şey bozulduğunda farklı bir sorumluya sahip, gerçekten birbirinden ayrı dört mühendislik tercihini kapsayan bir kategori.
Bu kılavuz önce bağlayıcının ne olduğunu tanımlıyor, dört yaklaşımı dürüstçe ortaya koyuyor ve ardından uzunluğunun büyük kısmını neredeyse hiçbir yazının değinmediği kısma ayırıyor: bağlayıcı canlıya alındıktan ve gerçek trafiği taşımaya başladıktan sonra neler ters gider.
Brevo bağlayıcısı aslında nedir
Markalamayı bir kenara bırakırsanız her Brevo bağlayıcısı aynı üç bileşenden oluşur.
Taşıma. Verinin fiziksel olarak nasıl hareket ettiği. Pratikte bu, bir yönde Brevo REST API’sine yapılan çağrılar, diğer yönde Brevo webhook’ları demektir. Brevo webhook’ları pazarlama ve işlemsel türlere ayırır, bunlar yönetim panelinden veya webhook oluşturma ve güncelleme uç noktalarından yapılandırılabilir ve hesap başına iki tür toplamında 40 webhook tavanı vardır.
Eşleme. Kaynak sistemdeki bir alanın Brevo’da hangi alana dönüştüğü. Bir Shopify müşterisinde first_name vardır, bir Brevo kişisinde ise sizin tanımladığınız özellik bulunur ve Brevo, hesabınızda var olmayan özellikleri sessizce yok sayar. Bağlayıcıların çoğu sessizce tam da bu noktada çürür.
Durum. Bağlayıcının çalışmalar arasında hatırladıkları: hangi kayıtları gönderdiği, hangileri başarısız olduğu, hangi imleç konumuna ulaştığı. Durum tutmayan bağlayıcılar geriye dönük dolgu yapamaz, bir hatayı yeniden oynatamaz ve bir kişinin eksik mi yoksa sadece geç mi kaldığını size söyleyemez.
Herhangi bir bağlayıcıyı bu üçünü ne kadar iyi ele aldığına bakarak değerlendirin. Pazarlama sayfalarının çoğu yalnızca ilkini anlatır.
Tanımlayıcı sorunu her şeyin altında yatar
Brevo’nun kişi oluşturma uç noktası en az bir tanımlayıcı ister: email, SMS veya sizin kendi harici tanımlayıcınız olan ext_id. Varsayılan olarak çakışan bir tanımlayıcı 4xx hatası döndürür. updateEnabled değerini true yapmak çağrıyı bir upsert işlemine çevirir, forceMerge ise en güncel zaman damgasına sahip kaydı tutup diğerini silerek yinelenenleri birleştirir.
Bağlayıcınızın hangi tanımlayıcıyı birincil kabul ettiği yönündeki bu tek tasarım kararı, elinizde temiz bir kişi veritabanı mı yoksa her şeyin iki kopyası mı olacağını belirler. Bir araç seçmeden önce bu kararı verin.
Brevo’ya bağlanmanın dört yolu
Seçenek 1: Yerel eklentiler ve pazar uygulamaları
Brevo, kendi ifadesiyle Brevo’yu “Shopify, WordPress, Stripe, Zapier ve daha fazlası gibi 150’den fazla dijital araçla” birleştiren bir uygulama pazarı işletiyor. Öne çıkardığı birinci taraf uygulamalar WordPress, WooCommerce, Shopify ve BigCommerce. Pazar, kategoriye ve uygulamayı kimin geliştirdiğine göre filtrelenebiliyor. Bu ikincisi kulağa geldiğinden daha önemli: Brevo’nun geliştirdiği bir uygulama ile iş ortağının geliştirdiği bir uygulama çok farklı destek yolları taşır.
Güçlü yanları. Çalışan bir kuruluma giden en hızlı yol. Kimlik doğrulama, temel alan eşlemesi ve yaygın olaylar önceden bağlanmış gelir. Brevo API’sini değiştirdiğinde eklentiyi sağlayıcı günceller.
Zayıf yanları. Sağlayıcının seçtiği eşlemeyi kabul etmek zorundasınız. Özel özellikler, sıra dışı nesneler ve mağazaya özgü mantık genellikle bunun dışında kalır. Hata ayıklama, eklentinin kaydettiği loglarla sınırlıdır ve bu loglar çoğu zaman işe yaramaz. Üstelik iş ortağının geliştirdiği bir uygulama terk edildiğinde bunu bir kesinti sırasında öğrenirsiniz.
Şu durumda kullanın: tek bir standart platformunuz, standart alanlarınız var ve neyin senkronize olduğunu kanıtlama zorunluluğunuz yok.
Seçenek 2: Genel iPaaS araçları
Zapier, Make ve Pabbly Connect’in tamamı Brevo’yu destekliyor. Brevo, entegrasyon sayfasında Zapier’i doğrudan “Brevo’yu uygulamalarınızla birleştirin, işinizi Zapier ile otomatikleştirin” başlığı altında gömülü sunuyor. Make, modülleri kişi, liste, klasör, kampanya, olay, e-posta ve SMS izleme, oluşturma, güncelleme, listeleme ve silme işlemlerini kapsayan bir Brevo uygulaması yayımlıyor. Pabbly Connect ise Brevo’yu desteklediği uygulamalar arasında listeliyor.
Güçlü yanları. Uzun kuyruk için gerçekten mükemmel. Kimsenin adını duymadığı bir form sağlayıcısı, tek seferlik bir dahili araç, arada bir insan gerektiren onay adımı: iPaaS bunları bir öğleden sonrada halleder ve senaryoyu mühendis olmayan biri de sürdürebilir.
Zayıf yanları. Görev başına fiyatlandırma hacmi cezalandırır. Çoğu senaryo tek seferde bir kayıt işler, dolayısıyla 40.000 kişilik bir geriye dönük dolgu ya imkansızdır ya da pahalıdır. Hata yönetimi genellikle “çalışma başarısız oldu, işte bir e-posta” düzeyindedir, otomatik yeniden oynatma yoktur ve geçen salı hangi kayıtların hiç ulaşmadığını sorabileceğiniz bir yol da yoktur. Sıralama garanti edilmez, bu yüzden bir güncelleme, bağlı olduğu oluşturma işleminin önüne geçebilir.
Şu durumda kullanın: hacim düşük, akış tek yönlü ve kaybolan bir kayıt maliyetli olmaktan çok can sıkıcı. En iyi entegrasyon platformları derlememiz bu kategorideki seçenekleri doğrudan karşılaştırıyor.
Seçenek 3: Bu iş için tasarlanmış bir entegrasyon katmanı
Sistemlerinizle Brevo arasında duran, eşlemenin ve senkronizasyon durumunun sahipliğini üstlenen ve herhangi bir uygulamadan herhangi bir uygulamaya değil, tam da bu iş için tasarlanmış bir katman.
Tajo bu seçeneklerden biri. Kendisini, desteklenen ticaret verilerini Brevo’ya bağlayan, kural tabanlı müşteri segmentleri oluşturan ve yönetişimi sağlanmış e-posta ile SMS kampanyaları hazırlayan, Brevo için bir AI pazarlama ekibi olarak tanımlıyor. Pratikte, bu iş için tasarlanmış her katmanın takası aynıdır: kişiler, olaylar ve kampanyalar için görüş sahibi bir modeli kabul edersiniz, karşılığında ne bir eklentinin ne de genel bir iPaaS’ın verebileceği geriye dönük dolgu, yeniden deneme ve kayıt bazında görünürlük elde edersiniz. Brevo entegrasyon kılavuzumuz kurulumu baştan sona anlatıyor.
Güçlü yanları. Toplu işlemler birinci sınıf vatandaştır. Hatalar kayıt bazında görünür ve yeniden oynatılabilir. Eşleme bir eklentinin içine gömülü değil, açık ve sürümlenmiştir.
Zayıf yanları. Yolda bir sağlayıcı daha ve değerlendirilecek bir şey daha. İhtiyacınız tek bir WordPress formunun tek bir Brevo listesine veri göndermesiyse, bu küçük bir iş için ağır makine demektir. Bu konuda dürüst olun: orada yerel bir eklenti daha doğru tercihtir.
Şu durumda kullanın: ticaret verisi hacminiz ciddi, neyin senkronize olduğunu kanıtlamanız gerekiyor ve segmentlerinizle kampanya mantığınızın, senkronizasyonun ürettiği veri modeliyle aynı model üzerine kurulmasını istiyorsunuz.
Seçenek 4: Doğrudan API entegrasyonu
Brevo API’sine karşı yazdığınız kendi kodunuz.
Güçlü yanları. Tavan yok. Kimlik çözümlemesini, gruplamayı, yeniden deneme politikasını ve denetim kaydını tam olarak siz denetlersiniz. Modellenmiş kitleleri Brevo’ya gönderen bir veri ambarı için bu çoğu zaman uyan tek yaklaşımdır.
Zayıf yanları. Sonsuza kadar sizin sorumluluğunuzdadır, kimsenin kapsama almadığı kısımlar dahil: geri çekilmeli yeniden deneme, ölü mektup deposu, şema kayması uyarıları, kimlik bilgisi rotasyonu ve bir çalıştırma kılavuzu. Ekipler mutlu senaryo için bütçe ayırır, sonra geri kalan her şeye üç katını harcar.
Şu durumda kullanın: mantık gerçekten size ait ve hacim bunu haklı çıkarıyor. Uç nokta düzeyindeki ayrıntılar için Brevo API kılavuzumuzdan başlayın.
Karar çerçevesi
Kararı altı soru veriyor. Herhangi bir araca bakmadan önce bunları yanıtlayın.
| Soru | Yerel eklenti | iPaaS | Entegrasyon katmanı | Özel API |
|---|---|---|---|---|
| Veri hacmi | Sağlayıcı ne destekliyorsa | Düşük, görev başına fiyatlı | Yüksek, toplu işlem farkındalıklı | Sınırsız |
| Senkronizasyon yönü | Genellikle tek yönlü, içeri | Senaryo başına tek yönlü | Tanımlı sahiplerle tek yönlü | Ne kurarsanız |
| Gecikme ihtiyacı | Sağlayıcının tercihi | Dakikalar | Gerçek zamana yakın | Sizin tercihiniz |
| Eşleme karmaşıklığı | Sabit alanlar | Basit, senaryo başına | Açık ve sürümlenmiş | Serbest |
| Hata yönetimi | Çoğu zaman görünmez | Hatada uyarı | Kayıt bazında yeniden deneme ve oynatma | Ne kurarsanız |
| Kim düzeltir | Eklenti sağlayıcısı | Görsel bir editörde siz | Sağlayıcı, sizin görünürlüğünüzle | Gece ikide siz |
Son satır, insanların atladığı ve sonra pişman olduğu satır. Bağlayıcı bir kurulum görevi değil, uzun vadeli bir operasyonel taahhüttür, dolayısıyla arıza biçimiyle yaşayabileceğiniz seçeneği seçin.
İşin yürüyüp yürümeyeceğini belirleyen senkronizasyon desenleri
Tek yönlüye karşı çift yönlü
Tek yönlü senkronizasyonda her alanın tek bir sahibi vardır ve bu, kelimenin en iyi anlamıyla sıkıcıdır. Çift yönlü senkronizasyon döngü bastırma, çakışma çözümü ve bir üstünlük kuralı gerektirir, üstelik Brevo, kendi bağlayıcınızın az önce yazdığı bir değişiklik için memnuniyetle contact_updated webhook’u yayar.
Kulağa daha yetenekli geldiği için çift yönlü senkronizasyon kurmayın. Bunun yerine bir alan sahipliği tablosu oluşturun: sipariş verisinin sahibi e-ticaret platformunuz, yaşam döngüsü aşamasının sahibi CRM’iniz, onay ve etkileşimin sahibi Brevo. Her alanı yalnızca tek bir yönde senkronize edin. Bir alanda gerçekten çift yönlü hareket gerekiyorsa her yazma işlemine bir köken işareti ekleyin ve kendi işaretinizi taşıyan gelen olayları eleyin.
Yoklamaya karşı webhook’lar
Webhook’lar daha ucuz ve daha hızlıdır ama garantili değildir. Pazarlama webhook olayları arasında delivered, opened, click, hard_bounce, soft_bounce, spam, unsubscribe, contact_updated, contact_deleted ve list_addition bulunur. İşlemsel webhook’lar ise gönderim yaşam döngüsünü, sent ve delivered aşamasından deferred, blocked, complaint ve error aşamalarına kadar kapsar.
Planlamanız gereken iki şey var. Birincisi, Brevo’nun webhook dokümantasyonu bir yük imzası yerine Brevo’nun yayımladığı IP adreslerinin izin listesine alınmasına odaklanır, dolayısıyla uç noktayı varsayılan olarak kimlik doğrulamasız kabul edin ve sonucu önemli olan her şeyi kaydı API’den geri okuyarak teyit edin. İkincisi, hiçbir webhook sistemi sonsuza kadar her şeyi teslim etmez, bu yüzden webhook’ları, aradan sızanları yakalayan düşük frekanslı bir mutabakat yoklamasıyla eşleştirin.
Toplu işleme karşı gerçek zamanlı
Gerçek zaman tetikleyiciler için önemlidir, terk edilmiş sepet ve karşılama akışlarının olay çağrılarını hak etmesinin nedeni budur. Gecelik bir özellik yenilemesi içinse hiç önemli değildir.
Deseni hız limitleriyle eşleştirin. Brevo’nun kişi uç noktaları ve POST /v3/events uç noktası standart hesaplarda saniyede 10 isteğe izin verir, işlemsel e-posta saniyede 1.000 isteğe izin verir ve diğer tüm uç noktalar saatte 100 istekle sınırlıdır. Professional ve Enterprise hesaplarında ilk grup kabaca ikiye katlanır. “Diğer tüm uç noktalar” için geçerli olan saatte 100 tavanı en sık yaşanan sürprizdir: her kayıtta liste veya klasör okuyan bir bağlayıcı bu limiti öğle olmadan tüketir ve HTTP 429 yanıtları toplamaya başlar.
Toplu işler için döngü kurmak yerine içe aktarma uç noktasını kullanın. Bu uç nokta bir dosya URL’si, bir dosya gövdesi veya 8MB güvenli sınırıyla 10MB’a kadar bir JSON gövdesi kabul eder, asenkron çalışır, bir processId döndürür ve iş bittiğinde bir bildirim URL’sini çağırır.
Idempotentlik ve kimlik
Brevo’nun olay uç noktası bir event_name, en az bir tanımlayıcı, isteğe bağlı kişi özellikleri ve 50KB’a kadar isteğe bağlı olay özellikleri alır, başarı durumunda 204 döndürür. Belgelenmiş bir idempotentlik anahtarı yoktur, dolayısıyla yeniden denenen bir çağrı yinelenen bir olay oluşturabilir.
Idempotentliği kendiniz kurun. Kaynak kayıttan ve sürümünden deterministik bir anahtar türetin, hangi anahtarları gönderdiğinizi saklayın ve göndermeden önce kontrol edin. Kişiler için tek bir birincil tanımlayıcı seçin, ext_id alanını kaynak sisteminizin kimliğiyle doldurun ve upsert için updateEnabled kullanın ki yeniden deneme hata vermek yerine güncelleme yapsın.
Güvenebileceğiniz bir yeniden senkronizasyon tasarlamak
Yeniden senkronizasyona ihtiyacınız olacak. Bunu daha ilk günden tasarlayın.
- Her yazma işlemini idempotent yapın ki yeniden oynatmak yıkıcı değil güvenli olsun.
- Nesne türü başına bir imleç tutun ve bunu bağlayıcının belleğinin dışında saklayın.
- Yeniden senkronizasyonu gerçek listeden önce tek kullanımlık bir Brevo listesinde test edin.
- İçe aktarmalar sırasında
emptyContactsAttributesdeğerini varsayılan false halinde bırakın. Bunu true yapmak, Brevo’ya boş alanların mevcut değerleri silmesi gerektiğini söyler ve kısmi bir dışa aktarmayı kalıcı veri kaybına çevirir. - Kayıt bazında sonuç loglayın. 40.000 kaydın 400’ü doğrulamada başarısız olduysa “iş başarılı oldu” bir sonuç değildir.
Canlı ortamda gerçekte neler ters gider
Alan eşlemesi kayması
Biri bir Shopify meta alanının adını değiştirir veya ödeme adımına zorunlu bir alan ekler. Bağlayıcı çalışmaya ve başarı bildirmeye devam eder, çünkü Brevo tanımadığı özellikleri yok sayar. Haftalar sonra bir segment sessizce yarı yarıya boşalmıştır.
Önlem. Kaynak şemasının ve Brevo özellik listesinin anlık görüntüsünü alın, bunları düzenli aralıklarla karşılaştırın ve farkta uyarı üretin. Ayrıca yalnızca hatalarda değil, özellik başına boş olmayan değer oranındaki düşüşte de uyarı üretin.
Yinelenen kişiler
Klasik sebep, iki farklı tanımlayıcı kullanan iki bağlayıcıdır: mağaza eklentisi kişileri e-postayla oluşturur, bir SMS akışı telefonla oluşturur ve tek bir insan, etkileşim geçmişi ikiye bölünmüş iki kayda dönüşür.
Önlem. Her yerde uygulanan tek bir birincil tanımlayıcı. ext_id alanını kaynak sisteminizden doldurun ki her zaman kararlı bir birleştirme anahtarınız olsun. forceMerge özelliğini rutin bir ayar olarak değil, eski kaydı sildiğini bilerek bilinçli bir temizlik adımı olarak kullanın.
Senkronizasyon döngüleri
A bağlayıcısı Brevo’ya yazar, Brevo contact_updated yayar, B bağlayıcısı kaynağa geri yazar, kaynak kendi değişiklik olayını yayar ve döngü tekrarlar. Bunu siz fark etmeden önce genellikle hız limitleri ortaya çıkarır.
Önlem. Her yazma işleminde köken işaretleri, artı belirli bir zaman aralığında eşiği aşınca alarm veren kayıt bazında bir değişiklik sayacı.
Hız limitleri ve kısmi hatalar
Limit aşıldığında 429 döner. Tehlikeli durum 429’un kendisi değildir, bazı kayıtların başarılı bazılarının başarısız olduğu bir gruptur: bağlayıcı ya tüm grubu başarısız sayıp yeniden oynatır ya da başarılı sayıp hataları kaybeder.
Önlem. Üstel geri çekilme ve sapma ile yeniden deneyin, varsa yeniden deneme ipucuna uyun ve sonuçları grup bazında değil kayıt bazında izleyin. Hataları, düzeltmeden sonra yeniden oynatılabilmeleri için tam yükleriyle birlikte bir ölü mektup deposuna gönderin.
Sessiz veri kaybı
En kötü hatalar sessiz olanlardır: boş bir sütunla ve emptyContactsAttributes true olarak yapılan bir içe aktarma, artık var olmadığı için değerleri buharlaşan bir özellik, kimse bakmazken bir saat boyunca 500 döndüren bir webhook uç noktası.
Önlem. Yalnızca hataları değil, sayıları izleyin. Günlük oluşturulan kişi sayısı, saatlik alınan olay sayısı, özellik doluluk oranları. Sıfıra düşen bir metrik, alabileceğiniz en net uyarıdır.
Birbiriyle anlaşamayan iki sistem
Er ya da geç kaynağınız 18.400 aktif kişi der, Brevo ise 18.062. Mutabakat olmadan hangisinin doğru olduğunu söyleyemezsiniz.
Önlem. Sayıları ve tanımlayıcıya göre seçilmiş bir kayıt örneklemini karşılaştıran zamanlanmış bir mutabakat çalıştırın ve bir fark raporu üretin. Tekrar tekrar yeniden içe aktarmak yerine sebepleri düzeltin, çünkü yeniden içe aktarma uyuşmazlığı açıklamadan gizler.
Pratikte sık görülen bağlantılar
E-ticaret. Shopify ve WooCommerce iki ağır sıklet ve ikisinin de Brevo pazarında birinci taraf uygulaması var. Yerel yol, kişileri ve temel sipariş verilerini iyi yönetir. Özel sipariş satırı mantığı, abonelik durumu ve sadakat seviyeleri genellikle buna sığmaz, işte bir katman ya da özel kod tam da orada hak ettiği yeri bulur. Brevo Shopify entegrasyon kılavuzumuz bu özel eşleşmeyi derinlemesine ele alıyor.
CMS. WordPress, e-ticaret dışındaki en yaygın Brevo bağlantısıdır, tipik olarak formlar, bülten kaydı ve Brevo’nun SMTP’si üzerinden işlemsel e-posta için kullanılır. Burada eklenti yolu neredeyse her zaman doğrudur, çünkü veri modeli basit ve hacim düşüktür.
CRM ve veri ambarı. Bağlayıcıların zorlaştığı yer burasıdır, çünkü her iki taraf da müşterinin sahibi olduğuna inanır. Bir alan sahipliği tablosu kullanın, her alanı tek yönde senkronize edin ve ham kayıtları senkronize etmek yerine ambardan modellenmiş kitleleri Brevo listelerine göndermeyi düşünün. Brevo’nun kendi CRM nesnelerinin bu tabloya nasıl oturduğu için Brevo CRM kılavuzumuza bakın.
Formlar. İdeal iPaaS kullanım senaryosu: düşük hacim, tek yön, gecikmeye toleranslı. Gereğinden fazla mühendislik yapmayın.
Doğru yapmak
Bağlayıcı seçimi büyük ölçüde özelliklerle değil operasyonla ilgili bir sorudur. Her seçenek bir kişiyi A’dan B’ye taşıyabilir. Farkları, eşlemenin kaydığı, hız limitinin tetiklendiği ya da 40.000 kayıtlık bir içe aktarmada 400 kaydın doğrulamada başarısız olduğu gün ne olacağındadır.
Şu sırayla ilerleyin:
- Hangi sistemin hangi alanın sahibi olduğunu yazın. Geri kalan her şey bundan türer.
- Tek bir birincil kişi tanımlayıcısı seçin ve
ext_idalanını kaynak sisteminizden doldurun. - En yetenekli olanı değil, hacminizden ve hata yönetimi gereksiniminizden sağ çıkan en hafif seçeneği seçin.
- Yeniden senkronizasyonu ve mutabakat raporunu ilk olaydan sonra değil, canlıya çıkmadan önce kurun.
- Sayıları ve doluluk oranlarını izleyin, çünkü sessiz kayıp gürültülü hatadan daha yaygındır.
Bu beş şeyi yapın, dört yaklaşımdan herhangi biri işe yarasın. Atlarsanız hiçbiri yaramaz.