E-ticaret için Anlık Bildirim Otomasyonu: 5 İş Akışı Taslağı

Çeyreğin üçüncü Cuması ve siz elde tutma panonuza bakıyorsunuz. Terk edilmiş sepet sırası çalışıyor. Göz atma terk etme tetikleyicisi çalışıyor. Satın alma sonrası inceleme isteği çalışıyor. Fiyat düşüşü uyarısı çalışıyor. Kaydolma başına hoş geldin bildirimleri gönderilir. Altı adet “otomatik” anlık bildirim. Son on sekiz ayda kurulmuş altı tetikleyici. Tekrar satın alma oranınız on iki ay önce durdu.

E-ticaret için anlık bildirim otomasyonu, çoğu orta ölçekli elde tutma sisteminde böyle görünür: altı bağlantısız tetikleyici, her biri farklı bir kampanya sahibinden kopya gönderiyor, hiçbiri diğerlerinden haberdar değil. Sepet terk etme serisi, zaten satın almış abonelere bildirim göndermeye devam ediyor. Geri kazanma kampanyası, aynı müşteri için fiyat düşüşü uyarısıyla çakışıyor. Paylaşılan bir mantık, paylaşılan bir çıkış kriteri, paylaşılan bir kimlik yok. Sadece aynı abone listesine işaret eden altı ayrı boru hattı, her biri diğer beşinin yok olduğunu iddia ediyor.

E-ticaret için anlık bildirim otomasyonu böyle çalışmamalıdır. Tek bir iş akışı mimarisi olarak çalışmalıdır: tek bir abone kimliğinden web anlık, uygulama anlık, WhatsApp ve canlı sohbet üzerinden çalışan paylaşılan tetikleyicilere, paylaşılan karar mantığına ve paylaşılan çıkış kriterlerine sahip çok düğümlü yolculuklar kümesi. Bu makale, bu mimarinin nasıl göründüğünü, kaldırabileceğiniz beş tam iş akışı planını sunduğunu ve satır öğesinin finans için savunulabilir olması için iş akışı başına huninin nasıl okunacağını gösterir.

Çoğu “otomatik anlık bildirim” aslında otomatik değildir

E-ticaret blog devresinde otomasyon kelimesi çok fazla hak edilmemiş iş yapıyor. Çoğu makale “otomatik anlık bildirimler” dediğinde, kastettikleri “tetiklenmiş anlık bildirimler”: bir olay gerçekleştiğinde gönderilen, başka bir durum, bekleme, dallanma veya çıkış koşulu olmayan tekil bildirimlerdir. Bir abone sepeti terk eder, sepet terk bildirimini gönderir. Bir abone bir ürünü görüntüler, göz atma bildirimini gönderir. Bir abone satın alır, satın alma sonrası bildirimini gönderir. Her tetikleyici, diğer her tetikleyiciden habersiz kendi boru hattıdır.

Bir iş akışı farklı bir şeydir. Bir iş akışı, durumu olan çok adımlı bir yolculuktur. Abonenin nereden girdiğini, şu anda nerede olduğunu, her düğüme ne zaman girdiğini ve hangi koşulların yolculuğu iptal ettiğini bilir. Sepet terk iş akışı, sadece bir saatlik işarette tek bir bildirim göndermez. Bir saatte gönderir, bir gün bekler, sepetin hala terk edilip edilmediğini kontrol eder, indirimli ikinci bir temas gönderir, iki gün daha bekler, son bir temas gönderir ve abone hangi adımda olursa olsun, satın aldığı anda iş akışından çıkar.

Son madde farktır. Tetikleyicinin hafızası yoktur. İş akışının vardır. “Terk edilmiş sepet otomasyonunuz” müşteri zaten ödeme yapmış olmasına rağmen hatırlatıcılar göndermeye devam ediyorsa, bir otomasyonunuz yoktur. Durması söylenmemiş bir tetikleyiciniz var.

Orta ölçekli bir e-ticaret müşteri tutma ekibi için bu ayrım, bileşik bir tekrar satın alma oranı ile durağanlaşan bir oran arasındaki farktır. Paralel çalışan altı tetikleyici, altı gürültü kanalı üretir. Koordineli çalışan beş iş akışı, abone başına dallanmış ve sınırlanmış bir yolculuk üretir. Bu anahtar kelime için sayfa bir arama sonuçlarının çoğu, sorunu “ne tür bildirimler gönderilmeli” olarak çerçeveler ve on iki veya on beş şablonluk bir liste ile yanıtlar. Soru bu değil. Soru, yolculuğun nasıl besteleneceğidir.

