Kapıda ödeme dönüşüm takibi ve harici ödeme sayfaları

Kapıda ödeme dönüşüm takibi, her satın alımı bir teşekkür sayfasındaki tarayıcı pikseline güvenmek yerine, siparişin kendisinden, sunucuda reklam platformlarınıza göndermek demektir. Kapıda ödeme uygulamalarından, harici ödeme sayfalarından, sipariş formlarından ve hunilerden gelen siparişler çoğu zaman normal ödeme sayfasının dışında tamamlanır; bu yüzden piksel onları kaçırır ya da yanlış anda raporlar.

Bu rehber, bu siparişlerin neden kaybolduğunu ve ödeme durumunun neden önemli olduğunu anlatır. Satın alımı göndermek için üç anı karşılaştırır: sipariş oluşturulduğunda, onaylandığında ve ödendiğinde. Ayrıca reddedilen siparişleri ve iadeleri, ROASaurus'un harici ödeme sayfalarını nasıl ele aldığını da kapsar.

Pikseller kapıda ödemeli siparişleri neden kaçırır?

Tarayıcı pikseli, alıcı onu çalıştıran bir sayfaya ulaştığında bir satın alım raporlar. Bu genellikle ödeme akışınızın teşekkür sayfasıdır. Bu sayfayı atlayan ya da başka bir alan adında çalıştıran her sipariş yolu, satın alım olayını ya da ona ait reklam tıklamasını kaybeder.

Siparişin kendisi asla kaybolmaz. Bir sipariş kimliği, bir tutar, bir e-posta adresi ve çoğu zaman bir telefon numarasıyla online mağazanızda ya da huni aracınızda durur. Bu yüzden güvenilir çözüm, satın alımı sipariş verisinden sunucu tarafında göndermek ve reklam tıklamasını siparişe taşımaktır. Shopify'da sunucu tarafı takip genel yöntemi anlatır. Bu yazı ekstra özen isteyen siparişleri kapsar.

Bazı kapıda ödeme uygulamaları kendi piksel olaylarını da tetikler. Sunucu tarafı takibinizle aynı pikseli ama farklı bir olay kimliğini kullanırlarsa platform siparişi iki kez sayar. Bu uygulama olaylarını kapatın ya da çift sayımı önleme adımlarını izleyin.

Ödeme durumu neden önemli

Kartlı ödeme ödeme sayfasında tahsil edilir, yani sipariş oluştuğu anda ödenmiştir. Kapıda ödemeli sipariş farklıdır. Shopify kapıda ödemeyi manuel ödeme yöntemi olarak listeler ve bu siparişler, siz ödenmiş olarak işaretleyene kadar Payment pending durumunda kalır. Uygulamada bu, kurye parayı tahsil ettikten sonra olur ve günler sürebilir. Bazı siparişler hiç ödenmez, çünkü alıcı paketi reddeder ya da evde değildir.

Birçok takip kurulumu satın alımı sipariş ödendiğinde gönderir, çünkü kartlı siparişler için en güvenli an budur. Kapıda ödemeli sipariş için aynı kural, satın alımın günler sonra gelmesi ya da hiç gelmemesi demektir. Aşağıdaki günlük, satın alımları ödeme anında gönderen bir mağazadaki tipik bir durumu gösterir.

WooCommerce bunun tersini yapar. Kapıda ödemeli siparişleri, ödeme tahsil edilene kadar Processing durumuna alır; indirilebilir ürün içeren siparişler ise On hold durumuna gider. Processing durumundaki siparişleri gönderen bir kurulum bu yüzden onları verilir verilmez gönderir. Başka bir şeye karar vermeden önce platformunuzun bu siparişlere hangi durumu verdiğini kontrol edin.

Oluşturuldu, onaylandı ya da ödendi: satın alım ne zaman gönderilmeli?

Aralarından seçebileceğiniz üç an var. Her biri hızı doğrulukla takas eder.

