Push Bildirim Rehberi: İzin, Segment, Frekans ve E-Ticaret Senaryoları

Mobil uygulama yatırımının geri dönüşü çoğu zaman tek bir yetenekte toplanıyor: müşteriye reklam bütçesi harcamadan, aracısız ulaşabilmek. Push bildirim bunu yapan kanal. Ama aynı kanal, yanlış kullanıldığında bir daha açılmamak üzere kapanan tek kanal da.

Bu yazıda push bildirimin e-postadan ve mesajlaşma kanallarından nerede ayrıldığını, izin yönetiminin neden en kritik karar olduğunu, segment ve frekansın nasıl kurulacağını, e-ticaret için hangi senaryoların gerçekten çalıştığını ve WhatsApp otomasyonuyla farkını anlatıyoruz. Uygulamanın kendisini yaptırma sürecini ise mobil uygulama yaptırma rehberinde ele aldık.

Push bildirim nedir, e-postadan farkı ne

Push bildirim, uygulamanın kapalı olduğu durumda bile cihazın kilit ekranında görünen kısa mesajdır. Teknik olarak mesajı siz değil, işletim sistemi sağlayıcısının bildirim servisi teslim eder; sizin gönderdiğiniz şey, o servise iletilen bir istek ve cihaza ait bir kimlik jetonudur.

Bu teslim biçiminin doğurduğu farklar, kanalın nasıl kullanılacağını da belirliyor:

Tablodaki en belirleyici iki satır kalıcılık ve kapatılma. Push okunmazsa kaybolur; yani "sonra bakarım" diye bir davranış yoktur. Buna karşılık kapatılması da tek dokunuş meselesidir ve kapatan kullanıcıyı geri kazanmak, e-posta listesinden çıkan birini geri kazanmaktan çok daha zordur. Bu iki gerçek, kanalın frekans disiplinini zorunlu kılıyor.

Push bildirim izni yönetimi: kanalı kaybetmenin en kolay yolu

Push kanalının tamamı tek bir ana bağlı: kullanıcının bildirim iznini vermiş olması. İzin isteme anını yanlış seçmek, uygulamanın en değerli yeteneğini daha ilk dakikada kaybetmek demek.

İki platformda izin nasıl işliyor

iOS tarafında bildirim izni her zaman kullanıcıdan açıkça istenir ve sistem penceresi bir kez gösterilir. Kullanıcı reddederse, uygulama o pencereyi tekrar açamaz; kullanıcının kendi iradesiyle sistem ayarlarına girip izni açması gerekir. Android tarafında da güncel sürümlerde ayrı bir bildirim izni sorulur; yani "Android'de zaten otomatik açık" varsayımı artık geçerli değil.

Ön izin ekranı

Doğru yaklaşım, sistem penceresini açmadan önce uygulamanın kendi ekranında kısa bir açıklama göstermek. Bu ekran, iznin ne işe yarayacağını somut söyler: "Siparişinizin kargoya verildiğini ve kampanyaların başladığını size haber verelim mi?" Kullanıcı bu ekranda hayır derse sistem penceresi hiç açılmaz ve izin şansınız yanmaz; ileride uygun bir anda tekrar sorabilirsiniz.

İzin isteme anı da içerikten önemli. En yüksek kabul, kullanıcının bildirimin faydasını hemen anladığı anlarda geliyor: ilk siparişten hemen sonra, stok bildirimi kurarken ya da bir ürünü favorilere eklerken. Uygulamayı ilk açan, henüz ne olduğunu bilmeyen kullanıcıdan izin istemek en düşük kabul oranını üretiyor.

Mobil uygulama bildirim tercihlerini kullanıcıya bırakın

İzin veren kullanıcı oranı zamanla düşer; bu normal ama ölçülmesi gereken bir düşüş. Uygulama içinde bildirim tercihlerini yöneten bir ekran bulundurun ve kullanıcıya tümünü kapatmak yerine tür bazında seçme imkânı verin: sipariş bildirimlerini açık tutup kampanya bildirimlerini kapatabilmek, kanalın tamamen kaybedilmesini önler.