Bir anlık bildirim iş akışının anatomisi

Planlardan önce, kelime dağarcığı. Bir anlık bildirim iş akışı altı düğüm tipinden oluşur. Her birinin ne yaptığını bildiğinizde, bu makaledeki her plan bir açıklama değil, bir diyagram olarak okunacaktır.

BAŞLANGIÇ. Giriş noktası. BİR BAŞLANGIÇ düğümü, iş akışının bir abone olayı (sepet terk edildi, sayfa görüntülendi, segmente katıldı, satın alma hedefi izlendi) veya planlanmış bir zamanda belirli kriterlere uyan aboneleri seçen bir kitle filtresi tarafından nasıl tetikleneceğini tanımlar. Bir iş akışının tam olarak bir BAŞLANGIÇ düğümü vardır.

BEKLE. Bir gecikme. BİR BEKLE düğümü, aboneyi belirli bir süre (dakika, saat, gün) veya belirli bir takvim saatine (abonenin saat diliminde Salı 10:00, site saatinde 15 Aralık 20:00) kadar bu noktada tutar. Beklemeler, bir iş akışının neden tek seferlik bir patlama olmadığını öğrenmesidir.

KARAR. İki yönlü bir dal. BİR KARAR düğümü bir koşulu kontrol eder (abone satın aldı mı, hala sepeti terk eden segmentinde mi, sadakat seviyesi “altın” mı) ve onları EVET yolu veya HAYIR yolu boyunca yönlendirir. Kararlar, bir iş akışının her aboneyi aynı şekilde ele almayı nasıl bıraktığıdır.

YOL_AYIR. Yüzde tabanlı bir çatal. YOL_AYIR düğümleri, yapılandırılmış yüzdelere göre aboneleri birden fazla yol boyunca yönlendirir: A/B testi için %50/50, üçlü gönderim süresi testi için %33/33/34. Kazananı bulduğunuzda, kazanan yolu %100'e yükseltirsiniz ve iş akışı kanıtlanmış varyant üzerinde çalışmaya devam eder.

İŞLEM. İşin kendisi. İŞLEM düğümleri bir anlık bildirim gönderir, aboneyi bir segmente ekler, özniteliklerini günceller, bir webhook tetikler, başka bir iş akışını başlatır veya birini durdurur. PushEngage İş Akışları on bir işlem türünü destekler. E-ticarette en yaygın olanlar SendPushNotification, AddSegment, UpdateAttribute ve HttpRequest'tir.

SON / ÇIKIŞ. Terminal. SON ve ÇIKIŞ düğümleri iş akışını tamamlar ve analitikleri günceller. SON doğal sonuçtur. ÇIKIŞ genellikle erken sonlandırmak için kullanılır: Abonenin uygun olmadığı Karar düğümünün HAYIR yolunda veya kontrol grubu olarak tasarlanmış bir Yol Ayır dalında.

Aşağıdaki her iş akışı bu altı parçadan oluşur. Kelime dağarcığı paylaşıldığında, planlar hızlı okunur.

E-ticaret için beş iş akışı planı

Bunlar "örnek" değil. Bunlar çalışan şablonlardır. Her biri tetikleyicisini, çalışma türünü, düğüm dizisini, çıkış kriterlerini ve amaçlanan saklama metriğini listeler. Her birini doğrudan PushEngage İş Akışları oluşturucusuna yerleştirebilir ve bir saatten kısa sürede çalışır duruma getirebilirsiniz.

Şablon 1 — Hoş Geldiniz serisi