Geç gelen satın alım olayları neden sorun

Reklam platformları bir satın alımı, ancak tıklamadan sonraki atıf penceresi içinde gerçekleşirse bir reklama atfeder. Meta'da 7 günlük tıklama atıfı ayarıyla, bir satın alım tıklamadan sonra 7 güne kadar bir reklama sayılır. Meta'nın Conversions API'si ayrıca event_time değeri 7 günden eski olan olayları reddeder ve bir olay çok eskiyse isteğin tamamını reddeder. Ödendiğinde gönderilen bir satın alımın bu yüzden iki kötü seçeneği vardır:

• Siparişin zamanıyla gönderin. Ödeme 7 günden sonra geldiyse Meta onu reddeder.
• Ödemenin zamanıyla gönderin. Meta kabul eder, ama reklam tıklaması artık 7 günden eski olabilir; bu yüzden satın alım reklama atfedilmez.

Hız optimizasyon için de önemlidir. Satın alımlar için optimize eden kampanyalar, gönderdiğiniz satın alımlardan öğrenir. Bir hafta geç gelen bir sinyal, algoritmaya geçen haftanın kitlesini anlatır.

Hangi anı seçmeli

Çoğu kapıda ödeme mağazası için oluşturulduğunda göndermek daha iyi varsayılandır. Sinyal anında gelir, tıklama hâlâ pencerenin içindedir ve hiçbir şey reddedilmez. Bedeli, reddedilen siparişlerin Ads Manager'da satın alım sayılmasıdır. Bunu bir sonraki bölümde gösterildiği gibi hedeflerinizde düzeltirsiniz.

Ekibiniz her siparişi göndermeden önce telefonla ya da mesajla onaylıyorsa, onay iyi bir orta yoldur. Sahte siparişleri eler ve genellikle bir gün içinde gerçekleşir. Kendi sisteminiz satın alımı o anda gönderebiliyorsa, örneğin bir API aracılığıyla, bunu kullanın. Sahte siparişler göründüğünden daha önemlidir: reklam platformu onlardan öğrenirse sipariş veren ama ödemeyen daha fazla insan arar.

Reddedilen siparişler, iptaller ve iadeler nasıl ele alınır

Bir satın alım gönderildikten sonra Ads Manager'da kalır. Kapıda reddedilen bir paket onu kaldırmaz. ROASaurus da iadeleri ya da iptalleri Meta'ya, TikTok'a ve diğer reklam platformlarının çoğuna göndermez; bu yüzden onların bildirdiği ciro, hiç tahsil etmediğiniz siparişleri de içerir. Yalnızca Google Ads ve Microsoft Advertising değerleri, değer düzeltmeleri açıksa bir iadeden sonra düzeltilebilir. Çözüm, ret oranınızı ölçmek ve karşılaştırdığınız rakamları buna göre ayarlamaktır.

İşte bir ay için çözümlü bir örnek. Basit tutmak için fiyatlar KDV'sizdir.

$3,000 reklam harcamasıyla aynı ay, hangi ciroyu kullandığınıza bağlı olarak çok farklı görünür:

Teslim edilen cirodaki brüt marj oranı $3,878 ÷ $8,200 = %47.3'tür; bu yüzden başabaş ROAS 1 ÷ 0.473 = 2.11 olur. Bu başabaş, teslim edilen ciro için geçerlidir. Ads Manager reddedilen siparişleri de saydığı için, karşılaştırmadan önce onu çevirmeniz gerekir. Başabaş ROAS yazısı temel formülü anlatır.

Sonucu doğrudan kontrol edebilirsiniz. Reklamlar, reklam harcaması $3,878'lik brüt kâra eşit olduğunda başabaşa gelir ve raporlanan $10,000 ciro ÷ $3,878 = 2.58.