Segment: kime gönderileceği, ne gönderileceğinden önce gelir

Push tarafında en yaygın hata, tüm kullanıcılara aynı mesajı göndermek. Bunun sonucu ölçülebilir biçimde şudur: mesajın ilgisiz olduğu kullanıcılar bildirimleri kapatır ve kanal her toplu gönderimde biraz daha küçülür.

Küçük mağazalarda bile kurulabilecek asgari segment seti şu:

• Hiç sipariş vermemiş kullanıcılar. İlk siparişe yönelten mesajlar.
• Bir kez sipariş vermiş kullanıcılar. İkinci siparişi hedefleyen, kategoriye uygun öneriler.
• Düzenli müşteriler. Yeni koleksiyon ve erken erişim mesajları.
• Uzun süredir uygulamayı açmayanlar. Geri kazanma; sıklık burada düşük tutulmalı.
• Kategori ilgisi. Son gezilen ve satın alınan kategorilere göre ayrım.
• Sepette ürün bırakanlar. Zamanlı hatırlatma.

Bu segmentler karmaşık bir veri altyapısı gerektirmiyor; uygulamanın zaten sahip olduğu sipariş ve gezinme verisiyle kurulabiliyor. Önemli olan segmentin gönderim anında hesaplanması, elle hazırlanmış statik listelerden okunmaması.

Frekans yorgunluğu ve doğru sıklık

Frekans için evrensel bir sayı vermek doğru olmaz; kategoriye ve müşteri alışkanlığına göre değişir. Ama sağlıklı bir kurgu şu üç kurala uyar:

1. İşlem bildirimleri sınırlı değildir. Sipariş alındı, hazırlanıyor, kargoya verildi, teslim edildi. Bunlar kullanıcının beklediği bildirimlerdir ve yorgunluk üretmez; aksine uygulamanın açılma sebebidir.
2. Pazarlama bildirimleri için tavan belirleyin. Kullanıcı başına haftalık bir üst sınır tanımlayın ve sistem bu sınırı otomatik uygulasın. Kampanya takvimi sıkıştığında kararı insanın vermesi, sınırın sürekli aşılmasına yol açıyor.
3. Sessiz saat tanımlayın. Gece gönderilen kampanya bildirimi, en hızlı kapatma sebeplerinden biri. Gönderimleri kullanıcının saat dilimine göre planlayın.

Frekans denetiminin en pratik ölçütü, gönderim sonrası bildirimleri kapatan kullanıcı sayısı. Her toplu gönderimden sonra bu sayıya bakın; belirli bir kampanya türü sürekli kapatma üretiyorsa sorun sıklıkta değil o mesajın hedeflemesinde demektir.

Kampanya bildirimi nasıl yazılır

Push, alanı en dar kanal. Başlık kilit ekranında kırpılır, gövdenin tamamı görünmeyebilir. Bu yüzden mesajın işi tek bir şey: merak değil netlik üretmek. İşe yarayan kalıp şu üç parçadan oluşuyor:

• Ne olduğu, ilk kelimelerde. Kampanyanın adı değil kapsamı. "Yaz İndirimi Başladı" yerine "Tüm ayakkabılarda indirim başladı".
• Kime hitap ettiği. Segmente göre kişiselleşen bir ayrıntı: bıraktığı ürün, baktığı kategori, beklediği stok.
• Doğru varış noktası. Bildirime tıklayan kullanıcı ana sayfaya değil, ilgili ürüne ya da kategoriye düşmeli. Derin bağlantı kurulmamış bildirimler, kullanıcıyı aramaya zorladığı için tıklansa bile satışa dönmüyor.

Kampanya duyurularını site tarafında da tekrarlamak gerekiyor; uygulaması olmayan ziyaretçi aynı kampanyayı sitede görmeli. Site içi duyuru tarafında kampanya zili gibi modüller aynı işi tarayıcıda yapıyor.