• Tetikleyici (BAŞLANGIÇ): Olay PushEngage.Subscriber.Added
• Çalışma türü: Tekli (aboneler başına bir karşılama yolculuğu, yeniden giriş öncesi 90 günlük soğuma süresi ile)
• Akış: Karşılama bildirimi (hemen) → 2 gün BEKLE → özellik vurgulama bildirimi → 3 gün BEKLE → KARAR: abone bir satın alma yaptı mı? → EVET yolu: teşekkür bildirimi gönder ve customers segmentine ekle → HAYIR yolu: ilk satın alma indirimi gönder → SON
• Çıkış kriterleri: Yok. Yolculuk yeterince kısa olduğundan her abone onu tamamlamalıdır.
• Saklama metriği: İlk satın almaya kadar geçen süre. Hoş geldiniz serisini tamamlayan yeni aboneler, tamamlamayanlara göre daha hızlı satın alma yaparlar, çünkü üçüncü temas noktası, ilk satın alma niyetinin ya gerçekleştiği ya da durduğu anda gerçekleşir.

Şablon 2 — Göz atma terk etme

• Tetikleyici (BAŞLANGIÇ): Özel olay page_view, 30 dakika içinde add_to_cart tetiklemeyen ürün detay sayfalarına filtrelenmiş
• Çalışma türü: Birden Çok Paralel (bir abone bir oturumda birden çok ürünü göz atma terk etme durumuna sokabilir ve her biri kendi iş akışı örneğini alır)
• Akış: 30 dakika BEKLE → KARAR: abone hala siteyi mi geziyor? → EVET yolu: SON (aktif bir oturumu kesintiye uğratma) → HAYIR yolu: görüntüledikleri ürünle bir hatırlatma bildirimi gönder → 24 saat BEKLE → KARAR: sepete eklediler mi? → EVET yolu: SON (sepet terk etme iş akışı buradan devralır) → HAYIR yolu: ilgili ürün önerisiyle ikinci bir temas gönder → SON
• Çıkış kriterleri: Hedef add_to_cart (sepet iş akışı yolculuğu devralır) veya hedef purchase (daha fazla mesajlaşmaya gerek yok)
• Saklama metriği: Daha önce görüntülenen ürünlerde göz atmadan sepete dönüşüm oranı. PushEngage'in göz atma terk etme kampanyaları hakkındaki gönderisi, bu şablonun devraldığı segmentasyon çalışmasını kapsar.

Şablon 3 — Terk edilmiş sepet yükseltme

• Tetikleyici (BAŞLANGIÇ): Özel olay cart_abandoned
• Çalışma türü: Birden Çok Paralel (terk edilen her sepet kendi yolculuğudur, bu nedenle ilki hala aktifken ikinci bir sepeti terk eden bir abone ikinci bir eşzamanlı örnek alır)
• Akış: 1 saat BEKLE → hatırlatma #1 (indirim yok, samimi ton) → 24 saat BEKLE → KARAR: sepet hala terk edilmiş mi? → EVET yolu: %10 indirimle hatırlatma #2 → 48 saat BEKLE → KARAR: sepet hala terk edilmiş mi? → EVET yolu: aciliyet çerçevesiyle son hatırlatma ve %20 indirim → SON
• Çıkış kriterleri: Tetikleyici olaydaki cart_id ile eşleşen purchase hedefi. Abone satın alır almaz, abone şu anda nerede olursa olsun, o sepet için iş akışı iptal edilir.
• Tutma metriği: Kanal başına, terk edilmiş sepet başına kurtarılan sepet değeri. Bu, sayfadaki en yüksek etkiye sahip iş akışıdır ve P&L'de savunması en kolay olanıdır. Özellikle sepet terk etme kurtarma dizisi hakkında daha derinlemesine bilgi için, PushEngage sepet terk etme oyun kitabı, dizinin platform davranışına nasıl ayarlandığını (Shopify Plus ödeme akışları, ilk beklemeyi etkileyen şekillerde WooCommerce'den farklıdır) ayrıntılı olarak açıklar.

Taslak 4 — Satın alma sonrası inceleme isteği