Ret oranları çoğu zaman bölgeye, ürüne ve kampanyaya göre farklılık gösterir. Yeterli siparişiniz olduğunda bunları kampanya başına hesaplayın ve sonucu brüt kâr üzerinden kontrol etmek için POAS hesaplayıcısını kullanın.

Kendi rakamlarınızda iadeler ve iptaller

Shopify'da iptaller ve iadeler ROASaurus'a webhook ile ulaşır; bu yüzden kâr analitiği iadeleri cirodan düşer. Hiç gönderilmemiş iptal edilen siparişlerin sayılıp sayılmayacağını siz seçersiniz ve varsayılan olarak dışarıda bırakılırlar. Zaten kargoya verilmiş iptal edilen bir sipariş içeride kalır, çünkü kargosu size yine de para kaybettirmiştir. Henüz geri dönebilecek yakın tarihli siparişler için Predicted returns ayarı, gerçek iadeler gelene kadar satışların beklenen bir payını bekletir.

ROASaurus kapıda ödemeyi ve harici ödeme sayfalarını nasıl ele alır

Shopify

Her Shopify mağazasının Store settings içinde, iki seçenekli bir Checkout type ayarı vardır:

• Shopify checkout: satın alım, Shopify siparişi ödenmiş olarak bildirdiğinde, orders/paid webhook'u üzerinden gönderilir.
• External / COD checkout: satın alım, sipariş oluşturulduğunda orders/create webhook'u üzerinden gönderilir. Kapıda ödeme için ve Shopify siparişini kendileri oluşturan CheckoutChamp ya da Checkify gibi harici ödeme sayfaları için kullanın.

Ayar mağazadaki her siparişe uygulanır. Ödeme sayfasında ödenen kartlı siparişler neredeyse aynı anda oluşturulur ve ödenir; bu yüzden seçim esas olarak ödenmemiş siparişlerin ne zaman gönderileceğini değiştirir. Her sipariş bir kez gönderilir. Kapıda ödemeli bir siparişin ödendi güncellemesi sonradan geldiğinde ikinci bir satın alım gönderilmez.

Satın alım, siparişin kendi verilerini kullanır: tutar, para birimi, ürünler ve alıcının e-postası, telefonu ve adresi; bunlar gönderilmeden önce hash'lenir. ROASaurus siparişi, betiğinin sepete kaydettiği ziyaretçi kimliği üzerinden reklam tıklamasıyla eşleştirir. Bir sipariş bunu taşımıyorsa ROASaurus şu sırayla dener: sepet ve ödeme sayfası token'ları, ödeme sayfasındaki satın alım olayı, ziyaretçinin sitenizde daha önce verdiği bir e-posta ve siparişten kısa süre önceki aynı IP adresi ile tarayıcı (tam olarak tek bir ziyaretçi uyduğunda). Tam kurulum Shopify entegrasyonu sayfasındadır.

WooCommerce ve diğer online mağazalar

WooCommerce eklentisi, bir siparişi Processing ya da Completed durumuna ulaştığında gönderir. Kapıda ödemeli siparişler verildiklerinde Processing durumuna geçer, bu yüzden hemen gönderilir. Banka havalesi siparişleri Processing durumuna geçtiğinde gönderilir. Diğer online mağaza bağlayıcıları siparişi şu anlarda gönderir:

• Wix, Squarespace, Ecwid, Lightspeed, CCV Shop ve Shopware: siparişin ödeme durumu ödendi olduğunda.
• BigCommerce: sipariş Awaiting Fulfillment, Awaiting Shipment, Shipped ya da Completed gibi bir duruma ulaştığında.
• Magento: sipariş durumu Processing ya da Complete olduğunda.
• PrestaShop: sipariş geçerli olarak işaretlendiğinde.
• Özel webhook ve sipariş API'si: kendi sisteminiz siparişi gönderdiğinde.