Sepet hatırlatmanın push versiyonu

Terk edilen sepet, push tarafında en yüksek getirili senaryo; çünkü mesajın konusu kullanıcının kendi seçtiği üründür. Ama zamanlama ve içerik kurgusu, e-posta veya mesajlaşma kanalındaki kurgudan farklı olmalı.

• İlk hatırlatma erken olmalı. Push anlık bir kanal; sepetten çıkıldıktan birkaç saat sonra gönderilen bildirim, kullanıcı hâlâ satın alma niyetindeyken yakalar.
• İndirimi ilk mesajda vermeyin. İlk bildirimde yalnızca hatırlatma yapın. İndirimi baştan verirseniz, düzenli müşteriler sepeti bilerek bekletmeyi öğrenir.
• En fazla iki hatırlatma. Üçüncü mesaj genelde kapatma üretiyor.
• Bildirim doğrudan sepete gitsin. Ürün listesine değil, dolu sepete.

Uygulaması olmayan müşteride aynı senaryo mesajlaşma kanalıyla kurulur; bu kurgunun ayrıntılarını terk edilen sepet kurtarma yazısında ve sepet hatırlatıcı modülünde anlattık. İkisini birlikte kurarken tek kural önemli: aynı sepet için iki kanaldan aynı anda mesaj gitmemeli. Kanal seçimi, kullanıcının uygulamayı kurup kurmadığına göre yapılmalı.

Push notification e-ticaret senaryoları

Push ile WhatsApp otomasyonu arasındaki fark

İkisi birbirinin alternatifi değil; farklı ön koşulları ve farklı güçlü yanları var.

• Erişim tabanı farklı. Push yalnızca uygulamayı kurmuş ve izin vermiş kullanıcıya ulaşır. Mesajlaşma kanalı, uygulaması olmayan müşteriye de ulaşır; e-ticarette bu kitle her zaman daha büyüktür.
• Maliyet yapısı farklı. Push'ta mesaj başına ücret yoktur; mesajlaşma kanalında gönderim ücretlidir. Bu, yüksek hacimli duyurularda push'u, hedefli ve değerli iletişimde mesajlaşmayı öne çıkarır.
• Etkileşim farklı. Push tek yönlüdür, kullanıcı cevap yazamaz. Mesajlaşma kanalında müşteri doğrudan yanıt verip soru sorabilir; bu, satış öncesi tereddütleri çözmede belirgin fark yaratır.
• Kalıcılık farklı. Okunmayan push kaybolur, mesaj sohbet listesinde durur.

Pratikte kurduğumuz kurgu şu: işlem bildirimleri her iki kanalda da çalışır ama kullanıcı uygulamayı kurmuşsa push tercih edilir, kurmamışsa mesajlaşma devreye girer. Kampanya tarafında ise geniş duyurular push, kişiye özel ve yüksek değerli iletişim mesajlaşma üzerinden gider. Kargo ve sipariş bildirimi modülleri bu ayrımı otomatik yapacak şekilde kurgulanabiliyor.

Teslim edilmeyen bildirimler ve jeton temizliği

Push tarafında görünmeyen ama zamanla listeyi bozan teknik bir konu var: cihaz jetonları kalıcı değil. Kullanıcı uygulamayı sildiğinde, cihazını değiştirdiğinde ya da uygulamanın verisini temizlediğinde eski jeton geçersiz hâle gelir. Gönderim servisi bu durumda bir geçersizlik yanıtı döner ve bu yanıtın işlenmesi gerekir.

İşlenmezse iki sonuç doğuyor. Birincisi, gönderdiğiniz kitle olduğundan büyük görünür; teslim edilmeyen bildirimler kitleyi şişirir ve tüm oranlarınız yanlış hesaplanır. İkincisi, aynı kullanıcı birden fazla jetonla kayıtlı kalırsa aynı bildirimi birkaç kez alabilir; bu, bildirimi kapatma sebeplerinin en hızlısı.