• Tetikleyici (BAŞLANGIÇ): goal_name = purchase olan PushEngage.Goal.Tracked olayı
• Çalıştırma türü: Birden Çok Sıralı (abone başına aynı anda bir aktif inceleme-istek yolculuğu, ancak bir sonraki satın alma yeni bir örnek tetikler)
• Akış: 7 GÜN BEKLE (ürünü alıp bir fikir oluşturmak için yeterince uzun) → YOLU 50/50 AYIR: sabah gönderimi (abone-yerel saatle 9:00) akşam gönderimine (abone-yerel saatle 19:00) karşı → inceleme isteği bildirimi → EYLEM: CRM'ye inceleme-istek gönderimini günlüğe kaydetmek için HTTP isteği → SON
• Sessiz saatler: Abonenin saat diliminde akşam 10 ile sabah 8 arası, varsayılan yeniden zamanla. Gece boyunca gönderilecek anlık bildirimler, düşmek yerine sabah 8:01'e kadar bekler. Yeniden zamanla ayarı, bu iş akışı için doğru varsayılandır çünkü atla anlık bildirimleri sessizce düşürür ve analitikten çıkarır, ki bu çoğu tutma ekibinin istemediği bir durumdur.
• Çıkış kriterleri: review_submitted hedefi
• Tutma metriği: Gönderim-saati varyantına göre inceleme-gönderim oranı. Ayrılmış yol, A/B testini bir kampanyanın raporuna eklenmiş bir sonradan düşünülmüş değil, iş akışının bir parçası haline getirir.

Taslak 5 — Geri Kazanım

• Tetikleyici (BAŞLANGIÇ): last_active > 30 days olan kitle filtresi
• Çalıştırma türü: Tek (90 günlük pencere başına abone başına bir geri kazanım denemesi)
• Akış: “Seni özledik” bildirimi → 3 GÜN BEKLE → KARAR: abone bildirimle etkileşime girdi mi veya siteyi ziyaret etti mi? → EVET yolu: yeniden-etkileşime_giren segmentine ekle, bir teşekkür ve indirim gönder, SON → HAYIR yolu: daha derin bir indirimle daha güçlü bir teklif gönder → 5 GÜN BEKLE → KARAR: hala inaktif mi? → EVET yolu: son “son şans” bildirimi → SON
• Çıkış kriterleri: last_active < 7 days olan kitle filtresi. Abone kendi başına aktif hale geldi ve iş akışının görevi tamamlandı.
• Tutma metriği: İş akışı girişinden 60 gün sonra yeniden etkinleştirme oranı.

Tetikleyici hakkında bir not. Bu, makaledeki tek şablondur; olay tabanlı bir tetikleyici yerine kitle tabanlı bir tetikleyici kullanır. PushEngage İş Akışlarındaki kitle tetikleyicileri, yalnızca iş akışı başlangıç saatinde eşleşen abone kümesini toplu olarak işler. İş akışı başladıktan sonra etkisiz hale gelen aboneler otomatik olarak dahil edilmez ve aktif bir iş akışında kitle filtresini düzenlemek yeni aboneler eklemez. Tekrarlanan bir yeniden etkileşim programı istiyorsanız, yeni adayları sürekli olarak almaya devam eden uzun süreli bir kitle iş akışı beklemek yerine, iş akışını tekrarlayan bir programa (aylık veya üç aylık) göre kopyalayın. Bu, tetikleyici türünü yanlış anlayan ekiplerde “neden bu abone geri kazanımı alamadı?” destek biletlerinin gerçek bir kaynağıdır.

Segmentasyon, A/B testi ve çıkış kriterleri iş akışının içinde yer alır

Bu anahtar kelime için sayfa bir arama sonuçlarındaki baskın desen, segmentasyon, A/B testi ve sessiz saatleri “en iyi uygulamalar” olarak listelemektir: makalenin sonunda, onları kullanan kampanyadan kopuk, genel madde işaretleri. Bu yanlış bir çerçevedir. Bunlar, iş akışının yanında oturan en iyi uygulamalar değildir. Bunlar iş akışıdır.

İşte aynı kavramlar kümesi, en iyi uygulamalar olarak çerçevelenmiş ve iş akışı düğümleri olarak çerçevelenmiş:

Kavram	En iyi uygulama çerçevesi (yanlış)	İş akışı düğümü çerçevesi (doğru)
RFM segmentasyonu	“Göndermeden önce listeni bölümlere ayır”	Yakınlık, sıklık ve parasal değeri kontrol eden ve ardından yüksek RFM abonelerini düşük RFM'li abonelerden farklı bir yola yönlendiren bir KARAR düğümü. PushEngage segmentasyon gönderisi bu düğümü besleyen RFM kova tanımlarını kapsar.
A/B testi	“Kopyanı her zaman A/B testi yap”	50/50 yüzde tahsisli bir YOL_AYIR düğümü, yola göre yük dengeli aboneler ve test anlamlılığa ulaştığında kazananı %100'e çıkaran bir winner_edge_id alanı
Sessiz saatler	“Sabah 3'te gönderme”	start_at, end_at, timezone ve gönderiyi skip eden veya sessiz saatler bittikten bir dakika sonrasına reschedule eden bir fallback ayarı ile iş akışı düzeyinde bir seçenek
Çıkış kriterleri	“Satın alan kişilere göndermeyi durdur”	Her düğümden önce aboneyi bir kitle filtresine veya tetiklenmiş bir hedefe karşı kontrol eden ve eşleşirse iş akışını iptal eden bir iş akışı düzeyinde kural