Platformunuzun kapıda ödemeli siparişleri nasıl işaretlediğini kontrol edin. Kurye ödemeyi aktarana kadar ödenmemiş kalıyorlarsa satın alımları geç gelir.

Huniler ve kendi ödeme sayfanız

1. Betiği huni sayfalarına ekleyin

   Online mağazanızla aynı mağaza anahtarını kullanın; böylece bir ziyaretçi her iki alan adında da tek bir ziyaretçi kimliğini korur.

2. Alan adlarınızı listeleyin

   Store settings içinde, huni ve mağaza alan adlarını Linked domains altına ekleyin. Bu alan adları arasındaki bağlantılar böylece ziyaretçi kimliğini ve tıklama kimliklerini taşır.

3. Siparişleri sipariş API'si ile gönderin

   Huni siparişi kendisi alıyorsa, her siparişi /api/v1/orders adresine, _tl çerezini visitor_id olarak ekleyerek gönderin. Anı sisteminiz belirler: oluşturulduğunda, onaylandığında ya da ödendiğinde.

4. Event log'u kontrol edin

   İlk gerçek siparişler geldiğinde Event log sayfasını açın ve her birinin bağlı her platforma gönderildiğini kontrol edin.

POST /api/v1/orders
X-Roasaurus-Key: <store key>
Authorization: Bearer <API key>
Content-Type: application/json

{
  "order_id": "F-20931",
  "created_at": "2026-10-20T14:05:00Z",
  "total": 50.00,
  "currency": "USD",
  "email": "buyer@example.com",
  "phone": "+15555550123",
  "country": "US",
  "visitor_id": "<value of the _tl cookie>",
  "click_ids": { "fbc": "<_fbc cookie>", "fbp": "<_fbp cookie>" },
  "client_ip": "203.0.113.7",
  "user_agent": "Mozilla/5.0 ...",
  "items": [{ "variant_id": "SKU1", "quantity": 1, "price": 50.00 }]
}

Sipariş API'si her sipariş kimliğinin ilk kopyasını tutar. Sisteminiz onu oluşturulduğunda ve ödendiğinde yeniden çağırırsa yalnızca ilk çağrı bir satın alım gönderir. Daha fazla ayrıntı huniler ve birden çok alan adı sayfasındadır.

Kaçınılması gereken yaygın hatalar

• Kapıda ödeme mağazasında ödendi durumunu beklemek. Satın alımlar bir hafta geç gelir ya da hiç gelmez; geç gelen olaylar reddedilir ya da atıf penceresinin dışında kalır.
• Ads Manager ROAS'ını ödenen siparişler için hesaplanmış bir başabaşla karşılaştırmak. Önce başabaşı ödeme oranınıza bölün.
• Tek bir satın alım için iki kaynak. Bir form uygulamasının kendi pikseli ve sunucu olaylarınız aynı siparişi iki kez sayar. Bkz. mükerrer satın alım olayları.
• Tıklamayı alan adları arasında kaybetmek. Başka bir alan adındaki huni, betiğe ve bağlı alan adlarına ihtiyaç duyar; yoksa siparişleri reklam tıklaması olmadan gelir.
• Manuel siparişleri dışarıda bırakmak. Telefon ve sohbet siparişlerinin tarayıcı oturumu yoktur, ama yine de bir e-posta adresleri ya da telefon numaraları vardır. Sipariş verisinden gönderildiklerinde reklam platformuna eşleştirebileceği bir şey verirler.

Kaynaklar

1. Meta for Developers: Server Event Parameters
2. Shopify: WebhookSubscriptionTopic (GraphQL Admin API)
3. Shopify Help Center: Manual payment methods
4. Shopify Help Center: Understanding your order statuses
5. WooCommerce: Cash on Delivery documentation

ROASaurus'ta

• Shopify entegrasyonu
• WooCommerce entegrasyonu
• Yardım: huniler ve birden çok alan adı
• ROASaurus'ta kâr analitiği

Okumaya devam edin