Sağlıklı bir kurgu şunları yapar: jeton kullanıcı hesabıyla birlikte saklanır, geçersizlik yanıtı gelen jetonlar otomatik silinir, aynı kullanıcının aynı cihazdaki eski jetonu yeni jeton kaydedilirken temizlenir ve kullanıcı çıkış yaptığında o cihazın jetonu hesaptan ayrılır. Son madde özellikle önemli: ortak kullanılan bir cihazda çıkış yapıldığı hâlde jeton bağlı kalırsa, bir başkasının siparişine ait bildirim yanlış kişiye gider.

Aynı disiplin hesap silme akışında da geçerli. Kullanıcı uygulama içinden hesabını sildiğinde, o hesaba bağlı tüm cihaz jetonlarının da silinmesi gerekir; aksi hâlde silinmiş bir hesaba bildirim göndermeye devam edersiniz.

Neye bakarak ölçmeli

Push tarafında en çok bakılan ama en az şey söyleyen metrik açılma oranı. Anlamlı olan ölçüler şunlar:

• İzin veren kullanıcı oranı ve zaman içindeki seyri. Kanalın büyüklüğü budur; her şeyden önce gelir.
• Gönderim başına bildirim kapatma sayısı. Kanalın yıpranma hızı.
• Bildirimden gelen oturumda tamamlanan sipariş. Tıklama değil, sonuç.
• Senaryo bazında karşılaştırma. Sepet hatırlatma ile kampanya duyurusunu aynı tabloda değerlendirmek yanıltır; her senaryo kendi geçmişiyle karşılaştırılmalı.

İzin, kişisel veri ve ticari ileti tarafı

Push gönderimi için cihaz başına bir kimlik jetonu saklanır ve bu jeton kullanıcı hesabıyla ilişkilendirildiğinde kişisel veri işleme kapsamına girer. Bu nedenle aydınlatma metninizde bildirim amacıyla hangi verinin işlendiği yer almalı ve kullanıcı bildirimleri kapattığında ya da hesabını sildiğinde jetonun silinmesi gerekir.

Ticari ileti tarafında ise şunu söylemek doğru olur: mevzuat kanalları örnekleme yöntemiyle sayıyor ve belirleyici ölçüt iletinin ticari amaç taşıması. Uygulama bildirimleri, kullanıcının kendi cihazında kendi verdiği izinle teslim edildiği için telefon numarasına yapılan gönderimlerden farklı bir zeminde duruyor; buna karşılık ihtiyatlı yaklaşım, pazarlama bildirimleri için ayrı ve geri alınabilir bir tercih sunmak ve bu tercihi kayıt altında tutmaktır. Mesajlaşma kanallarındaki izin yükümlülüklerini ayrıntılı olarak ticari mesaj ve İYS rehberinde yazdık. Bu bölüm hukuki danışmanlık değildir; kurumsal yapılar için hukuk danışmanından görüş alınmasını öneririz.

Biz nasıl kuruyoruz

Geliştirdiğimiz mobil uygulamalarda bildirim altyapısını üç parça hâlinde teslim ediyoruz: gönderim paneli, segment tanımları ve tetikli senaryolar. Panel üzerinden hem elle kampanya gönderimi yapılabiliyor hem de sipariş durumu, sepet terk ve stok bildirimi gibi senaryolar kullanıcı davranışına bağlı olarak otomatik çalışıyor. Derin bağlantılar ilk sürümden itibaren kuruluyor; bildirime tıklayan kullanıcı doğrudan ilgili ekrana düşüyor.

Bildirimin mağazanızla nasıl ortak çalıştığını e-ticaret mobil uygulaması yazısında bulabilirsiniz. Mevcut uygulamanızın bildirim kurgusunu değerlendirmemizi isterseniz bize yazabilirsiniz.