Fark önemlidir çünkü en iyi uygulama maddelerine onay vermek kolaydır ve uygulamak zordur. İş akışı düğümleri motorun kendisi tarafından uygulanır. KARAR her seferinde çalışır. SPLIT_PATH her aboneyi dengeler. Sessiz saatler geri dönüşü, zamanı kontrol etmeyi hatırlamadan devreye girer. Çıkış kuralı, kampanya sahibi dikkat etmese de iş akışını iptal eder.

Yukarıdaki sepeti terk etme şablonu için bu, bir abonenin terk edilen ürünleri satın aldığı anda çıkış kuralının tetiklendiği, iş akışının o abone için iptal edildiği ve ikinci ve üçüncü hatırlatıcıların asla gönderilmediği anlamına gelir. Destek bileti yok, finans departmanından e-posta yok, özür kampanyası yok. Motorun durmasını söyleyen bir kuralı olduğu için iş akışı durdu.

Çok kanallı orkestrasyon: tek iş akışı, dört kanal

Çoğu anlık bildirim platformu tek kanallı araçlardır. Bazıları iki kanallıdır. Cevaplayamadıkları soru, orta ölçekli bir müşteri tutma ekibinin gerçekten cevaplaması gereken sorudur: bu abonenin durumuna göre hangi kanal ateşlenmeli? Kaydolduysa web anlık bildirimi. Web anlık bildiriminden çıktıysa e-posta. Sepet değeri 200$'ın üzerindeyse WhatsApp. Abone şu anda sitedeyse canlı sohbet.

Bu karar ağacı, dört araçta dört kampanya değil, tek bir çok kanallı anlık bildirim otomasyon iş akışıdır. PushEngage İş Akışları ile bir sepeti terk etme yolculuğu şu şekilde oluşturulabilir:

• BAŞLANGIÇ: sepet_terk_edildi olayı
• BEKLE: 1 saat
• KARAR düğümü 1: abone web push'a abone mu?
  • EVET yolu: EYLEM, web push hatırlatıcısı gönder
  • HAYIR yolu: bir sonraki karara devam et
• BEKLE: web push'tan 30 dakika sonra (veya hiç push gönderilmediyse hemen)
• KARAR düğümü 2: abone web push'a tıkladı mı veya web push'a abone değil mi?
  • Web push gönderildi ve tıklandıysa: ÇIKIŞ (sepet akışının bitmesine izin ver)
  • Web push gönderildi ve tıklanmadıysa veya web push yoksa: devam et
• KARAR düğümü 3: sepet değeri 200$'dan büyük mü?
  • EVET yolu: EYLEM, WhatsApp kanalındaki SendPushNotification eylemi aracılığıyla WhatsApp mesajı gönder
  • HAYIR yolu: EYLEM, ESP'nize yapılan bir HTTP isteği aracılığıyla e-posta gönder
• purchase hedefinde ÇIK

Dört kanal, bir iş akışı, bir çıkış kriteri seti, bir abone kimliği. Daha önce üç satıcı girişi ve bir Zapier akışı olmadan bunu koordine edemeyen aynı elde tutma yöneticisi, artık bunu motorun zorladığı tek bir iş akışı içinde oluşturabilir.

Ayrı araçlarda aynı şeyi yapmak, platformlar arasında altı senkronizasyon, "VIP abone" olarak kimin sayıldığı konusunda anlaşamayan iki segmentasyon motoru ve her araç kendi dönüşümlerini bildirdiği için tek bir gelir atfı anlamına gelir. Bunu tek bir iş akışı motoru içinde yapmak, tek bir abone kimliği, tek bir karar mantığı seti ve tek bir huni raporu anlamına gelir. İtme ve e-postanın tek bir elde tutma planı içinde nasıl birlikte çalıştığı hakkında daha fazla bilgi için itme ve e-posta çok kanallı orkestrasyonuna bakın.

Bu, baskın sayfa bir sonuçlarında benzeri olmayan farklılaştırıcıdır. Bu anahtar kelime için ilk on beş sonucun hiçbiri, çapraz kanal iş akışını tek bir nesne olarak tanımlamaz. Hepsi itmeyi konu ve e-postayı karşılaştırma olarak ele alır.

Elde tutma matematiği: iş akışı başına gelir, kanal başına, bildirim başına

Bir sonraki P&L incelemesinde savunamayacağınız bir iş akışı, sonlandırılacak bir iş akışıdır. Elde tutma yöneticisinin görevi, her satır öğesinin dolar bazında ne ürettiğini göstermektir. Çoğu "e-ticaret için otomatik anlık bildirimler" makalesi tıklama oranında durur. Bu yeterli değil. Doğru metrik, abone başına, iş akışı başına, kanal başına kurtarılan gelirdir.

PushEngage İş Akışları her düğümde üç sayıyı takip eder:

• Sıradaki kullanıcılar: şu anda bu düğümde bekleyen aboneler (tipik olarak BİR BEKLEME veya sessiz saat yeniden planlaması)
• Tamamlanan kullanıcılar: bu düğümden geçen aboneler
• Çıkan kullanıcılar: çıkış kriterlerinin eşleşmesi veya abonelikten çıkmaları nedeniyle bu düğümde iş akışından ayrılan aboneler

Aktif bir sepet terk etme iş akışı için düğüm düzeyinde analitikler şuna benzer (gerçekçi 200.000 aboneye sahip bir listeden alınan örnek sayılar):

Düğüm	Sıradaki	Tamamlanan	Ayrılan	Notlar
BAŞLANGIÇ (sepet_terk_edildi)	0	12,400	320	İş akışı başlangıcında 320 abone çıkış kriterleriyle eşleşti (sepet olayı ile iş akışı taraması arasında satın alındı)
1 saat BEKLE	180	11,900	320	Normal kuyruk derinliği
EYLEM: hatırlatıcı #1	0	11,900	0	Bildirim gönderildi
24 saat BEKLE	240	9,800	1,860	Yüksek çıkış sayısı: 1.860 abone ilk hatırlatıcıdan sonra satın aldı
KARAR: sepet hala terk edilmiş durumda	0	9,800	0	Kalan tüm abonelerin hala sepeti açık
EYLEM: 2. hatırlatıcı (%10 indirim)	0	9,800	0	İndirimle gönderilen bildirim
48 saat BEKLE	90	6,300	3,410	3.410 satın alma daha çıkışı tetikledi
EYLEM: son hatırlatıcı (%20 indirim)	0	6,300	0	Son bildirim
SON	yok	6,300	yok	6.300 abone satın almadı

Bu hunide, 5.270 abone (1.860 + 3.410) iş akışı sırasında satın alma yaptı, bu da %42,5'lik bir kurtarılan sepet oranı anlamına geliyor. İki bekleme (24 saat ve 48 saat) hunideki en yüksek çıkış düğümleridir, bu beklenen bir desendir: satın alma kararları, eylem pencerelerinde değil, bekleme pencerelerinde gerçekleşir. İş akışınız ters deseni gösteriyorsa, eylem düğümlerinde yüksek çıkışlar ve bekleme düğümlerinde düşük çıkışlar varsa, zamanlamanız yanlıştır ve beklemeler kısaltılmalıdır.

Yeniden elde tutma matematiği maliyeti de ele almalıdır. Abone katıldıktan sonra anlık bildirimlerin gönderim başına maliyeti sıfırdır. E-posta maliyetleri ESP'nize bağlıdır, ancak 200.000 abonelik bir listede tipik bir Klaviyo veya Bloomreach kurulumuyla, tek bir sepet terk gönderimi, ölçülen kullanımdan birkaç yüz dolara mal olur (sözleşme şartlarınız geçerlidir).

%42 oranında sepet kurtaran bir anlık bildirim otomasyonu, %38 oranında anlık bildirim ve e-posta iş akışıyla aynı kurtarılan gelir sayısına, önemli ölçüde daha düşük bir maliyetle ulaşabilir. Kendi liste boyutunuz ve ESP sözleşmeniz üzerinden hesaplamayı yapın. Önemli olan, anlık bildirim, uygulama anlık bildirimi ve WhatsApp'ın e-postanın sahip olduğu gönderim başına maliyeti oluşturmamasıdır ve iş akışının görevi, abonenin durumu izin verdiğinde her zaman en ucuz kanalı ilk önce kullanmaktır.

Satır öğesi savunulabilir olduğunda (bu iş akışı, Y maliyetine karşılık X sepet kurtardı), bütçe konuşması kısadır.

PushEngage İş Akışlarında Oluşturun

Bu makaledeki her şablon doğrudan PushEngage Workflows bileşenlerine eşlenir. İşte yukarıdaki beş şablonun eşlemesi:

Şablon	Kullanılan düğüm türleri	Kullanılan Eylem Türleri	İş Akışı Seçeneği
Hoş geldiniz serisi	BAŞLANGIÇ, BEKLE, KARAR, EYLEM, SON	SendPushNotification, AddSegment	Çalıştırma türü: Tek
Göz atma terk etme	START, WAIT, DECISION, ACTION, EXIT	Push Bildirimi Gönder	Çalıştırma türü: Birden Çok Paralel
Sepet terk escalasyonu	BAŞLANGIÇ, BEKLE, KARAR, EYLEM, SON	Push Bildirimi Gönder	Çalıştırma türü: Birden Çok Paralel; hedefte çıkış purchase
Satın alma sonrası inceleme isteği	START, WAIT, SPLIT_PATH, ACTION, END	Push Bildirimi Gönder, HTTP İsteği	Çalıştırma türü: Birden Çok Sıralı; sessiz saatler 22:00 – 08:00, yeniden planlama yedeklemesi
Geri kazanma	START, ACTION, WAIT, DECISION, END	SendPushNotification, AddSegment	Çalıştırma türü: Tek; kitle tabanlı tetikleyici

Workflows motoru, bu akışların her birini kapsayan 60'tan fazla gönderilmiş şablonla birlikte gelir. Her şablon bir başlangıç noktasıdır. Yukarıdaki her şablon, beş dakikadan kısa sürede Shopify, Shopify Plus, WooCommerce, BigCommerce veya Magento'da PushEngage anlık bildirim iş akışı oluşturucusu içinde kurulabilir.

Workflows özelliği ayrıca, önceki bölümde yer alan çok kanallı yönlendirmeyi mümkün kılan karar mantığını ve kişiselleştirme adımlarını kapsar ve yalnızca bildirim göndermekten daha fazlasını yapmanızı sağlayan on bir eylem türünü destekler: abone özniteliklerini güncelleme, CRM'inize webhook'lar gönderme, sonraki iş akışlarını başlatma veya çakışanları durdurma.

Bu iş akışlarının eksiksiz bir e-ticaret yeniden elde tutma programına nasıl uyduğuna dair daha geniş bir bakış açısı için, e-ticaret anlık bildirimleri hub gönderisi bu şablonların uyguladığı kampanya türlerini kapsar.

Ücretsiz plan, size 200 abone, dört kanalın tamamını (web anlık bildirim, uygulama anlık bildirimi, WhatsApp ve canlı sohbet) ve ilk günden itibaren tam Workflows motorunu sunar. Bu, kanalı bir bütçe satırına koymadan önce kanıtlamak için yeterlidir.

Bunun neyi değiştirdiği

Bu makaleden çıkaracağınız tek bir şey varsa, o da şudur: E-ticaret için anlık bildirim otomasyonu, tetiklenmiş kampanyalar yığını değil, iş akışı mimarisidir. Satın alma ile sona eren sepeti terk etme yolculuğu, ilk satın alma davranışına göre dallanan karşılama serisi ve her abone için en ucuz uygun kanalı seçen çapraz kanal düzenlemesi aynı şekildedir.

Bir BAŞLANGIÇ, bazı BEKLEMELER, bazı KARARLAR, bazı EYLEMLER, bir ÇIKIŞ. Altı bağımsız tetikleyici bunu yapamaz. Bir iş akışı motoru yapabilir. Tutma matematiği oradan katlanır.

Ücretsiz planla başlayın, ilk planı bir saatten kısa sürede gönderin.